6 ms·

Authenticated encryption isn't the same as signing encrypted data. Even when you don't generally care about the properties digital signatures provide you almos

by nullc 6y ago

Authenticated encryption isn't the same as signing encrypted data. Even when you don't generally care about the properties digital signatures provide you almost always need authentication w/ encryption because block cipher modes make the behaviour of the encryption differ in surprising and important ways from an idealized black box. Concretely: Imagine I setup a service that accepts commands through encrypted messages with a static key. Only authorized parties know the keys. Each (encrypted) command sent to the services includes a user and password. At first glance you might consider this setup reasonably secure but if authenticated encryption is not used a MITM can modify the ciphertext to cause predictable modifications to the plain text, preserving the user and password but changing the command or its parameters. Eg. Imagine the cipher used is AES-CTR, the attacker can just xor whatever he wants into the plaintext. If a CBC mode is used, the attacker has a little less flexibility but still a lot. Beyond breaking control the lack of authentication can also break confidentiality: For example, if the service provides different error behaviours for different corrupted inputs, I could replay a message with many different corruptions to determine it's content. Yes, if you augmented this protocol with a digital signature it could accomplish authentication (if implemented correctly!); but since the protocol has no particular need for a digital signature otherwise the signature is an extremely slow way to accomplish authenticated encryption (compared to a proper authenticated encryption mode). An authenticated block cipher mode can be made pretty much just as fast as unauthenticated (at least for longer messages, and only (say) a 2x slow down for the shortest messages... one or more orders magnitude better than a digital signature). It is very hard to design secure cryptographic protocols and systems and even harder to have a good basis to believe that they're secure. Whenever the primitives we use have subtle behaviour that differs from an idealized version that job becomes significantly harder. Authenticated encryption works a lot more like a simple black box "ideal encryption" than non-authenticated ciphers. Secure systems could use either, but non-auth is a LOT easier to end up with an insecure protocol by surprise.

PowerBar 6y ago
And that doesn't even touch on replay attacks. If you have a door lock that accepts "lock", "unlock" and "report status", a MITM attacker only needs to capture the encrypted & signed "unlock" command, then replay it later. Many workarounds were developed to mitigate this such as random values, incrementing values and timestamps, but most were found insecure. Challenge-response systems with a short validity period are one of the better systems in use, but require bi-directional communication which can make some products (ex: garage door openers) more expensive.
- davidhyde 6y ago
  What about using a time based one time password algorithm instead of a challenge-response mechanism? Most embedded systems have a real time clock. Would it make sense to use this technology for that? https://en.m.wikipedia.org/wiki/Time-based_One-time_Password_algorithm https://en.m.wikipedia.org/wiki/Time-based_One-time_Password...
  - cybergibbons 6y ago
    RTCs are actually quite rare, especially in a lot of the lower power RF SoCs. Drift would also be an issue - most move at least 10 minutes a year. That's with good temperatures, not being left in a hot car or at body temp. If you could solve the drift issue then it would be pretty good I think, it's an interesting idea.
    - davidhyde 6y ago
      Maybe you could use the secure connection to resync the time or some other clock with the authenticated server. I guess that’s just another request / response type of arrangement though. And then any breakdown of communication for an extended period of time would brick the whole thing. EDIT: Maybe the time based one time password algorithm can be configured to be made less time granular (say daily) so that it can handle clock drift.
- renewiltord 6y ago
  Actually, why doesn't signing a time-stamped unlock work?
  - PowerBar 6y ago
    That's one of the other popular strategies, but relies on both devices have accurate clocks. With computers and servers (where the strategy is used quite a bit, sometimes in combination with challenge-response), it's quite easy. If you're working with something non-networked or battery powered like a garage door opener, clock drift becomes a serious issue.
ianmiers 6y ago
Secure systems cannot use either a signature or authenticated encryption. Signing a message is not sufficient to prevent tampering that leads to an attacker reading the message by seeing errors in processing the tampered message. You need either authenticated encryption or signcryption. Suppose your format is ciphertext || signature. An attacker can strip off the signature, modify the ciphertext, and then sign the modified ciphertext as coming from an attacker controlled account. The recipient will then accept the ciphertext, decrypt it, and parse it. Errors on decrypting or parsing induced by mutations can then be used to get the plaintext. This isn't theoretical. It happened to iMessage[1] and GPG[2] And no, you cannot just include the sender inside the ciphertext. iMessage tried that. It didn't work. In general, there are two problems 1) the ciphertext is malleable and the id can be changed. 2) the error could happen before you can read the sender id from the ciphertext. Signing and authenticated encryption really don't do the same thing. [1]https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_garman.pdf https://www.usenix.org/system/files/conference/usenixsecurit... [2]https://efail.de/ https://efail.de/
- kerng 6y ago
  Isn't that why HMAC exists?
- upofadown 6y ago
  This is the best example of an attack against PGP encryption malleability that I have come across. It uses the modification to enhance social engineering and make it more likely you could get someone to decrypt a message and then return the decrypted message to them: * https://www.schneier.com/academic/archives/2000/08/a_chosen_ciphertext.html https://www.schneier.com/academic/archives/2000/08/a_chosen_... EFAIL is a poor example of this sort of thing. EFAIL was based on the information leak from HTML emails. The malleable encryption angle was quite forced: * https://articles.59.ca/doku.php?id=pgpfan:efail https://articles.59.ca/doku.php?id=pgpfan:efail In an email context a missing signature or a signature from someone you do not know counts as an invalid signature. A signature does in fact detect both of these to the extent that authenticated encryption could. >Errors on decrypting or parsing induced by mutations can then be used to get the plaintext. That sort of oracle attack can't really work in practice with a one way medium like email.

by nullc 6y ago

PowerBar 6y ago

And that doesn't even touch on replay attacks. If you have a door lock that accepts "lock", "unlock" and "report status", a MITM attacker only needs to capture the encrypted & signed "unlock" command, then replay it later. Many workarounds were developed to mitigate this such as random values, incrementing values and timestamps, but most were found insecure. Challenge-response systems with a short validity period are one of the better systems in use, but require bi-directional communication which can make some products (ex: garage door openers) more expensive.

davidhyde 6y ago
What about using a time based one time password algorithm instead of a challenge-response mechanism? Most embedded systems have a real time clock. Would it make sense to use this technology for that? https://en.m.wikipedia.org/wiki/Time-based_One-time_Password_algorithm https://en.m.wikipedia.org/wiki/Time-based_One-time_Password...
- cybergibbons 6y ago
  RTCs are actually quite rare, especially in a lot of the lower power RF SoCs. Drift would also be an issue - most move at least 10 minutes a year. That's with good temperatures, not being left in a hot car or at body temp. If you could solve the drift issue then it would be pretty good I think, it's an interesting idea.
  - davidhyde 6y ago
    Maybe you could use the secure connection to resync the time or some other clock with the authenticated server. I guess that’s just another request / response type of arrangement though. And then any breakdown of communication for an extended period of time would brick the whole thing. EDIT: Maybe the time based one time password algorithm can be configured to be made less time granular (say daily) so that it can handle clock drift.
renewiltord 6y ago
Actually, why doesn't signing a time-stamped unlock work?
- PowerBar 6y ago
  That's one of the other popular strategies, but relies on both devices have accurate clocks. With computers and servers (where the strategy is used quite a bit, sometimes in combination with challenge-response), it's quite easy. If you're working with something non-networked or battery powered like a garage door opener, clock drift becomes a serious issue.

ianmiers 6y ago

Secure systems cannot use either a signature or authenticated encryption. Signing a message is not sufficient to prevent tampering that leads to an attacker reading the message by seeing errors in processing the tampered message. You need either authenticated encryption or signcryption. Suppose your format is ciphertext || signature. An attacker can strip off the signature, modify the ciphertext, and then sign the modified ciphertext as coming from an attacker controlled account. The recipient will then accept the ciphertext, decrypt it, and parse it. Errors on decrypting or parsing induced by mutations can then be used to get the plaintext. This isn't theoretical. It happened to iMessage[1] and GPG[2] And no, you cannot just include the sender inside the ciphertext. iMessage tried that. It didn't work. In general, there are two problems 1) the ciphertext is malleable and the id can be changed. 2) the error could happen before you can read the sender id from the ciphertext. Signing and authenticated encryption really don't do the same thing. [1]https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_garman.pdf https://www.usenix.org/system/files/conference/usenixsecurit... [2]https://efail.de/ https://efail.de/

kerng 6y ago
Isn't that why HMAC exists?
upofadown 6y ago
This is the best example of an attack against PGP encryption malleability that I have come across. It uses the modification to enhance social engineering and make it more likely you could get someone to decrypt a message and then return the decrypted message to them: * https://www.schneier.com/academic/archives/2000/08/a_chosen_ciphertext.html https://www.schneier.com/academic/archives/2000/08/a_chosen_... EFAIL is a poor example of this sort of thing. EFAIL was based on the information leak from HTML emails. The malleable encryption angle was quite forced: * https://articles.59.ca/doku.php?id=pgpfan:efail https://articles.59.ca/doku.php?id=pgpfan:efail In an email context a missing signature or a signature from someone you do not know counts as an invalid signature. A signature does in fact detect both of these to the extent that authenticated encryption could. >Errors on decrypting or parsing induced by mutations can then be used to get the plaintext. That sort of oracle attack can't really work in practice with a one way medium like email.