[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [IETF-PKIX] Multiple Certificates



At 09:32 AM 3/10/98 -0500, you wrote:
>> From: "Balluffi, Frank" <BalluffiF@CertCo.com>
>>
>> What is the foundation or context for this discussion: WHAT ATTACKS ARE
>> WE CONCERNED ABOUT?
>
>
>In addition to the four operational disadvantages listed in a prior
>message, I thought up the following actual attack this morning
>in the shower :-)
>
>Consider two credit cards with different policies: the Green card
>is free and offers no benefits; the Gold card costs .1% per transaction
>but offers replacement insurance up to $1000 on goods purchased.
>
>It is in the user's interest to use the Green card for every transaction,
>unless the goods received turn out to be defective, in which case the
>user might try to substitute the Gold card on the purchase transaction.
>
>The credit card company has the opposite incentive, to switch all
>transactions to the Gold card.  And if the merchant pays a different
>fee or gets a different commission from the two cards, the merchant
>has an incentive to swap certificates too.
>
>Certificate substitution would be prevented by using different keys,
>by binding the cert to the transaction, or both.  In the case of
>credit cards, any reasonable commerce protocol would bind the cert
>into the transaction.  But the attack applies whenever there
>are certificates with a shared key and conflicting incentives;
>the incentives could be information-based rather than monetary.
>Few application protocols (and according to the chair of the S/MIME
>working group, *no* email protocols) include any means of preventing
>certificate substitution, so key sharing is a vulnerability.
>
>Am I missing something?

No.  And I really like this example!  It neatly illustrates motivations
for certificate substitution in both directions.  And your last paragraph
addresses most of my questions regarding your point in the previous letter
concerning varied key expirations - linking usage to certificate would
largely obviate the problem, true?

___TONY___

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: azb@llnl.gov   phone: 510-422-3881             LLLLLLLL