[17016] in cryptography@c2.net mail archive

home help back first fref pref prev next nref lref last post

Re: MD5 collision in X509 certificates

daemon@ATHENA.MIT.EDU (Anne & Lynn Wheeler)
Sun Mar 6 14:35:50 2005

X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
Date: Sat, 05 Mar 2005 09:23:11 -0700
From: Anne & Lynn Wheeler <lynn@garlic.com>
To: Victor Duchovni <Victor.Duchovni@MorganStanley.com>
Cc: Cryptography <cryptography@metzdowd.com>
In-Reply-To: <20050304211830.GW7470@piias899.ms.com>

Victor Duchovni wrote:
> What is the significance of this? It seems I can get a certificate for
> two public keys (chosen, not given) while only proving posession of the
> first. Is there anything else? In what sense is the second public key
> useful to the attacker?

the purpose of a certificate is analogous to the old letters of credit 
in the sailing ship days .... it supposedly establishes the bonifides of 
the individual in an offline, non-connected world where the relying 
party has no other recourse regarding trust/integrity of the individual 
that they are dealing with.

in the PKI/certificate world ... the relying party receives some sort of 
digitally encrypted/signed information and validates it using the public 
key presented in the attached certificate. a correctly validation then 
implies some kind of 3-factor authentication (although the 
PKI/certificate paradigm tends to totally gloss over this 
characteristic, instead attempting to focus the communities attention on 
the value of the certification as opposed to focusing the attention on 
any possibility/value/trust that some part of 3-factor authentication 
might have occured).

In any case, if the public key (from some source, possibly a 
certificate) is able to validate the transmission, then the relying 
party assumes that some portion of 3-factor authentication occured in 
the access and use of the corresponding private key ... possibly

* something you have (private key exclusively in a hardware token)
* something you know (hardware token won't work appropriately w/o PIN)
* something you are (hardware token requires some biometric)

in any case, given that the relying party accepts the validation by the 
public key as representing some implied 3-factor authentication involved 
in access and use of the corresponding private key ... then the relying 
party may be faced with just who the implied authentication corresponds 
to. In the typical, long time accepted business process ... the relying 
party will have prior relationship with the entity being authenticated 
and it will be explicit and/or implicit in the communication itself. In 
the more modern world, in the situations where the relying party has no 
prior relationship with the authenticated entity ... they will have 
access to online and/or real-time information to establish that fact.

However, certificates were targeted at the offline email world ... where 
the email was created, digitally signed (presumably after some form of 
3-factor authentication occuring to establish access/use of the private 
key), and the email, digital signature, and certificate packaged up and 
sent off to some party that there had been no previous communciation 
(might be considered spam in this day and age). After some number of 
intermediary store-and-forwards stops, the package arrives at the post 
office of the relying party. the relying party eventually calls their 
post office, exchanges emails and hangs up.

At this point the relying party is presented with a digital signed 
message with whom that they had no prior communciation. The attached 
certificate provides the public key for validating the digital signature 
and the rest of the certificate contents is supposedly to attest to some 
characteristic of the email sending party (that the relying party has no 
other way of validating).

The implication is that if i can substitute a public key in some 
certificate that attests to represent some other party .... then it may 
be some form of identity theft (fraudulent messages can be created that 
otherwise appear to have originated from you ... and validate with the 
substituted public key). The other might be elevation of privileges .... 
adding characteristics to a certificate that were otherwise not provided.

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

home help back first fref pref prev next nref lref last post