Intel SGX/remote attestation for verifying that servers are running the code they say they are running is very interesting, I believe Signal talked about doing something similar for contact discovery, but at a base level it requires a lot of trust. How do I verify that the attestation I receive back is the one of the machine I am contacting? Can I know for sure that this isn't a compromised SGX configuration, since the system has been broken in the past? Furthermore, can I really be sure that I can trust SGX attestations if I can't actually verify SGX itself? Even if the code running under SGX is verifiable, as an ordinary user it's basically impossible to tell if there are bugs that would make it possible to compromise.
Personally I like the direction Mullvad went instead. I get that it means we really can't verify Mullvad's claims, but even in the event they're lying, at least we got some cool Coreboot ports out of it.
If you're really paranoid, neither this service nor Mullvad offers that much assurance. I like the idea of verifiability, but I believe the type of people who want it are looking to satisfy deeper paranoia than can be answered with just trusting Intel... Still, more VPN options that try to take privacy claims seriously is nothing to complain about.
junon · 16m ago
> Can I know for sure that this isn't a compromised SGX configuration, since the system has been broken in the past?
As far as I'm aware, no. Any network protocol can be spoofed, with varying degrees of difficulty.
I would love to be wrong.
MagicalTux · 13m ago
Intel audits configuration on system launch and verifies it runs something they know safe. That involves CPU, CPU microcode, BIOS version and a few other things (SGX may not work if you don't have the right RAM for example).
The final signature comes in the form of a x509 cerificate signed with ECDSA.
What's more important to me is that SGX still has a lot of security researchers attempting (and currently failing) to break it further.
rasengan · 9m ago
> Any network protocol can be spoofed, with varying degrees of difficulty.
Because of the cryptographic verifications, the communication cannot be spoofed.
MagicalTux · 23m ago
Intel will not attest insecure configurations. Our client will automatically verify the attestation it receives to make sure the certificate isn't expired and has a proper signature under Intel's CA trust.
A lot of people have been attempting to attack SGX, and while there have been some successful attacks these have been addressed by Intel and resolved. Intel will not attest any insecure configuration as do other TEE vendors (AMD SEV, ARM Trustzone, etc).
jchw · 17m ago
I really am interested in how this works. How can the client software verify that the SGX attestation actually is from the same machine as the VPN connection? I guess there's probably an answer here, but I don't know enough about SGX.
MagicalTux · 6m ago
The way this works is by generating a private key inside the enclave and having the CPU attest its public key.
This allows generating a self signed TLS certificate that includes the attestation (under OID 1.3.6.1.4.1.311.105.1) and a client connecting verifying the TLS certificate not via the standard chain of trust, but by reading the attestion, verifying the attestation itself is valid (properly signed, matching measured values, etc) and verifying the containing TLS certificate is indeed signed with the attested key.
Intel includes a number of details inside the attestation, the most important being intel's own signature of the attestation and chain of trust to their CA.
exfil · 15m ago
These VPN's for privacy are so bad. You give your credit card (verified identity), default gateway and payload to foreign soil and feel safe. On top of that your packets clear text metadata verifies you with cryptographic accuracy.
In today's internet you just cannot have exit IP which is not tied either into your identity, payment information or physical location. And don't even mention TOR, pls.
MagicalTux · 11m ago
You're welcome to use cryptocurrencies (we have a page for that), and our system only links your identity at connection time to ensure you have a valid subscription. Your traffic isn't tied to your identity, and you can look at the code to verify that.
rkagerer · 41m ago
Someone had a comment here that just disappeared, mentioning it's by Mark Karpelès (yes, the same guy from MtGox) and Andrew Lee. Why did that remark get deleted?
staplers · 31m ago
I'm assuming OP is Mark Karpeles, MagicalTux is a well-known username for him.
b8 · 22m ago
They claim to allow anonymous sign up and payments, but requires an email,an account, zip code and name for Crypto payments, but fake info could be used I guess. I tried ordering via Crypto, but it constantly gives me this error: "Unable to load order information. Try again".
Honestly, I feel more comfortable using Mullvad. This team has some folks with questionable backgrounds and I wouldn't trust Intel. Also VPN providers are usually in non-us countries due to things like the Lavabit, Yahoo incidents and the Snowden revelations.
rasengan · 59s ago
> Honestly, I feel more comfortable using Mullvad. This team has some folks with questionable backgrounds and I wouldn't trust Intel.
Relying on "trust" in a security/privacy architecture isn't the right way to do things - which is what this solves. It removes the need to trust in a person or person(s) in most VPN company cases since they have many employees, and moves it to trusting in code.
> Also VPN providers are usually in non-us countries due to things like the Lavabit, Yahoo incidents and the Snowden revelations.
The system is designed so that any change server side will be immediately noticed by clients/users. As a result, these issues are sufficiently mitigated, and instead, allows people to take advantage of strong consumer, and personal, protection laws in the US.
jen729w · 1h ago
> built in the usa.
backed by the constitution.
Old copy? Might need an update.
john01dav · 27m ago
One of the main use cases of a VPN is against governments, but a government making Intel compromise SGX is plausible given what we know from Snowden.
MagicalTux · 15m ago
The US government might be able to pressure Intel into doing something with SGX, but there are way too many eyes on this for it to go unnoticed in my opinion, especially considering SGX has been around for so long and messed with by so many security researchers.
The US government also likely learned a lesson from early attempts at backdoors (RSA, etc) that this kind of things do not stay hidden and do not reflect well.
We've thought about this long and hard and planning to mitigate this as much as possible. Meanwhile we still offer something that is a huge step forward compared to what is standard in the industry.
remram · 32m ago
What does the verifiable program do though? With a VPN, what I'm concerned about is my traffic not being sniffed and analyzed. This code seem to have something to do with keys but it's not clear how that helps...?
tripdout · 1h ago
How does Intel SGX compare with e.g. ARM Trustzone? Seems like its similar in that information access is restricted from certain privilege levels?
MagicalTux · 56m ago
Seems fairly similar, ARM's response to TEE basically. We started with SGX because it is battle tested and has a lot of people still trying to find issues, meaning any issue is likely solved quickly, however we are planning to also evaluate and support other solutions. Information is restricted and cannot leave the enclave unless the code running in there allows it to in both cases.
tossaway23523 · 39m ago
> battle tested
lol
SGX has been broken time and again
SGX has 0-day exploits live in the wild as we speak
so... valiant attempt in terms of your product... but utterly unsuitable foundation
MagicalTux · 32m ago
As far as I know SGX has no 0-day exploits live today. sgx.fail was the largest collection of attacks and have all been resolved.
What this tells me however is there are a lot of people trying to attack SGX still today, and Intel has improved their response a lot.
The main issue with SGX was that its initial designed use for client-side DRM was flawed by the fact you can't expect normal people to update their BIOS (meaning downloading update, putting it on a storage device, rebooting, going into BIOS, updating, etc) each time an update is pushed (and adoption wasn't good enough for that), it is however having a lot of use server-side for finance, auto industry and others.
We are also planning to support other TEE in the future, SGX is the most well known and battle tested today, with a lot of support by software like openenclave, making it a good initial target.
If you do know of any 0-day exploit currently live on SGX, please give me more details, and if it's something not yet published please contact us directly at security@vp.net
do_not_redeem · 29m ago
> Build the code we published, get the fingerprint it produces, ask a VP.NET server for the fingerprint it reports, and compare the two. If they match, the server is running the exact code you inspected. No trust required.
Okay, maybe I'm being thick, but... when I get a response from your server, how do I know it's actually running inside the enclave, and not an ordinary process sending a hardcoded expected fingerprint?
mrtesthah · 26m ago
No crypto payments or ability to mail cash?
MagicalTux · 22m ago
Yes crypto payments, a bit difficult to find since you need to look at the bottom of the page however, but we have some plans to improve that in the coming days.
ranger_danger · 1h ago
Hard disagree... not only is SGX deprecated and was also removed from recent processors due to security issues IIRC, it still can't prove that your requests are actually being served by the code they say they're running. The machine/keys you get back from their server could be from anywhere and might be completely unrelated.
rkagerer · 34m ago
Looks neat, but how can you tell the fingerprint the server returns was actually generated by the enclave server, and isn't just a hardcoded response to match the expected signature of the published code (or that you're not talking to compromised box that's simply proxying over a signature from a legit, uncompromised SGX container)?
MagicalTux · 27m ago
The enclave fingerprint is generated as part of the attestation.
The way this works is the enclave on launch generates a ECDSA key (which only exists inside the enclave and is never stored or transmitted outside). It then passes it to SGX for attestation. SGX generates a payload (the attestation) which itself contains the enclave measured hash (MRENCLAVE) and other details about the CPU (microcode, BIOS, etc). The whole thing has a signature and a stamped certificate that is issued by Intel to the CPU (the CPU and Intel have an exchange at system startup and from times to times where Intel verifies the CPU security, ensures everything is up to date and gives the CPU a certificate).
Upon connection we extract the attestation from the TLS certificate and verify it (does MRENCLAVE match, is it signed by intel, is the certificate expired, etc) and also of course verify the TLS certificate itself matches the attested public key.
Unless TLS itself is broken or someone manages to exfiltrate the private key from the enclave (which should be impossible unless SGX is broken, but then Intel is supposed to not certify the CPU anymore) the connection is guaranteed to be with a host running the software in question.
ranger_danger · 18m ago
> the connection is guaranteed to be with a host running the software in question
a host... not necessarily the one actually serving your request at the moment, and doesn't prove that it's the only machine touching that data. And afaik this only proves the data in the enclave matches a key, and has nothing to do with "connections".
MagicalTux · 9m ago
Let me clarify, it guarantees your connection is being served by the enclave itself. The TLS encryption keys are kept inside the enclave, so whatever data is exchanged with the host, it can only be read from within the secure encrypted enclave.
rasengan · 11m ago
The attestation guarantees it's the one serving the request, and the encryption/decryption and NAT occurs inside the enclave so it's definitely private.
MagicalTux · 1h ago
SGX's original goal of being used for DVD DRMs has been deprecated because it turns out people don't keep their BIOS up to date and didn't all get Intel's latest CPUs, making the use of SGX as a client side feature not useful. Turns out it's a lot more useful server-side, and while it had its share of issues (see sgx.fail) Intel addressed these (also see sgx.fail). It can prove your requests are actually being served by the code due to the way the TLS attestation works.
tripdout · 1h ago
Wikipedia says it's still on Xeons, so not sure what that says. But I agree with the rest of your point, it seems like an oversight to me.
MagicalTux · 1h ago
Not an oversight, one of SGX's features is MRENCLAVE measurement, a hash of the code running inside the enclave that can be compared with the value obtained at build time.
Personally I like the direction Mullvad went instead. I get that it means we really can't verify Mullvad's claims, but even in the event they're lying, at least we got some cool Coreboot ports out of it.
If you're really paranoid, neither this service nor Mullvad offers that much assurance. I like the idea of verifiability, but I believe the type of people who want it are looking to satisfy deeper paranoia than can be answered with just trusting Intel... Still, more VPN options that try to take privacy claims seriously is nothing to complain about.
As far as I'm aware, no. Any network protocol can be spoofed, with varying degrees of difficulty.
I would love to be wrong.
The final signature comes in the form of a x509 cerificate signed with ECDSA.
What's more important to me is that SGX still has a lot of security researchers attempting (and currently failing) to break it further.
Because of the cryptographic verifications, the communication cannot be spoofed.
A lot of people have been attempting to attack SGX, and while there have been some successful attacks these have been addressed by Intel and resolved. Intel will not attest any insecure configuration as do other TEE vendors (AMD SEV, ARM Trustzone, etc).
This allows generating a self signed TLS certificate that includes the attestation (under OID 1.3.6.1.4.1.311.105.1) and a client connecting verifying the TLS certificate not via the standard chain of trust, but by reading the attestion, verifying the attestation itself is valid (properly signed, matching measured values, etc) and verifying the containing TLS certificate is indeed signed with the attested key.
Intel includes a number of details inside the attestation, the most important being intel's own signature of the attestation and chain of trust to their CA.
In today's internet you just cannot have exit IP which is not tied either into your identity, payment information or physical location. And don't even mention TOR, pls.
Honestly, I feel more comfortable using Mullvad. This team has some folks with questionable backgrounds and I wouldn't trust Intel. Also VPN providers are usually in non-us countries due to things like the Lavabit, Yahoo incidents and the Snowden revelations.
Relying on "trust" in a security/privacy architecture isn't the right way to do things - which is what this solves. It removes the need to trust in a person or person(s) in most VPN company cases since they have many employees, and moves it to trusting in code.
> Also VPN providers are usually in non-us countries due to things like the Lavabit, Yahoo incidents and the Snowden revelations.
The system is designed so that any change server side will be immediately noticed by clients/users. As a result, these issues are sufficiently mitigated, and instead, allows people to take advantage of strong consumer, and personal, protection laws in the US.
Old copy? Might need an update.
The US government also likely learned a lesson from early attempts at backdoors (RSA, etc) that this kind of things do not stay hidden and do not reflect well.
We've thought about this long and hard and planning to mitigate this as much as possible. Meanwhile we still offer something that is a huge step forward compared to what is standard in the industry.
lol
SGX has been broken time and again
SGX has 0-day exploits live in the wild as we speak
so... valiant attempt in terms of your product... but utterly unsuitable foundation
What this tells me however is there are a lot of people trying to attack SGX still today, and Intel has improved their response a lot.
The main issue with SGX was that its initial designed use for client-side DRM was flawed by the fact you can't expect normal people to update their BIOS (meaning downloading update, putting it on a storage device, rebooting, going into BIOS, updating, etc) each time an update is pushed (and adoption wasn't good enough for that), it is however having a lot of use server-side for finance, auto industry and others.
We are also planning to support other TEE in the future, SGX is the most well known and battle tested today, with a lot of support by software like openenclave, making it a good initial target.
If you do know of any 0-day exploit currently live on SGX, please give me more details, and if it's something not yet published please contact us directly at security@vp.net
Okay, maybe I'm being thick, but... when I get a response from your server, how do I know it's actually running inside the enclave, and not an ordinary process sending a hardcoded expected fingerprint?
The way this works is the enclave on launch generates a ECDSA key (which only exists inside the enclave and is never stored or transmitted outside). It then passes it to SGX for attestation. SGX generates a payload (the attestation) which itself contains the enclave measured hash (MRENCLAVE) and other details about the CPU (microcode, BIOS, etc). The whole thing has a signature and a stamped certificate that is issued by Intel to the CPU (the CPU and Intel have an exchange at system startup and from times to times where Intel verifies the CPU security, ensures everything is up to date and gives the CPU a certificate).
Upon connection we extract the attestation from the TLS certificate and verify it (does MRENCLAVE match, is it signed by intel, is the certificate expired, etc) and also of course verify the TLS certificate itself matches the attested public key.
Unless TLS itself is broken or someone manages to exfiltrate the private key from the enclave (which should be impossible unless SGX is broken, but then Intel is supposed to not certify the CPU anymore) the connection is guaranteed to be with a host running the software in question.
a host... not necessarily the one actually serving your request at the moment, and doesn't prove that it's the only machine touching that data. And afaik this only proves the data in the enclave matches a key, and has nothing to do with "connections".