3 ms·
> No trust required. You also have to trust that SGX isn't compromised. But even without that, you can log what goes into SGX and what comes out of SGX. That
by Retr0id 1y ago
> No trust required.
You also have to trust that SGX isn't compromised.
But even without that, you can log what goes into SGX and what comes out of SGX. That seems pretty important, given that the packets flowing in and out need to be internet-routable and necessarily have IP headers. Their ISP could log the traffic, even if they don't.
> Packet Buffering and Timing Protection: A 10ms flush interval batches packets together for temporal obfuscation
That's something, I guess. I don't think 10ms worth of timing obfuscation gets you very much though.
> This temporal obfuscation prevents timing correlation attacks
This is a false statement. It makes correlation harder but correlation is a statistical relationship. The correlations are still there.
(latter quotes are from their github readme https://github.com/vpdotnet/vpnetd-sgx https://github.com/vpdotnet/vpnetd-sgx )
All that said, it is better to use SGX than to not use SGX, and it is better to use timing obfuscation than to not. Just don't let the marketing hype get ahead of the security properties!
- Retr0id 1y agoTaking a look at their code I see a rather concerning comment: func (om *ObfuscationManager) ProcessOutgoingPacket( ... // TODO where is the obfuscation here? https://github.com/vpdotnet/vpnetd-sgx/blob/bc63e3b8efe41120b21fdcf18c26b1318f9e7e5d/obfuscation.go#L61 https://github.com/vpdotnet/vpnetd-sgx/blob/bc63e3b8efe41120... While I do see the impl of the 10ms flush interval, I don't see any randomisation within batches. So iiuc, packets are still flushed in their original order.
- MagicalTux 1y agoThe comment was added before the implementation of the IPC buffer & shuffling and was left there, sorry about that. In an older version packets were sent back in sequence to their original connection to the host, as it was faster. We since then implemented a system where nproc (16+) buffers receiving packets running at differed intervals, meaning that while packets are processed "in order" the fact this runs in multiple threads, reading packets even from the same client will cause these to be put in queues that will be flushed at different timings. We have performed many tests and implementing a more straightforward randomized queue (by allocating memory, handling array of pointers of buffers, shuffling these, and sending these shuffled) did not make much of a difference in terms of randomization but resulted a huge loss in performance due to the limitations of the SGX environment. As we implement other trusted environments (TEE) we will be implementing other strategies and obfuscation methods.