[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Replay Attacks
At 3:39 PM 3/8/96 -0800, Tony Bartoletti wrote:
>It occurs to me that no one has directly addressed the "Replay Attack."
>Perhaps it is outside the scope of spki but then, what do I know?
>
>A contrived example:
>
>You sign a Purchase Order (for delivery of a color TV) with your certified
>key, and forward the PO to the supplier, e-mail-wise. The supplier receives
>the PO, but the wily hacker (who has gained illicit access to one of the
>intervening mailservers) takes this sequence of packets and replays them to
>the supplier over a period of several days. Three weeks later, a semi pulls
>up to your door and you are asked to accept delivery of 20 color TVs.
>
>... If anyone knows how the
>spki framework can address this (or why it doesnt need to, is mitigated
>through other mechanisms or assumptions) I would like to hear about it.
SET solves this class of problem by requiring a unique transaction ID to be
included with each transaction. In your example, it would be a PO number.
In SET it is sometimes a long random number (with small chance of
collision). Adding this number to transactions makes them idempotent, so
replay (or innocent duplication) do not cause them to acted on more than
once.
Regards - Bill
------------------------------------------------------------------------
Bill Frantz | The CDA means | Periwinkle -- Computer Consulting
(408)356-8506 | lost jobs and | 16345 Englewood Ave.
frantz@netcom.com | dead teenagers | Los Gatos, CA 95032, USA