dual-use digital signature vulnerability

Anne & Lynn Wheeler lynn at garlic.com
Sun Jul 18 10:54:56 EDT 2004


At 01:33 AM 7/18/2004, Amir Herzberg wrote:
I don't see here any problem or attack. Indeed, there is difference
between signature in the crypto sense and legally-binding
signatures. The later are defined in one of two ways. One is by the
`digital signature` laws in different countries/states; that approach
if often problematic, since it is quite tricky to define in a general
law a binding between a person or organization and a digital
signature. The other way however is fine, imho: define the digital
signature in a (`regular`) contract between the parties. The contract
defines what the parties agree to be considered as equivalent to their
(physical) signature, with well defined interpretation and
restrictions.
...

the digital signature laws, for the most part, defined how a
certification authority went about binding the owner of a public key
(or at least the entity presenting a public key and a digital
signature that could be verified by that public key) and some other
information ... and presenting that in a certificate. However, I don't
remember seeing any of the e-sign laws a) defining a non-repudiation
environment that is mandated for signature digital signing environments
(indicating that the key owner has read, understood, and approves,
agrees, and/or authorizes the contents of the message and b) as
part of the integrity of the message, there is proof that such a
non-repudiation environment was used.


1)

the relying party being able to certify the integrity level of
something like a hardware token .... for use in "something you have"
authentication .... aka the relying party verifies a digital signature
and that verification may used to imply "something you have"
authentication (at this point there is absolutely nothing involving a
certificate). However, in order for the relying party to be able to
assume or imply what the verification of the digital signature
actually means .... and therefor how much it can trust the
verification ... it needs to know how the private key is maintained
and operated. If the act of "verifying a digital signature" actually
means or implies that it is "something you have" authentication
... then it needs to have some certification along the lines that the
private key is used and maintained in a hardware token with specific
characteristics. It has nothing at all to do with any certificate
traditionally mentioned in various kinds of e-sign laws.

2)

during the early '90s, the identity certificates tended to be
overloaded with all sorts of identity and privacy information. this
was fairly quickly realized to represent serious privacy and liability
issues. this was retrenched to things like relying-only-party
certificates that basically only had a public key and some sort of
account identifier (which could be used by the relying-party to pull
up the real information .... w/o having it publicly broadcast all over
the world). However, there were also things like "non-repudiation"
bits defined in certificates ... that have since been severely
depreciated. During the mid-90s there were some infrastructures being
proposed that if you had some data which had an appended digital
signature and an appended certificate containing a non-repudiation bit
.... then the burden of proof (in disputes) could be shifted from the
relying party to the signing party.

This was vulnerable to possibly two exploits

a) the digital signer had believed that they had signed random data as
part of an authentication protocol ... as opposed to having signed
some document contents indicating agreement, approval, and/or
authorization (as in real live signature .... aka the dual-use
scenario) and/or

b) since the appended certificate isn't part of the signed transaction
.... the relying-party might be able to find a digital certificate
(belonging to that key-owner for the same public key) that had the
non-repudiation bit set and substitute a non-repudiation certificate
for the certificate that the key-owner had actually appended (aka the
certificate is not part of the integrity of the message covered under
the digital signature).

3)

at the NIST PKI workshop a couple months ago .... there were a number
of infrastructure presentations where various entities in the
infrastructure were

a) signing random data as part of authentication protocol (where the
entity performing the digital signature was given no opportunity to
view the contents being signed) they were using hardware token
implementation .... and they were assuming that the verification of
the digital signature implied some sort of "something you have"
authentication. however there was nothing in the infrastructure that
provided certification and/or proof that the private key was kept and
maintained in a hardware token .... so there was no proof as to the
level of integrity and/or level of trust that the relying party could
place in the verification of that digital signature

b) signing authorization documents (using the same tokens that were
used in the authentication protocols)

However, there was no distinguishing and/or provable characteristics
that were provided which a relying-party could use to distinguish
between (random) contents that were signed as part of an
authentication protocol and (authorization) contents that the
relying-party could assume to indicate that the signer was agreeing,
approving, and/or authorization what was indicated by the contents of
the document.

Since there was no proof provided to the relying-party as to the
environment and conditions under which the signing actually occurred
.... then a dual-use attack is for non-random contents (aka some sort
of authorization document) to be injected into an authentication
protocol .... under the assumption that the entity performing the
digital signature will never look at the contents. Then such digitally
signed contents can be used in an approval, agreement, and/or
authorization scenario to imply that the entity performing the digital
signature was actually approving the contents of the document.

4)

this now verges into various of the non-repudiation definitions and
threads that have occurred in the past. in effect, for any kind of
infrastructure where the digital signature is being used to imply that
the entity responsible for the digital signature agrees, approves,
and/or authorizes what is in the content of the message being signed
(as opposed to some random data being signed as part of authentication
protocol and is never viewed) ... there has to be some additional
signing environment (demonstrating that the signer has actually read,
understood, and agrees with the contents) ... and the proof of the use
of such a signing environment infrastructure has to be carried as part
of the integrity of the message .... in order for the relying party to
rely on it being a real "signature signing" event ... as opposed to
have really originated from a authentication protocol where the person
believed that random data was being signed (and never actually viewed
the contents being signed). Note that not only does such an
non-repudiation signing environment has to have been used .... but the
proof of its use has to be carried as part of the integrity of the
message (in order for the relying party to distinguish between random
data being digital signed and the person having signed after viewing
the contents, understanding the contents and approving, agreeing,
and/or authorization what was indicated by the contents). So it isn't
just that a non-repudiation environment has to be used for signing
operations (as in human signature) ...but the proof of such
non-repudiation environments have to be carried as part of the
integrity of the message .... to differentiate from a dual-use attack
where the signing is believed to be random data and the person never
views the contents.

5)

other kinds of infrastructure implementations may be to have two
completely different hardware tokens with two completely different
public/private key pairs.

the hardware token used for authentication protocols doesn't concern
itself with the contents of the data ... in fact it always appends a
disclaimer to all random data (that it signs) stating that the digital
signature cannot be used to imply any agreement, approval,
authorization and/or any obligation on the part of the
token-owning entity.

the hardware token used for authorization, agreement, and/or approval
signing events will never perform a digital signature operation unless
it first senses that the token owner has read, understood and
approved of the contents.

all protocols indicate as part of the hardware token interaction, which
type of digital signature will be performed ... and the owner of the
hardware tokens is then instructed appropriately when hardware token
swapping needs to occur.

=========
random past posts about non-repudiation:

http://www.garlic.com/~lynn/aadsm10.htm#cfppki15 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm10.htm#cfppki18 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm10.htm#paiin PAIIN security glossary & 
taxonomy
http://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#6 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#7 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#8 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#9 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#11 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#12 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#13 Words, Books, and Key Usage
http://www.garlic.com/~lynn/aadsm11.htm#14 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#15 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm12.htm#5 NEWS: 3D-Secure and Passport
http://www.garlic.com/~lynn/aadsm12.htm#12 TOC for world bank e-security paper
http://www.garlic.com/~lynn/aadsm12.htm#30 Employee Certificates - Security 
Issues
http://www.garlic.com/~lynn/aadsm12.htm#37 Legal entities who sign
http://www.garlic.com/~lynn/aadsm12.htm#38 Legal entities who sign
http://www.garlic.com/~lynn/aadsm12.htm#59 e-Government uses 
"Authority-stamp-signatures"
http://www.garlic.com/~lynn/aadsm14.htm#39 An attack on paypal
http://www.garlic.com/~lynn/aadsm14.htm#47 UK: PKI "not working"
http://www.garlic.com/~lynn/aadsm14.htm#48 basic question: semantics of 
"map", "tie", etc in PKI
http://www.garlic.com/~lynn/aadsm15.htm#32 VS: On-line signature standards
http://www.garlic.com/~lynn/aadsm15.htm#33 VS: On-line signature standards
http://www.garlic.com/~lynn/aadsm15.htm#34 VS: On-line signature standards 
(slight addenda)
http://www.garlic.com/~lynn/aadsm15.htm#35 VS: On-line signature standards
http://www.garlic.com/~lynn/aadsm15.htm#36 VS: On-line signature standards
http://www.garlic.com/~lynn/aadsm16.htm#11 Difference between TCPA-Hardware 
and a smart card (was: example: secure computing kernel needed)
http://www.garlic.com/~lynn/aadsm16.htm#13 The PAIN mnemonic
http://www.garlic.com/~lynn/aadsm16.htm#14 Non-repudiation (was RE: The 
PAIN mnemonic)
http://www.garlic.com/~lynn/aadsm16.htm#17 Non-repudiation (was RE: The 
PAIN mnemonic)
http://www.garlic.com/~lynn/aadsm16.htm#18 Non-repudiation (was RE: The 
PAIN mnemonic)
http://www.garlic.com/~lynn/aadsm16.htm#23 Non-repudiation (was RE: The 
PAIN mnemonic)
http://www.garlic.com/~lynn/aadsm17.htm#3 Non-repudiation (was RE: The PAIN 
mnemonic)
http://www.garlic.com/~lynn/aadsm17.htm#5 Non-repudiation (was RE: The PAIN 
mnemonic)
http://www.garlic.com/~lynn/aadsm17.htm#55 Using crypto against Phishing, 
Spoofing and Spamming
http://www.garlic.com/~lynn/2000.html#57 RealNames hacked. Firewall issues.
http://www.garlic.com/~lynn/2001c.html#30 PKI and Non-repudiation 
practicalities
http://www.garlic.com/~lynn/2001c.html#34 PKI and Non-repudiation 
practicalities
http://www.garlic.com/~lynn/2001c.html#39 PKI and Non-repudiation 
practicalities
http://www.garlic.com/~lynn/2001c.html#40 PKI and Non-repudiation 
practicalities
http://www.garlic.com/~lynn/2001c.html#41 PKI and Non-repudiation 
practicalities
http://www.garlic.com/~lynn/2001c.html#42 PKI and Non-repudiation 
practicalities
http://www.garlic.com/~lynn/2001c.html#43 PKI and Non-repudiation 
practicalities
http://www.garlic.com/~lynn/2001c.html#44 PKI and Non-repudiation 
practicalities
http://www.garlic.com/~lynn/2001c.html#45 PKI and Non-repudiation 
practicalities
http://www.garlic.com/~lynn/2001c.html#46 PKI and Non-repudiation 
practicalities
http://www.garlic.com/~lynn/2001c.html#47 PKI and Non-repudiation 
practicalities
http://www.garlic.com/~lynn/2001c.html#50 PKI and Non-repudiation 
practicalities
http://www.garlic.com/~lynn/2001c.html#51 PKI and Non-repudiation 
practicalities
http://www.garlic.com/~lynn/2001c.html#52 PKI and Non-repudiation 
practicalities
http://www.garlic.com/~lynn/2001c.html#54 PKI and Non-repudiation 
practicalities
http://www.garlic.com/~lynn/2001c.html#56 PKI and Non-repudiation 
practicalities
http://www.garlic.com/~lynn/2001c.html#57 PKI and Non-repudiation 
practicalities
http://www.garlic.com/~lynn/2001c.html#58 PKI and Non-repudiation 
practicalities
http://www.garlic.com/~lynn/2001c.html#59 PKI and Non-repudiation 
practicalities
http://www.garlic.com/~lynn/2001c.html#60 PKI and Non-repudiation 
practicalities
http://www.garlic.com/~lynn/2001c.html#72 PKI and Non-repudiation 
practicalities
http://www.garlic.com/~lynn/2001c.html#73 PKI and Non-repudiation 
practicalities
http://www.garlic.com/~lynn/2001g.html#11 FREE X.509 Certificates
http://www.garlic.com/~lynn/2001g.html#38 distributed authentication
http://www.garlic.com/~lynn/2002f.html#35 Security and e-commerce
http://www.garlic.com/~lynn/2002g.html#37 Security Issues of using Internet 
Banking
http://www.garlic.com/~lynn/2002g.html#69 Digital signature
http://www.garlic.com/~lynn/2002h.html#68 Are you really who you say you are?
http://www.garlic.com/~lynn/2002i.html#67 Does Diffie-Hellman  schema 
belong to Public Key schema family?
http://www.garlic.com/~lynn/2002i.html#77 Does Diffie-Hellman  schema 
belong to Public Key schema family?
http://www.garlic.com/~lynn/2002j.html#24 Definition of Non-Repudiation ?
http://www.garlic.com/~lynn/2002j.html#40 Beginner question on Security
http://www.garlic.com/~lynn/2002m.html#38 Convenient and secure eCommerce 
using POWF
http://www.garlic.com/~lynn/2002n.html#16 Help! Good protocol for national 
ID card?
http://www.garlic.com/~lynn/2002n.html#19 Help! Good protocol for national 
ID card?
http://www.garlic.com/~lynn/2003.html#19 Message 
(authentication/integrity); was: Re: CRC-32 collision
http://www.garlic.com/~lynn/2003.html#29 Message 
(authentication/integrity); was: Re: CRC-32 collision
http://www.garlic.com/~lynn/2003f.html#37 unix
http://www.garlic.com/~lynn/2003h.html#29 application of unique signature
http://www.garlic.com/~lynn/2003h.html#38 entity authentication with 
non-repudiation
http://www.garlic.com/~lynn/2003i.html#35 electronic-ID and key-generation
http://www.garlic.com/~lynn/2003i.html#36 electronic-ID and key-generation
http://www.garlic.com/~lynn/2003j.html#47 The Tao Of Backup: End of postings
http://www.garlic.com/~lynn/2003k.html#6 Security models
http://www.garlic.com/~lynn/2003m.html#38 Questioning risks of using the 
same key for authentication and
http://www.garlic.com/~lynn/2003o.html#22 securID weakness
http://www.garlic.com/~lynn/2003o.html#29 Biometric cards will not stop 
identity fraud
http://www.garlic.com/~lynn/2003p.html#4 Does OTP need authentication?
http://www.garlic.com/~lynn/2003p.html#11 Order of Encryption and 
Authentication
http://www.garlic.com/~lynn/2003p.html#17 Does OTP need authentication?
http://www.garlic.com/~lynn/2004e.html#20 Soft signatures


--
Anne & Lynn Wheeler    http://www.garlic.com/~lynn/ 

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list