4 ms·

> Whether or not Signal's server is open source has nothing to do with security This true only when you are exclusively concerned about your messages' content

> Whether or not Signal's server is open source has nothing to do with security This true only when you are exclusively concerned about your messages' content but not about the metadata. As we all know, though, the metadata is the valuable stuff. There is a second reason it is wrong, though: These days, lots of actual user data (i.e. != metadata) gets uploaded to the Signal servers[0] and encrypted with the user's Signal PIN (modulo some key derivation function). Unfortunately, many users choose an insecure PIN, not a passphrase with lots of entropy, so the derived encryption key isn't particularly strong. (IMO it doesn't help that it's called a PIN. They should rather call it "ultra-secure master passphrase".) This is where a technology called Intel SGX comes into play: It provides remote attestation that the code running on the servers is the real deal, i.e. the trusted and verified code, and not the code with the added backdoor. So yes, the server code does need to be published and verified. Finally, let's not forget the fact that SGX doesn't seem particularly secure, either[1], so it's even more important that the Signal developers be open about the server code. [0]: https://signal.org/blog/secure-value-recovery/ https://signal.org/blog/secure-value-recovery/ [1]: https://blog.cryptographyengineering.com/2020/07/10/a-few-thoughts-about-signals-secure-value-recovery/ https://blog.cryptographyengineering.com/2020/07/10/a-few-th...

codethief 6y ago
Addendum: Out of pure interest I just went into a deep dive into the Signal-Android repository and tried to figure out where exactly the SGX remote attestation happens. I figured that somewhere in the app there should be hash or something of the code running on the servers. Unfortunately, `rg -i SGX` only yielded the following two pieces of code: https://github.com/signalapp/Signal-Android/blob/master/libsignal/service/src/main/java/org/whispersystems/signalservice/internal/contacts/crypto/SigningCertificate.java#L72 https://github.com/signalapp/Signal-Android/blob/master/libs... https://github.com/signalapp/Signal-Android/blob/master/libsignal/service/src/main/java/org/whispersystems/signalservice/internal/contacts/crypto/Quote.java#L8 https://github.com/signalapp/Signal-Android/blob/master/libs... No immediate sign of a fixed hash. Instead, it looks like the code only verifies the certificate chain of some signature? How does this help if we want to verify the server is running a specific version of the code and we cannot trust the certificate issuer (whether it's Intel or Signal)? I'm probably (hopefully) wrong here, so maybe someone else who's more familiar with the code could chime in here and explain this to me? :)
- deleted 6y ago
  [deleted]
- corbiqula 6y ago
  The hash of the code that is running in the enclave is called "MRENCLAVE" in SGX. During remote attestation, the prover (here, Signal's server) create a "quote" that proves it is running a genuine enclave. The quote also includes the MRENCLAVE value. It sends the quote to the verifier (here, Signal-Andriod), which in turn sends it to Intel Attestation Service (IAS). IAS verifies the quote, then signs the content of the quote, thus signing the MRENCLAVE value. The digital signature is sent back to the verifier. Assuming that the verifier trusts IAS's public key (e.g., through a certificate), it can verify the digital signature, thus trust the MRENCLAVE value is valid. The code where the verifier is verifying the IAS signature is here: https://github.com/signalapp/Signal-Android/blob/6ddfbcb94510fdef91ca3ce81ae8f8c0d5adf261/libsignal/service/src/main/java/org/whispersystems/signalservice/internal/contacts/crypto/RemoteAttestationCipher.java#L56 https://github.com/signalapp/Signal-Android/blob/6ddfbcb9451... The code where the MRENCLAVE value is checked is here: https://github.com/signalapp/Signal-Android/blob/6ddfbcb94510fdef91ca3ce81ae8f8c0d5adf261/libsignal/service/src/main/java/org/whispersystems/signalservice/internal/contacts/crypto/RemoteAttestationCipher.java#L44 https://github.com/signalapp/Signal-Android/blob/6ddfbcb9451... Hope this helps!
  - codethief 6y ago
    Thank you, this indeed helps a lot and I've now found the hashes![1] Moreover, thank you for providing me with some additional keywords that I could google for – this made it much easier to follow the SGX 101 "book"[0] and I think I've got a much better grasp now on how SGX works! [0]: https://sgx101.gitbook.io/sgx101/sgx-bootstrap/attestation#remote-attestation-primitives https://sgx101.gitbook.io/sgx101/sgx-bootstrap/attestation#r... [1]: For other people interested in this matter: I've followed the path of the MRENCLAVE variable to the very end, https://github.com/signalapp/Signal-Android/blob/6ddfbcb94510fdef91ca3ce81ae8f8c0d5adf261/app/src/main/java/org/thoughtcrime/securesms/pin/KbsEnclaves.java#L13 https://github.com/signalapp/Signal-Android/blob/6ddfbcb9451... where it gets injected by the build config. The build config, in turn, is available here: https://github.com/signalapp/Signal-Android/blob/6ddfbcb94510fdef91ca3ce81ae8f8c0d5adf261/app/build.gradle https://github.com/signalapp/Signal-Android/blob/6ddfbcb9451... (The MRENCLAVE values can be found around line 120.)
wolverine876 6y ago
> These days, lots of actual user data (i.e. != metadata) gets uploaded to the Signal servers[0] and encrypted with the user's Signal PIN (modulo some key derivation function). Unfortunately, many users choose an insecure PIN, not a passphrase with lots of entropy, so the derived encryption key isn't particularly strong. If I understand what you are saying and what Signal says, Signal anticipates this problem and provides a solution that is arguably optimal: https://signal.org/blog/secure-value-recovery/ https://signal.org/blog/secure-value-recovery/ My (limited) understanding is that the master key consists of the user PIN plus c2, a 256 bit code generated by a secure RNG, and that the Signal client uses a key derivation function to maximize the master key's entropy. c2 is stored in SGX on Signal's servers. If the user PIN is sufficiently secure, c2's security won't matter - an attacker with c2 still can't bypass the PIN. If the PIN is not sufficiently secure, as often happens, c2 stored in SGX might be the most secure way to augment it while still making the the data recoverable. I'd love to hear from a security specialist regarding this scheme. I'm not one and I had only limited time to study the link above.
- codethief 6y ago
  > If I understand what you are saying and what Signal says, Signal anticipates this problem and provides a solution that is arguably optimal Yep, this is what I meant when I said "This is where a technology called Intel SGX comes into play". :) And you're right, SGX is better than nothing if you accept that people use insecure PINs. My argument mainly was that - the UI is designed in the worst possible way and actually encourages people to choose a short insecure PIN instead of recommending a longer one. This means that security guarantees suddenly rest entirely on SGX. - SGX requires the server code to be verified and published (which it wasn't until yesterday). Without verification, it's all pointless. > uses a key derivation function to maximize the master key's entropy Nitpick: Technically, the KDF is deterministic, so it cannot change the entropy and – as the article says – you could still brute-force short PINs (if it weren't for SGX). > I'd love to hear from a security specialist regarding this scheme. I'm not one and I had only limited time to study the link above. Have a look at link [1] in my previous comment. :)
im3w1l 6y ago
SGX is just the processor pinky swearing (signed with Intel keys) that everything is totally legit. Nation State Adversaries can and will take Intel's keys and lie.
- codethief 6y ago
  SGX is also supposed to protect against Signal as a potential adversary, though, as well as against hackers. Or at least that's how I understood the blog article.

codethief 6y ago

Addendum: Out of pure interest I just went into a deep dive into the Signal-Android repository and tried to figure out where exactly the SGX remote attestation happens. I figured that somewhere in the app there should be hash or something of the code running on the servers. Unfortunately, `rg -i SGX` only yielded the following two pieces of code: https://github.com/signalapp/Signal-Android/blob/master/libsignal/service/src/main/java/org/whispersystems/signalservice/internal/contacts/crypto/SigningCertificate.java#L72 https://github.com/signalapp/Signal-Android/blob/master/libs... https://github.com/signalapp/Signal-Android/blob/master/libsignal/service/src/main/java/org/whispersystems/signalservice/internal/contacts/crypto/Quote.java#L8 https://github.com/signalapp/Signal-Android/blob/master/libs... No immediate sign of a fixed hash. Instead, it looks like the code only verifies the certificate chain of some signature? How does this help if we want to verify the server is running a specific version of the code and we cannot trust the certificate issuer (whether it's Intel or Signal)? I'm probably (hopefully) wrong here, so maybe someone else who's more familiar with the code could chime in here and explain this to me? :)

deleted 6y ago
[deleted]
corbiqula 6y ago
The hash of the code that is running in the enclave is called "MRENCLAVE" in SGX. During remote attestation, the prover (here, Signal's server) create a "quote" that proves it is running a genuine enclave. The quote also includes the MRENCLAVE value. It sends the quote to the verifier (here, Signal-Andriod), which in turn sends it to Intel Attestation Service (IAS). IAS verifies the quote, then signs the content of the quote, thus signing the MRENCLAVE value. The digital signature is sent back to the verifier. Assuming that the verifier trusts IAS's public key (e.g., through a certificate), it can verify the digital signature, thus trust the MRENCLAVE value is valid. The code where the verifier is verifying the IAS signature is here: https://github.com/signalapp/Signal-Android/blob/6ddfbcb94510fdef91ca3ce81ae8f8c0d5adf261/libsignal/service/src/main/java/org/whispersystems/signalservice/internal/contacts/crypto/RemoteAttestationCipher.java#L56 https://github.com/signalapp/Signal-Android/blob/6ddfbcb9451... The code where the MRENCLAVE value is checked is here: https://github.com/signalapp/Signal-Android/blob/6ddfbcb94510fdef91ca3ce81ae8f8c0d5adf261/libsignal/service/src/main/java/org/whispersystems/signalservice/internal/contacts/crypto/RemoteAttestationCipher.java#L44 https://github.com/signalapp/Signal-Android/blob/6ddfbcb9451... Hope this helps!
- codethief 6y ago
  Thank you, this indeed helps a lot and I've now found the hashes![1] Moreover, thank you for providing me with some additional keywords that I could google for – this made it much easier to follow the SGX 101 "book"[0] and I think I've got a much better grasp now on how SGX works! [0]: https://sgx101.gitbook.io/sgx101/sgx-bootstrap/attestation#remote-attestation-primitives https://sgx101.gitbook.io/sgx101/sgx-bootstrap/attestation#r... [1]: For other people interested in this matter: I've followed the path of the MRENCLAVE variable to the very end, https://github.com/signalapp/Signal-Android/blob/6ddfbcb94510fdef91ca3ce81ae8f8c0d5adf261/app/src/main/java/org/thoughtcrime/securesms/pin/KbsEnclaves.java#L13 https://github.com/signalapp/Signal-Android/blob/6ddfbcb9451... where it gets injected by the build config. The build config, in turn, is available here: https://github.com/signalapp/Signal-Android/blob/6ddfbcb94510fdef91ca3ce81ae8f8c0d5adf261/app/build.gradle https://github.com/signalapp/Signal-Android/blob/6ddfbcb9451... (The MRENCLAVE values can be found around line 120.)

wolverine876 6y ago

> These days, lots of actual user data (i.e. != metadata) gets uploaded to the Signal servers[0] and encrypted with the user's Signal PIN (modulo some key derivation function). Unfortunately, many users choose an insecure PIN, not a passphrase with lots of entropy, so the derived encryption key isn't particularly strong. If I understand what you are saying and what Signal says, Signal anticipates this problem and provides a solution that is arguably optimal: https://signal.org/blog/secure-value-recovery/ https://signal.org/blog/secure-value-recovery/ My (limited) understanding is that the master key consists of the user PIN plus c2, a 256 bit code generated by a secure RNG, and that the Signal client uses a key derivation function to maximize the master key's entropy. c2 is stored in SGX on Signal's servers. If the user PIN is sufficiently secure, c2's security won't matter - an attacker with c2 still can't bypass the PIN. If the PIN is not sufficiently secure, as often happens, c2 stored in SGX might be the most secure way to augment it while still making the the data recoverable. I'd love to hear from a security specialist regarding this scheme. I'm not one and I had only limited time to study the link above.

codethief 6y ago
> If I understand what you are saying and what Signal says, Signal anticipates this problem and provides a solution that is arguably optimal Yep, this is what I meant when I said "This is where a technology called Intel SGX comes into play". :) And you're right, SGX is better than nothing if you accept that people use insecure PINs. My argument mainly was that - the UI is designed in the worst possible way and actually encourages people to choose a short insecure PIN instead of recommending a longer one. This means that security guarantees suddenly rest entirely on SGX. - SGX requires the server code to be verified and published (which it wasn't until yesterday). Without verification, it's all pointless. > uses a key derivation function to maximize the master key's entropy Nitpick: Technically, the KDF is deterministic, so it cannot change the entropy and – as the article says – you could still brute-force short PINs (if it weren't for SGX). > I'd love to hear from a security specialist regarding this scheme. I'm not one and I had only limited time to study the link above. Have a look at link [1] in my previous comment. :)

im3w1l 6y ago

SGX is just the processor pinky swearing (signed with Intel keys) that everything is totally legit. Nation State Adversaries can and will take Intel's keys and lie.

codethief 6y ago
SGX is also supposed to protect against Signal as a potential adversary, though, as well as against hackers. Or at least that's how I understood the blog article.