Vulnerability Development mailing list archives
Re: Non-Mathmatical Forging of PKI Digital Certificates / Throwin g Rocks at the PKI
From: "Everhart, Glenn (FUSA)" <GlennEverhart () FIRSTUSA COM>
Date: Fri, 18 Aug 2000 13:20:51 -0400
That a credit card transaction is validated does not mean it is not fraudulent. There is a limited amount one can check and it has been reliably reported that fraud rates of several percent in internet transactions are common. The problem is that even if one has a lot of public information, and even if one knows a lot about someone's history, that does not guarantee that the someone with all this information and knowledge of personal history is the person he claims to be. Any identity credential giver has this problem, some worse than others. If the laws go any further than creating a refutable presumption that the credential refers to some human, they go too far. (If every member of Congress had his/her identity forged in some transaction and had some charge made ...needs not be large... which they were obliged by such a law to pay, the law might quickly be altered. Apparently this hasn't happened...) -----Original Message----- From: Timothy J. Miller [mailto:cerebus () SACKHEADS ORG] Sent: Friday, August 18, 2000 10:24 AM To: VULN-DEV () SECURITYFOCUS COM Subject: Re: Non-Mathmatical Forging of PKI Digital Certificates / Throwing Rocks at the PKI Pluto <pluto () DEFCOM-SEC COM> writes:
Page 2, 4 paragraph: An CA can authenticate an user. Why do you think this should not be possible? Checking valid, gov. guaranteed credentials for example. If the user want's a sig under his X.509, he has to give some information, I'd think. I havn't found advice on how to social engeneer a CA into believing you are someone else.
So I steal your state-issued driver's license and mail a photocopy to the CA manager, and he issues me a cert that is, as legislation begins to get passed, non-repudiable by you. Hope you don't mind paying for my new Mercedes...
Page 4: Not more than a privacy problem, if you don't want to be called, don't list in the yellow pages. A directory service or searchable list of customers is not necessary for operations, to check if a cert is revoced you submit the ID to the CA and wait for an answer.
This gets me thinking. I don't know if any of y'all remember the little black books the store clerk used to use to look up your credit card number, but I do. CC companies used to publish paper listings of all invalid CC#s. If you were in the book, you lost your card. If you weren't, you got the sale. This is the same function as a CRL. Note that this is not a positive statement of validity, but a negative statement of validity-- which is weaker. However, most of this is moot. There are several popular PKI enabled producted that *don't bother to check the CRL even if it's present on the local system*. So in actual practice, you need to go further than just offering validity checking. There needs to be some mechanism whereby the source of authority can guarantee that for some arbitrary PKI transaction, the parties engaged actually performed a validity check. To return to the credit card analogy, you cannot complete a CC transaction without receiving an approval code from the issuer. Even if I manually frank your card and send you on your merry way, the CC issuer won't honor the receipt if I don't have an authorization code on it. The issuer (the SOA) has mandated that I have to perform a validity check (swipe it / call it in) and issues me a token (the authorization code) that they can use to make sure I do what I'm supposed to do. I can't forge the token since it won't exist in their system when they receive the paper receipt. We don't have this for PKI transactions. Now I know a little about OCSP (Online Certificate Status Protocol), but does OCSP provide a mechanism to force a participant to validate the certificate, and invalidates the transaction if not completed?
Page 5, 2 para.: Same as above, when a key is lost, it get's revoced and has to be applied for again. Again using some means to authenticate the applyee before signing the stuff. The example from verisign is not best practice, you're right.
Not always. Many PKI sites, particulary private CAs internal to corporations, will escrow your private key at issuance. For instance, if you're fired the private key needs to be recovered so they can decrypt company data on your system. Or again if you're working in a smartcard-enabled company, when the CEO forgets his smartcard at home are *you* going to tell him that he *must* drive home and get it, or are you simply going to snatch his private key from escrow and issue him a temporary card? Food for more thought.
Current thread:
- Re: Non-Mathmatical Forging of PKI Digital Certificates / Throwin g Rocks at the PKI Chris Tobkin (Aug 17)
- <Possible follow-ups>
- Re: Non-Mathmatical Forging of PKI Digital Certificates / Throwin g Rocks at the PKI Everhart, Glenn (FUSA) (Aug 18)