6 ms·

Signatures: Modern End-to-End Encryption

46 points by signa11 5y ago

bsaul 5y ago
in their last point, they forgot that not only can the device be compromised, but app stores can too. You have to trust everyone from hardware manufacturers to software maker to software distribution channel, to not add some form of spying features that would render the e2e algorithm basically useless.
- supermatt 5y ago
  In theory your app is signed with your (private) key, so it should be tamper resistant from that perspective. Of course, it is those same stores that issue the certs used for "trusted" verification, so they could reissue a new one, resign accordingly and noone would know unless they manually verified the cert with the developer. Maybe that shouldn't be a thing ;)
  - bawolff 5y ago
    However the primary selling point of end2end encryption (as opposed to normal encryption) is what if the app creator is evil? But then we end up having to trust the app creator's code anyways.
    - morjom 5y ago
      Wouldn't open-source and/or auditing alleviate this?
      - supermatt 5y ago
        You would need reproducible builds and to manually verify the hash of the respective application bundle. But even then you need to trust the device to actually execute THAT bundle, of course... And even if it did, it could change its behaviour at runtime. Dont forget you are also trusting many layers below the app itself: Hardware design and manufacture, device manufacturers, distributers and vendors, the OS (and the 3rd party libs they depend on) developers and distributers, the underlying application libs, frameworks and runtime, the application notaries and distributers, etc. At any point there could be bugs/vulnerabilities/backdoors/etc.
    - supermatt 5y ago
      My example demonstrates that the app creator doesnt need to be evil. The store can be evil, and for end-user its very difficult to know.
      - bawolff 5y ago
        If apple was evil, i think they would just put a rootkit on your phone. Seems easier and more effective than compromising their app store.
        supermatt 5y ago
        I mention elsewhere in this thread that there are many layers that can do this sort of attack. Also, this same issue applies on android, where you can have stores not owned by the OS vendor.
- sylvain_kerkour 5y ago
  Good point thanks! I've updated the conclusion to better reflect that at the end of the day we still have to trust some third-parties, and this is where Open Source comes into play to bring transparency and accountability about what runs on our devices.
deleted 5y ago
[deleted]
sylvain_kerkour 5y ago
Hi author here, Happy to see this here :) The original title of the post was "Signatures: the secret behind Modern End-to-End Encryption" but it seems that HN filtered "the secret behind". With hindsight it seems that indeed the formulation was a little bit too "clickbaity" so I updated the title to "Signatures: The foundations of modern end-to-end encryption"
formerly_proven 5y ago
Signatures only appear in the Signal protocol for prekeys, which allow limited asynchrony [1]. Signatures are not necessary for synchronous E2E with PFS. [1] The basic PFS key exchange is a triple DH: ee, es, se (e=ephemeral key, s=static key). This is obviously a synchronous protocol, because the ephemeral keys need to be exchanged for the handshake. X3DH works around this by publishing a bunch of unused ephemeral keys in advance. Those are signed. Note that the signature is not necessary for the protocol to be secure per se, the triple DH gives you mutual authentication already. The signature is only there to prevent the prekey-exchange-server from publishing prekeys for arbitrary clients and then decrypting initial messages using those ephemeral prekeys after compromising the corresponding static key. So the purpose of the signature is to close a loophole weakening PFS when you publish ephemeral keys in advance. X3DH also has a few other subtleties due to this, so it should only be used if you really need an asynchronous handshake. Otherwise, normal triple DH (Noise_XX) should be used instead.
- upofadown 5y ago
  >Signatures only appear in the Signal protocol for prekeys... Correct me if I am wrong (Signal protocol is pretty complicated), but doesn't the triple DH take a long term identity factor as an input? So in a sense the signature is built in. The result is logically the same as signing a DH exchange.
  - supermatt 5y ago
    the prekeys are to establish the ratchet, which is distinct from the identity. They are signed by the identity so that they can be verified.
    - upofadown 5y ago
      No, not the prekeys. I meant the triple DH itself. I think my comment/question might of been confused. It appears that in practice Signal only uses prekeys to start things off. The prekeys are just signed chunks of the triple DH just stored somewhere for a time. So from that I conclude that Signal does in fact use signatures just like any other public key messaging system. The issue is fundamental after all...
_wldu 5y ago
Should we assume that all cell phones are compromised (or can be by nation states and cyber criminals whenever they like)? I believe we should. That assumption implies that they have access to private/secret keys on our phones. How do you build software to be secure and private in that scenario?
- deleted 5y ago
  [deleted]
- supermatt 5y ago
  You run it in an environment that you DO trust - i.e. a TEE (Trusted Execution Environment). This can be a separate device (physically attached or networked), integrated hardware (e.g. IME/SEP/etc), or some form of isolation built into the hardware (e.g. SGX/PSP/etc). But this has major limitations - especially if you are trying to communicate from an untrusted layer, as it can still be intercepted. Only what happens INSIDE the TEE is secure, and theres no guarantee you are even communicating with it. This is why they are generally only used for verification, secured RNG (including OTP), protected decryption of insensitive data (i.e. DRM), etc. Basically where you dont particularly care about the input or output (or both), just that the operation itself needs to be secure.

46 points by signa11 5y ago

in their last point, they forgot that not only can the device be compromised, but app stores can too. You have to trust everyone from hardware manufacturers to software maker to software distribution channel, to not add some form of spying features that would render the e2e algorithm basically useless.

supermatt 5y ago
In theory your app is signed with your (private) key, so it should be tamper resistant from that perspective. Of course, it is those same stores that issue the certs used for "trusted" verification, so they could reissue a new one, resign accordingly and noone would know unless they manually verified the cert with the developer. Maybe that shouldn't be a thing ;)
- bawolff 5y ago
  However the primary selling point of end2end encryption (as opposed to normal encryption) is what if the app creator is evil? But then we end up having to trust the app creator's code anyways.
  - morjom 5y ago
    Wouldn't open-source and/or auditing alleviate this?
    - supermatt 5y ago
      You would need reproducible builds and to manually verify the hash of the respective application bundle. But even then you need to trust the device to actually execute THAT bundle, of course... And even if it did, it could change its behaviour at runtime. Dont forget you are also trusting many layers below the app itself: Hardware design and manufacture, device manufacturers, distributers and vendors, the OS (and the 3rd party libs they depend on) developers and distributers, the underlying application libs, frameworks and runtime, the application notaries and distributers, etc. At any point there could be bugs/vulnerabilities/backdoors/etc.
  - supermatt 5y ago
    My example demonstrates that the app creator doesnt need to be evil. The store can be evil, and for end-user its very difficult to know.
    - bawolff 5y ago
      If apple was evil, i think they would just put a rootkit on your phone. Seems easier and more effective than compromising their app store.
      - supermatt 5y ago
        I mention elsewhere in this thread that there are many layers that can do this sort of attack. Also, this same issue applies on android, where you can have stores not owned by the OS vendor.
sylvain_kerkour 5y ago
Good point thanks! I've updated the conclusion to better reflect that at the end of the day we still have to trust some third-parties, and this is where Open Source comes into play to bring transparency and accountability about what runs on our devices.

deleted 5y ago

[deleted]

sylvain_kerkour 5y ago

Hi author here, Happy to see this here :) The original title of the post was "Signatures: the secret behind Modern End-to-End Encryption" but it seems that HN filtered "the secret behind". With hindsight it seems that indeed the formulation was a little bit too "clickbaity" so I updated the title to "Signatures: The foundations of modern end-to-end encryption"

formerly_proven 5y ago

Signatures only appear in the Signal protocol for prekeys, which allow limited asynchrony [1]. Signatures are not necessary for synchronous E2E with PFS. [1] The basic PFS key exchange is a triple DH: ee, es, se (e=ephemeral key, s=static key). This is obviously a synchronous protocol, because the ephemeral keys need to be exchanged for the handshake. X3DH works around this by publishing a bunch of unused ephemeral keys in advance. Those are signed. Note that the signature is not necessary for the protocol to be secure per se, the triple DH gives you mutual authentication already. The signature is only there to prevent the prekey-exchange-server from publishing prekeys for arbitrary clients and then decrypting initial messages using those ephemeral prekeys after compromising the corresponding static key. So the purpose of the signature is to close a loophole weakening PFS when you publish ephemeral keys in advance. X3DH also has a few other subtleties due to this, so it should only be used if you really need an asynchronous handshake. Otherwise, normal triple DH (Noise_XX) should be used instead.

upofadown 5y ago
>Signatures only appear in the Signal protocol for prekeys... Correct me if I am wrong (Signal protocol is pretty complicated), but doesn't the triple DH take a long term identity factor as an input? So in a sense the signature is built in. The result is logically the same as signing a DH exchange.
- supermatt 5y ago
  the prekeys are to establish the ratchet, which is distinct from the identity. They are signed by the identity so that they can be verified.
  - upofadown 5y ago
    No, not the prekeys. I meant the triple DH itself. I think my comment/question might of been confused. It appears that in practice Signal only uses prekeys to start things off. The prekeys are just signed chunks of the triple DH just stored somewhere for a time. So from that I conclude that Signal does in fact use signatures just like any other public key messaging system. The issue is fundamental after all...

_wldu 5y ago

Should we assume that all cell phones are compromised (or can be by nation states and cyber criminals whenever they like)? I believe we should. That assumption implies that they have access to private/secret keys on our phones. How do you build software to be secure and private in that scenario?

deleted 5y ago
[deleted]
supermatt 5y ago
You run it in an environment that you DO trust - i.e. a TEE (Trusted Execution Environment). This can be a separate device (physically attached or networked), integrated hardware (e.g. IME/SEP/etc), or some form of isolation built into the hardware (e.g. SGX/PSP/etc). But this has major limitations - especially if you are trying to communicate from an untrusted layer, as it can still be intercepted. Only what happens INSIDE the TEE is secure, and theres no guarantee you are even communicating with it. This is why they are generally only used for verification, secured RNG (including OTP), protected decryption of insensitive data (i.e. DRM), etc. Basically where you dont particularly care about the input or output (or both), just that the operation itself needs to be secure.