[Cryptography] Verified privacy and VPNs

[Mark Karpelès]

Greetings.

This is my first email here. I’ve been reading a lot and following
some of the discussions in the past but haven’t had much to bring to
the table. That is, until today.

I’ve been invited by Andrew Lee to join him in creating vp.net, a VPN
service aimed at providing verifiable privacy.

You’ll probably be thinking “oh no not another one of these,” if so
please bear with me for a little while as we’ve been working on
creating something truly different.

Specifically, we’ve made it possible during the connection to measure
the software running on the server thanks to Intel’s SGX and verify
that the host is running our software. We have today released the
source code for the software, which anyone can compile and verify the
generated binary’s hash (MRENCLAVE) matches the host attestation.

There are a number of layers involved in this process, and I’ll start
by answering some of the most common remarks, starting with addressing
SGX itself.
Yes, SGX has had its weaknesses, and a lot of people sent me a link to
sgx.fail, to which I’ll point to the bottom of said page “Is SGX
secure now?”. Unlike SGX running on end user devices we have the
ability to upgrade BIOS and CPU microcode across servers to ensure the
latest fixed version of SGX is in use, and Intel’s own system will
refuse to attest instances with known issues.

Another important point I want to address is that what we’ve built
here isn’t meant to be a final answer to VPN privacy. Technology keeps
changing and there is no answer to keeping things private forever
without adapting and evolving. As of today SGX has proven to be a good
technology to use in terms of security, ease of use, availability and
perceived trustworthiness, but we won’t be stopping there.
I also hope feedback I get here and in other places will help improve
privacy and security further.

The solution we’ve built and deployed today offers an improvement
compared to all existing VPN services. That is, while many have been
opening the details on their client-side software, none have opened
their servers, or made it possible to actually confirm the software
they are running is indeed what is claimed to be.

What did we build?

SGX has a number of features that makes it an ideal solution to bring
verifiable privacy as a service. The fact that code running in
enclaves can be hashed and compared is an important part, but also the
fact that SGX memory is encrypted.

With this in mind we’ve built a lightweight enclave system that will
create a WireGuard® private key at launch (which is not stored and
will be lost if the enclave stops) and route traffic between wireguard
hosts and the Internet.

The enclave handles the following:

* Registration of WireGuard® client keys for use with the server,
using an attested HTTPS server (the attestation is inserted in the TLS
certificate).
* No link between your identity (the authentication token proving you
have paid for the service) and subsequent use of the service.
* Reception and decryption of encrypted wireguard packets within the
SGX enclave.
* In-process NAT routing with the client ID being part of the NAT key,
ensuring no traffic leaks between clients and allowing clients to use
virtually any IP address.
* Translated packets are then shuffled and mixed with other users’
traffic and sent to the open Internet.
* Packets from the Internet are matched to the NAT table to their
respective users, encrypted and sent over WireGuard®.
* The enclave also generates random traffic to connected WireGuard®
users in order to further obfuscate traffic.

To be really honest it is difficult to define the right level of
shuffling required to obfuscate traffic and depending which source you
read it can vary a lot. We’ve aimed at providing the right amount of
shuffling while keeping performances good enough it wouldn’t be an
issue for day to day use.

This means that typically there will be ~10ms delay on packets going
through the enclave, which should be low enough it won’t be noticeable
while still mixing around packets enough so that it becomes impossible
to link specific packets to specific IPs without a lot of work, and
any link would be circumstantial at best.

Conclusion

Of course things can’t be perfect. There is no such thing as perfect
encryption, perfect security or perfect privacy. Perfection is an
ideal, something to thrive for and get closer to without ever
reaching.

What we’ve aimed for is to create a spark, an innovation in the world
of privacy VPNs, of which many exist and yet all ask you to trust them
not to be spying on you despite increasing pressure, to trust them not
to ever get hacked by malicious third parties, to trust them not to
put their own goals before you.

Of course the element of trust can never be fully removed, however
thanks to SGX, it goes from a service for which sometimes the
underlying company isn’t even clearly known to Intel. SGX has had its
share of security breaches, but this goes to show people are actively
working on finding and reporting these, and while SGX’s use as a DRM
platform to offer a trusted environment on client devices has been
difficult due to the requirements of keeping an up to date BIOS and
CPU microcode, it is much easier to do it the other way around -
allowing client devices to benefit from a trusted environment on our
servers.

I am still considering other options, technologies and methods. Any
and all input is welcome. This is a journey into privacy not by trust,
but by cryptographic systems.


Mark Karpeles
CTO @ VP.NET