3 ms·

Check the client debug logs mine has the verification for the enclaves in it although I'm on an intel i3 but that makes sense for Intel's remote attestation tha

Check the client debug logs mine has the verification for the enclaves in it although I'm on an intel i3 but that makes sense for Intel's remote attestation that its verifying the enclave's unique hash and showing the MRENCLAVE hexes of the expected result.

phillipseamore 1y ago
But without the source being available you still need to trust vp.net to be providing the correct hash to compare to, right?
- deleted 1y ago
  [deleted]
- eGQjxkKF6fif 1y ago
  Intel's remote attestation verifies that, with the hash you can use Intel's remote API which is what the client is doing, Intel gets the hash the server sends, verifies it using their encrypted key set and then tells the client that it's valid and verified. Not all processors have SGX capability to verify the hash. Intel provides tools to do the manual verification if you utilize SGX https://www.intel.com/content/www/us/en/developer/tools/software-guard-extensions/get-started.html https://www.intel.com/content/www/us/en/developer/tools/soft... So you can verify locally and Intel's API also does the verification. When an SGX Encalve is created, the private key to it goes within it, it can't be accessed. That's the security. It's a good read if you look in to the tech on Intel's website.
  - phillipseamore 1y ago
    It verifies that something is running in the enclave. Without the source you can't hash it yourself (don't need an SGX capable system for that, just the SDK) to verify that it's the actual code running.
    - eGQjxkKF6fif 1y ago
      it would be verifying that WireGuard (https://www.wireguard.com/repositories/ https://www.wireguard.com/repositories/) is within the enclave, yeah?
      - phillipseamore 1y ago
        Have no idea since there isn't any code available for review. Technically what's running in SGX could just be what's enough for it to attest to it's existence [sidenote: how can I be sure this is even the SGX handling my connection and not just any SGX?]. I really like this idea but even if the code was available most users are still just trusting vp.net (won't be doing their own verification [and doing it everytime the hash has changed] but trusting vp.net's own claims in their own client, it's similar to the criticism of many E2EE messaging solutions, everything might be fine over the wire but I'm trusting their client not to collect or transmit anything before encryption or after decryption). If I could build my own client and lock it down to a hash of published SGX code then I'd be happier, or perhaps if an external party would handle the verification. Looking forward to explore this better when any code is made available.

phillipseamore 1y ago

But without the source being available you still need to trust vp.net to be providing the correct hash to compare to, right?

deleted 1y ago
[deleted]
eGQjxkKF6fif 1y ago
Intel's remote attestation verifies that, with the hash you can use Intel's remote API which is what the client is doing, Intel gets the hash the server sends, verifies it using their encrypted key set and then tells the client that it's valid and verified. Not all processors have SGX capability to verify the hash. Intel provides tools to do the manual verification if you utilize SGX https://www.intel.com/content/www/us/en/developer/tools/software-guard-extensions/get-started.html https://www.intel.com/content/www/us/en/developer/tools/soft... So you can verify locally and Intel's API also does the verification. When an SGX Encalve is created, the private key to it goes within it, it can't be accessed. That's the security. It's a good read if you look in to the tech on Intel's website.
- phillipseamore 1y ago
  It verifies that something is running in the enclave. Without the source you can't hash it yourself (don't need an SGX capable system for that, just the SDK) to verify that it's the actual code running.
  - eGQjxkKF6fif 1y ago
    it would be verifying that WireGuard (https://www.wireguard.com/repositories/ https://www.wireguard.com/repositories/) is within the enclave, yeah?
    - phillipseamore 1y ago
      Have no idea since there isn't any code available for review. Technically what's running in SGX could just be what's enough for it to attest to it's existence [sidenote: how can I be sure this is even the SGX handling my connection and not just any SGX?]. I really like this idea but even if the code was available most users are still just trusting vp.net (won't be doing their own verification [and doing it everytime the hash has changed] but trusting vp.net's own claims in their own client, it's similar to the criticism of many E2EE messaging solutions, everything might be fine over the wire but I'm trusting their client not to collect or transmit anything before encryption or after decryption). If I could build my own client and lock it down to a hash of published SGX code then I'd be happier, or perhaps if an external party would handle the verification. Looking forward to explore this better when any code is made available.