7 ms·

Digital signatures and how to avoid them

278 points by _ikke_ 2y ago

sandij 2y ago
This article is very relevant in the context of the EU Digital Identity Wallet, and digital credentials in general, such as ISO/IEC 18013-5 mobile driver licenses and other mdocs. We may accidentially end up with non-repudiation of attribute presentation, thinking that this increases assurance for the parties involved in a transaction. The legal framework is not designed for this and insufficiently protects the credential subject for example. Instead, the high assurance use cases should complement digital credentials (with plausible deniability of past presentations) with qualified e-signatures and e-seals. For these, the EU for example does provide a legal framework that protects both the relying party and the signer.
- moffkalast 2y ago
  I mean it's not a super big deal if the EU identity private key leaks in some arcane attack or if someone steals it the normal way, you can just cancel it and order a new one like a credit card. It expires every two years I think anyway. This reminds me of a specific number that Americans have to give in plain text as proof of digital identity that they only get one of and can't change it ever. Lol.
  - the_sleaze_ 2y ago
    Well, at least you can laminate it
  - sunk1st 2y ago
    That doesn’t matter. The claim being made by the grandparent post is that the legal system isn’t well-equipped to deal with scenarios like, “yes the digital signature is valid but it was improperly authorized.”
    - moffkalast 2y ago
      The legal system also isn't well equipped to deal with the conceptually roughly equal case of someone stealing your car and running people over with it, but it deals with it anyway.
  - toast0 2y ago
    > This reminds me of a specific number that Americans have to give in plain text as proof of digital identity that they only get one of and can't change it ever. Lol. You can get up to ten replacements of your card in your lifetime. They do all have the same number though. [1] https://secure.ssa.gov/poms.nsf/lnx/0110205400 https://secure.ssa.gov/poms.nsf/lnx/0110205400
- dangsux 2y ago
  [dead]
- lmm 2y ago
  Isn't non-repudiation something we want for cases like this? If e.g. a car rental place checks your driving license before renting you a car, and then you get into a crash, no-one wants you to be able to claim that you never showed them your driving license and they never checked.
  - sandij 2y ago
    To prove that the car rental company has seen the driver licence, they just need to show the judge a copy of the licence which is e-sealed by its issuing authority. No need to include a non-repudiable proof-of-possession signature of the holder. Having that in addition would just introduce legal ambiguity and information asymmetry to the disadvantage of the holder. The opponent may still claim that the car rental place is showing a copy that was obtained illegally, and not in holder presentation. To avoid such a claim, the car rental company should ask for a qualified e-signature before providing the car key. The signed data can include any relevant claims that both parties confirm as part of the transaction. To provide similar assurance to the customer, the company should counter-sign that document, or provide it pre-sealed if it is an automated process. Note that with the EU Digital Identity, creating qualified e-signatures is just as easy as presenting digital credentials.
    - pjc50 2y ago
      Getting the parties on the desk, or the people commissioning enterprise IT systems, to understand this is going to be a serious uphill struggle. Especially in places that are used to photocopying your ID.
      - mistrial9 2y ago
        the liquor store owner that scans the barcode on your Driver's License "does not understand" and does not care to understand. Yet the opening to your entire life to some low-level cog has been transferred. The correct answer for the wonks out there is : scan ID to answer the question "is this person over the legal drinking age" YES or NO .. which is stored. Similar situations with different contexts, abound.
- namibj 2y ago
  Can you make the comparison to the German eID (notable for it's unusually extensive privacy-preserving tactics)?
  - sandij 2y ago
    I’m not sure what the German eID uses today, but the German architecture team has explored KEM+MAC for the EU Digital Identity Wallet. Maybe its eID is similar. You can apply KEM+MAC at either or both of two points: 1. plausible deniability of the document’s issuer seal 2. plausible deniability of having presented the document The second is great for legal certainty for the user. The first has problems. It would be incompatible with qualified e-sealing; stakeholders have no evidence if issuer integrity was compromised. Also, it would mean that issuance happens under user control, during presentation to a relying party. In a fully decentralised wallet architecture, this means including the trusted issuer KEM key pair on the user’s phone. Compromising the issuance process, for example by extracting the trusted issuer KEM key pair, could enable the attacker to impersonate all German natural persons online. The advantage would have been that authenticity the content of stolen documents could be denied. This potentially makes it less interesting to steal a pile of issued documents and sell it illegally. But how would illegal buyers really value qualified authenticity e-seals on leaked personal data?
- dwaite 2y ago
  Can you go into a bit more detail on what you see as the problem in non-repudiation of presentation?
  - sandij 2y ago
    Non-repudiation of commitments to a transaction can be good when both parties want to avoid later disputes about the authenticity of these commitments. It requires careful design of the data to be signed, the public key certificates, the policies governing the signature creation and validation processes, and the signature formats to enable validation as long as needed. Attribute presentation is not designed for this feature. When attribute presentation becomes non-repudiable, it creates legal uncertainty: 1. In court, the verifier may now present the proof of possession as evidence. But this is, at least in the EU, not recognised by default as an e-signature. It is yet unknown if it would be interpreted as such by a court. So the verifier keeps a risk that will be difficult for them to assess. 2. Even if it would be recognised as evidence, the holder may argue that it is a replay of a presentation made in another transaction. Presentation protocols are not designed for timestamp assurance towards third parties, and generally do not include verifiable transaction information. 3. The verifier may protect itself by audit-logging attribute presentation input and output along with publicly verifiable timestamps and verifiable transaction information, and by editing its terms and conditions to claim a priori non-repudiation of any presentation. Typically such a solution would not create the same evidence files at the holder’s side. So the holder would not be able to present as strong evidence in court as the verifier. (This asymmetry aspect needs some more elaboration.) Non-repudiation is well arranged in EU law for e-signatures. If anyone would want the same for attribute presentation, this should involve changes in law. As far as I can see, non-repudiation is now opportunistically being considered in mDL/EUDI just from an isolated technical perspective.
  - sandij 2y ago
    Another issue with non-repudiation of presentation is that it encourages relying parties to log full transcripts of presentation interactions. It could also encourage supervisory bodies to request such over-complete logging. Instead, relying parties should log the minimum necessary, to avoid developing a honeypot of personal data.
kccqzy 2y ago
The author mentions HMAC at the end. I think HMAC is really an underrated technique. I remember reading Colin Percival's classic Cryptographic Right Answers[0] and saw a section about "symmetric signatures." I pondered to myself what scheme I could use for that before I looked at the answer: of course it's just HMAC. I feel like this is another perspective that ought to be more widely known: if you want something to be like a signature, but the two parties (or just a single party at different times) can share a key, HMAC really is the right answer. Things like, a server needs to cryptographically sign a cookie to prevent tempering: that's HMAC. Or a server needs to know an API request is coming from an expected client: that's also HMAC. [0]: https://www.daemonology.net/blog/2009-06-11-cryptographic-right-answers.html https://www.daemonology.net/blog/2009-06-11-cryptographic-ri...
- anyfoo 2y ago
  Yeah, if you have a shared secret, HMAC is the way to go. It's also super simple: It's almost literally just concatenating the secret and the message you want to authenticate together, and take an ordinary hash (like SHA256) of that, the rest of it is just to deal with padding. It's super intuitive how HMAC works: If you just mash secret and message together on your side, and get the same answer as what the other side told you, then you know that the other side had the secret key (and exactly this message), because there's obviously no way to go from SHA256 to the input. HMAC is also useful if you want to derive new secret keys from other secret keys. Take an HMAC with the secret key and an arbitrary string, you get a new secret key. The other side can do the same thing. Here's the kicker, the arbitrary string does not have to be secret to anyone, it can be completely public! Why would you do that? Well, maybe you want the derived key to have a different lifetime and scope. A "less trusted" component could be given this derived key to do its job without having to know the super-secret key it was derived from (which could be used to derive other keys for other components, or directly HMAC or decrypt other stuff).
  - loeg 2y ago
    > It's also super simple: It's almost literally just concatenating the secret and the message you want to authenticate together, and take an ordinary hash (like SHA256) of that, the rest of it is just to deal with padding. It's not quite as simple as that. The output of the first hash is hashed a second time (to prevent length extension attacks).
gyush 2y ago
> As well as authenticating a message, they also provide third-party verifiability and (part of) non-repudiation. I think digital signatures and third party verification are an incredibly useful feature. The ability to prove you received some data from some third party lets you prove things about yourself, and enables better data privacy long-term, especially when you have selective disclosure when combined with zero knowledge proofs. See: https://www.andrewclu.com/sign-everything https://www.andrewclu.com/sign-everything -- the ability to make all your data self-sovereign and selectively prove data to the outside world (i.e. prove I'm over 18 without showing my whole passport) can be extremely beneficial, especially as we move towards a world of AI generated content where provenant proofs can prove content origin to third parties. You're right that post quantum signature research is still in progress, but I suspect that until post-quantum supremacy, it's still useful (and by then I hope we'll have fast and small post quantum signature schemes). EU's digital signatures let you do this for your IDs and https://www.openpassport.app/ https://www.openpassport.app/ lets you do this for any country passport, but imagine you could do this for all your social media data, personal info, and login details. we could have full selective privacy online, but only if everyone uses digital signatures instead of HMACs.
- ramchip 2y ago
  The article's point is that these properties are not always desirable. Imagine someone messages a friend via an app, and mentions that they're gay, in a country where it's illegal. If the app uses signatures they can't deny that they sent the message. If it's based on key agreement (like Signal), then either party could have faked the exchange, so there's at least some deniability.
- sebbu 2y ago
  I already successfully used EU digital signatures through lex [1], but neither openpassport [2] not withpersona / linkedin [3] supports EU's new (2019+) identity cards, only passports. [1] https://lex.community/ https://lex.community/ [2] https://github.com/zk-passport/openpassport/issues/126 https://github.com/zk-passport/openpassport/issues/126 [3] https://www.linkedin.com/help/linkedin/answer/a1631613 https://www.linkedin.com/help/linkedin/answer/a1631613
- 2y ago
talkingtab 2y ago
I am a user, but not expert in cryptography, but I find the title of the article to be bait and switch. A more accurate title would be "Pitfalls of using Digital Signatures and Possible Alternatives".
rpigab 2y ago
To me, DKIM doesn't prove that the user john.smith@gmail.com sent that email. It proves that gmail.com sent it. I'd avoid trusting FAANGs in courts when the fate of political leaders is at stake.
- kbolino 2y ago
  This is exactly what DKIM means, and this is why it has wide adoption, while S/MIME and PGP-signed mail remain relegated to niche uses. The entire purpose of DKIM is not to prove that the individual behind john.smith@gmail.com sent the message, but that a legitimate server owned and operated by the entity behind gmail.com sent the message. It's mostly there to reduce spam and phishing, not to ensure end-to-end communication integrity. This has nothing to do with the particular companies involved nor their particular trustworthiness.
  - rpigab 2y ago
    Your last sentence kinda contradicts the fact that the company Google operates the server behind gmail.com. If Google was evil (but in reality it's not), it could have forged and signed an email from john.smith@gmail.com with valid DKIM, sent on other mail servers or not (since we talk about leaked emails, we just need a file), when in reality the Google user john.smith@gmail.com never sent that email. To me, John Smith could have plausible deniability in court, depending on if everyone trusts Google to be 100% reliable. If the stakes are higher than what the company would risk to lose if found to have forged the email, what's stopping them?
    - deleted 2y ago
      [deleted]
    - kbolino 2y ago
      Google could forge the email without DKIM (DMARC only requires one of SPF or DKIM to succeed, not both). While DKIM gives high confidence that the email came from Google, neither its presence nor absence says anything about John Smith.
- 2y ago
next_xibalba 2y ago
Slightly off topic: In school I only took one cryptography class (it was bundled with networking, at that), and to this day I still think it contained some of the most amazing concepts I've ever learned. Public-key cryptography being on the short list along with cryptographic hash functions. Maybe it's my particular bias, or maybe cryptography has just attracted some of the most creative genius' of the 20th century.
- Aachen 2y ago
  What I find the most mind-blowing is that you can do a diffie-hellman-merkle key exchange in a room full of people, everyone can hear you, but the two participants are the only ones in possession of the encryption key after exchanging three messages (once to establish the parameters, once to convey one computed number in each direction). The math is simple enough to do by heart, at least as a demonstration (of course, it's not possible to compute numbers in your head that are so large a computer, doing billions of calculations per second, cannot simply iterate over all possible values and thus break it; but the principle works) Didn't get this in school unfortunately. They made us implement DES S-boxes iirc and Caesar cipher breaking... all very relevant and foundational knowledge for non-mathematicians who will never design a secure cipher

278 points by _ikke_ 2y ago

This article is very relevant in the context of the EU Digital Identity Wallet, and digital credentials in general, such as ISO/IEC 18013-5 mobile driver licenses and other mdocs. We may accidentially end up with non-repudiation of attribute presentation, thinking that this increases assurance for the parties involved in a transaction. The legal framework is not designed for this and insufficiently protects the credential subject for example. Instead, the high assurance use cases should complement digital credentials (with plausible deniability of past presentations) with qualified e-signatures and e-seals. For these, the EU for example does provide a legal framework that protects both the relying party and the signer.

moffkalast 2y ago
I mean it's not a super big deal if the EU identity private key leaks in some arcane attack or if someone steals it the normal way, you can just cancel it and order a new one like a credit card. It expires every two years I think anyway. This reminds me of a specific number that Americans have to give in plain text as proof of digital identity that they only get one of and can't change it ever. Lol.
- the_sleaze_ 2y ago
  Well, at least you can laminate it
- sunk1st 2y ago
  That doesn’t matter. The claim being made by the grandparent post is that the legal system isn’t well-equipped to deal with scenarios like, “yes the digital signature is valid but it was improperly authorized.”
  - moffkalast 2y ago
    The legal system also isn't well equipped to deal with the conceptually roughly equal case of someone stealing your car and running people over with it, but it deals with it anyway.
- toast0 2y ago
  > This reminds me of a specific number that Americans have to give in plain text as proof of digital identity that they only get one of and can't change it ever. Lol. You can get up to ten replacements of your card in your lifetime. They do all have the same number though. [1] https://secure.ssa.gov/poms.nsf/lnx/0110205400 https://secure.ssa.gov/poms.nsf/lnx/0110205400
dangsux 2y ago
[dead]
lmm 2y ago
Isn't non-repudiation something we want for cases like this? If e.g. a car rental place checks your driving license before renting you a car, and then you get into a crash, no-one wants you to be able to claim that you never showed them your driving license and they never checked.
- sandij 2y ago
  To prove that the car rental company has seen the driver licence, they just need to show the judge a copy of the licence which is e-sealed by its issuing authority. No need to include a non-repudiable proof-of-possession signature of the holder. Having that in addition would just introduce legal ambiguity and information asymmetry to the disadvantage of the holder. The opponent may still claim that the car rental place is showing a copy that was obtained illegally, and not in holder presentation. To avoid such a claim, the car rental company should ask for a qualified e-signature before providing the car key. The signed data can include any relevant claims that both parties confirm as part of the transaction. To provide similar assurance to the customer, the company should counter-sign that document, or provide it pre-sealed if it is an automated process. Note that with the EU Digital Identity, creating qualified e-signatures is just as easy as presenting digital credentials.
  - pjc50 2y ago
    Getting the parties on the desk, or the people commissioning enterprise IT systems, to understand this is going to be a serious uphill struggle. Especially in places that are used to photocopying your ID.
    - mistrial9 2y ago
      the liquor store owner that scans the barcode on your Driver's License "does not understand" and does not care to understand. Yet the opening to your entire life to some low-level cog has been transferred. The correct answer for the wonks out there is : scan ID to answer the question "is this person over the legal drinking age" YES or NO .. which is stored. Similar situations with different contexts, abound.
namibj 2y ago
Can you make the comparison to the German eID (notable for it's unusually extensive privacy-preserving tactics)?
- sandij 2y ago
  I’m not sure what the German eID uses today, but the German architecture team has explored KEM+MAC for the EU Digital Identity Wallet. Maybe its eID is similar. You can apply KEM+MAC at either or both of two points: 1. plausible deniability of the document’s issuer seal 2. plausible deniability of having presented the document The second is great for legal certainty for the user. The first has problems. It would be incompatible with qualified e-sealing; stakeholders have no evidence if issuer integrity was compromised. Also, it would mean that issuance happens under user control, during presentation to a relying party. In a fully decentralised wallet architecture, this means including the trusted issuer KEM key pair on the user’s phone. Compromising the issuance process, for example by extracting the trusted issuer KEM key pair, could enable the attacker to impersonate all German natural persons online. The advantage would have been that authenticity the content of stolen documents could be denied. This potentially makes it less interesting to steal a pile of issued documents and sell it illegally. But how would illegal buyers really value qualified authenticity e-seals on leaked personal data?
dwaite 2y ago
Can you go into a bit more detail on what you see as the problem in non-repudiation of presentation?
- sandij 2y ago
  Non-repudiation of commitments to a transaction can be good when both parties want to avoid later disputes about the authenticity of these commitments. It requires careful design of the data to be signed, the public key certificates, the policies governing the signature creation and validation processes, and the signature formats to enable validation as long as needed. Attribute presentation is not designed for this feature. When attribute presentation becomes non-repudiable, it creates legal uncertainty: 1. In court, the verifier may now present the proof of possession as evidence. But this is, at least in the EU, not recognised by default as an e-signature. It is yet unknown if it would be interpreted as such by a court. So the verifier keeps a risk that will be difficult for them to assess. 2. Even if it would be recognised as evidence, the holder may argue that it is a replay of a presentation made in another transaction. Presentation protocols are not designed for timestamp assurance towards third parties, and generally do not include verifiable transaction information. 3. The verifier may protect itself by audit-logging attribute presentation input and output along with publicly verifiable timestamps and verifiable transaction information, and by editing its terms and conditions to claim a priori non-repudiation of any presentation. Typically such a solution would not create the same evidence files at the holder’s side. So the holder would not be able to present as strong evidence in court as the verifier. (This asymmetry aspect needs some more elaboration.) Non-repudiation is well arranged in EU law for e-signatures. If anyone would want the same for attribute presentation, this should involve changes in law. As far as I can see, non-repudiation is now opportunistically being considered in mDL/EUDI just from an isolated technical perspective.
- sandij 2y ago
  Another issue with non-repudiation of presentation is that it encourages relying parties to log full transcripts of presentation interactions. It could also encourage supervisory bodies to request such over-complete logging. Instead, relying parties should log the minimum necessary, to avoid developing a honeypot of personal data.

kccqzy 2y ago

The author mentions HMAC at the end. I think HMAC is really an underrated technique. I remember reading Colin Percival's classic Cryptographic Right Answers[0] and saw a section about "symmetric signatures." I pondered to myself what scheme I could use for that before I looked at the answer: of course it's just HMAC. I feel like this is another perspective that ought to be more widely known: if you want something to be like a signature, but the two parties (or just a single party at different times) can share a key, HMAC really is the right answer. Things like, a server needs to cryptographically sign a cookie to prevent tempering: that's HMAC. Or a server needs to know an API request is coming from an expected client: that's also HMAC. [0]: https://www.daemonology.net/blog/2009-06-11-cryptographic-right-answers.html https://www.daemonology.net/blog/2009-06-11-cryptographic-ri...

anyfoo 2y ago
Yeah, if you have a shared secret, HMAC is the way to go. It's also super simple: It's almost literally just concatenating the secret and the message you want to authenticate together, and take an ordinary hash (like SHA256) of that, the rest of it is just to deal with padding. It's super intuitive how HMAC works: If you just mash secret and message together on your side, and get the same answer as what the other side told you, then you know that the other side had the secret key (and exactly this message), because there's obviously no way to go from SHA256 to the input. HMAC is also useful if you want to derive new secret keys from other secret keys. Take an HMAC with the secret key and an arbitrary string, you get a new secret key. The other side can do the same thing. Here's the kicker, the arbitrary string does not have to be secret to anyone, it can be completely public! Why would you do that? Well, maybe you want the derived key to have a different lifetime and scope. A "less trusted" component could be given this derived key to do its job without having to know the super-secret key it was derived from (which could be used to derive other keys for other components, or directly HMAC or decrypt other stuff).
- loeg 2y ago
  > It's also super simple: It's almost literally just concatenating the secret and the message you want to authenticate together, and take an ordinary hash (like SHA256) of that, the rest of it is just to deal with padding. It's not quite as simple as that. The output of the first hash is hashed a second time (to prevent length extension attacks).

gyush 2y ago

> As well as authenticating a message, they also provide third-party verifiability and (part of) non-repudiation. I think digital signatures and third party verification are an incredibly useful feature. The ability to prove you received some data from some third party lets you prove things about yourself, and enables better data privacy long-term, especially when you have selective disclosure when combined with zero knowledge proofs. See: https://www.andrewclu.com/sign-everything https://www.andrewclu.com/sign-everything -- the ability to make all your data self-sovereign and selectively prove data to the outside world (i.e. prove I'm over 18 without showing my whole passport) can be extremely beneficial, especially as we move towards a world of AI generated content where provenant proofs can prove content origin to third parties. You're right that post quantum signature research is still in progress, but I suspect that until post-quantum supremacy, it's still useful (and by then I hope we'll have fast and small post quantum signature schemes). EU's digital signatures let you do this for your IDs and https://www.openpassport.app/ https://www.openpassport.app/ lets you do this for any country passport, but imagine you could do this for all your social media data, personal info, and login details. we could have full selective privacy online, but only if everyone uses digital signatures instead of HMACs.

ramchip 2y ago
The article's point is that these properties are not always desirable. Imagine someone messages a friend via an app, and mentions that they're gay, in a country where it's illegal. If the app uses signatures they can't deny that they sent the message. If it's based on key agreement (like Signal), then either party could have faked the exchange, so there's at least some deniability.
sebbu 2y ago
I already successfully used EU digital signatures through lex [1], but neither openpassport [2] not withpersona / linkedin [3] supports EU's new (2019+) identity cards, only passports. [1] https://lex.community/ https://lex.community/ [2] https://github.com/zk-passport/openpassport/issues/126 https://github.com/zk-passport/openpassport/issues/126 [3] https://www.linkedin.com/help/linkedin/answer/a1631613 https://www.linkedin.com/help/linkedin/answer/a1631613
2y ago

talkingtab 2y ago

I am a user, but not expert in cryptography, but I find the title of the article to be bait and switch. A more accurate title would be "Pitfalls of using Digital Signatures and Possible Alternatives".

rpigab 2y ago

To me, DKIM doesn't prove that the user john.smith@gmail.com sent that email. It proves that gmail.com sent it. I'd avoid trusting FAANGs in courts when the fate of political leaders is at stake.

kbolino 2y ago
This is exactly what DKIM means, and this is why it has wide adoption, while S/MIME and PGP-signed mail remain relegated to niche uses. The entire purpose of DKIM is not to prove that the individual behind john.smith@gmail.com sent the message, but that a legitimate server owned and operated by the entity behind gmail.com sent the message. It's mostly there to reduce spam and phishing, not to ensure end-to-end communication integrity. This has nothing to do with the particular companies involved nor their particular trustworthiness.
- rpigab 2y ago
  Your last sentence kinda contradicts the fact that the company Google operates the server behind gmail.com. If Google was evil (but in reality it's not), it could have forged and signed an email from john.smith@gmail.com with valid DKIM, sent on other mail servers or not (since we talk about leaked emails, we just need a file), when in reality the Google user john.smith@gmail.com never sent that email. To me, John Smith could have plausible deniability in court, depending on if everyone trusts Google to be 100% reliable. If the stakes are higher than what the company would risk to lose if found to have forged the email, what's stopping them?
  - deleted 2y ago
    [deleted]
  - kbolino 2y ago
    Google could forge the email without DKIM (DMARC only requires one of SPF or DKIM to succeed, not both). While DKIM gives high confidence that the email came from Google, neither its presence nor absence says anything about John Smith.
2y ago

next_xibalba 2y ago

Slightly off topic: In school I only took one cryptography class (it was bundled with networking, at that), and to this day I still think it contained some of the most amazing concepts I've ever learned. Public-key cryptography being on the short list along with cryptographic hash functions. Maybe it's my particular bias, or maybe cryptography has just attracted some of the most creative genius' of the 20th century.

Aachen 2y ago
What I find the most mind-blowing is that you can do a diffie-hellman-merkle key exchange in a room full of people, everyone can hear you, but the two participants are the only ones in possession of the encryption key after exchanging three messages (once to establish the parameters, once to convey one computed number in each direction). The math is simple enough to do by heart, at least as a demonstration (of course, it's not possible to compute numbers in your head that are so large a computer, doing billions of calculations per second, cannot simply iterate over all possible values and thus break it; but the principle works) Didn't get this in school unfortunately. They made us implement DES S-boxes iirc and Caesar cipher breaking... all very relevant and foundational knowledge for non-mathematicians who will never design a secure cipher