[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on Photuris
> From ipsec-request@ans.net Wed Feb 15 02:03 PST 1995
>> What do you mean by "steal a signature"? Trick the device to sign an
> arbitrary value of your own choosing, such as the hash on a g^x
> for which you know x?
Yes.
> If this is the case, then of *course* you can impersonate the user.
> This just underscores the importance of being careful about what you
> sign. The problem is really one of engineering, not protocol design.
No, the problem bears directly on protocol design, because
some protocols minimize the damage of this sort of compromise,
whereas for others (e.g. Photuris) this is catastrophic.
For example, the STS protocol in the Diffie et al reference I cited
earlier allows an adversary to gain *no* impersonation advantage from
stealing signatures in advance from smart cards because you don't know
in advance what you will be expected to sign in real time in order to
be authenticated.
And if you replaced the signatures in the STS protocol design with
ICVs computed with cached pairwise SKIP master keys, then this
too would allow no advantage from smart cards being tricked
into signing/encrypting various quantities. Furthermore, this
would alleviate the need to precompute the signature because
realtime computation of ICVs is a very efficient operation
in comparison with RSA signatures. This would have the same realtime
computational overhead of, e.g., Photuris without some of the
catastrophic failure modes.
> But I see an addition to the protocol to at least limit the damage if
> this were to happen. Simply append an expiration time to the
> precomputed DH public part before you sign it.
This doesn't help a whole lot when the intruder is picking the signature
to be stolen, because she can simply pick the expiration date that
suits her. Not unless you modify the smart card to always append dates
to all signatures, which would make the smart card not very useful
for other protocols which cannot handle dates in signatures (e.g PEM/PGP etc.)
And no smart card I know of does this.
> This is just a superset of the previous attack. It's not really fair
> to posit that x is compromised since DH has always assumed it to be
> secret. But the timestamp feature could again limit the duration of
> the breach if it were to occur.
As Hugo mentioned, attacks are not about fairness. One could make the same
argument about protocols that dont support perfect forward secrecy, i.e,
it is not fair to assume that the keys will ever be compromised.
> Now I have been assuming that the entire IPSP is software running on
> general purpose computers, i.e., there is no special tamper resistant
> hardware for the signing operation. If you do assume such hardware,
> especially if the rest of the protocol remains on hackable general
> purpose computers, then your point starts to carry some real weight.
Assuming the lack of special purpose crypto-hardware when considering
IPSP system/protocol design issues is not a good idea. I expect a very
large proportion of commercial IPSP products to support crypto hardware
like smart cards, PCMCIA devices etc.
Kind regards,
Ashar.
Follow-Ups: