the limits of crypto and authentication

[Anne & Lynn Wheeler]

Nick Owen wrote:
> To validate the transaction, a receipt could be sent to the user
> encrypted by the server's public key.  If the receipt is correct, the
> user enters their PIN to 'sign' the transaction.
> 
> I'm assuming an asymmetric authentication system here outside the
> browser. The attacker would have to steal the user's private key, their
> PIN and the server's private key, correct?
> 
> I know that if the PC is compromised anything is possible, but I think
> this raises the bar significantly - perhaps to an unprofitably level.

the x9a10 financial standard working group was charged with preserving
the integrity of the financial infrastructure for all retail payments
... and came up with x9.59
http://www.garlic.com/~lynn/index.html#x959
http://www.garlic.com/~lynn/subpubkey.html#privacy

besides the two business rules mentioned before, there were guidelines
about being able to fit within the existing financial transaction
*straight-through processing* transaction model ... aka the consumer
originates the transaction and it can be processed in a single round trip.

there were provisions that the consumer should originate the transaction
... and/or at least have certified terminal when presented with the
option to sign; misc. past posts about the EU finread terminal standard
http://www.garlic.com/~lynn/subpubkey.html#finread

worst case is that the foreign terminals are still susceptable to
various compromises ... like misrepresnting the transaction. Not that
this is slightly lower threat model since the point of compromise and
the point of fraud are the same place ... and therefor are subject to
quick shutdown. recent post mentioning paranoid consumers needing
pda/cellphone portable devices at point-of-sale as countermeasure to
various transaction misrepresentation vulnerabilities
http://www.garlic.com/~lynn/aadsm19.html#38 massive data theft at
MasterCard processor

x9.59 does provide for interaction outside the *straight-through
processing* of the financial transaction. for instance, x9.59 has
provision for including the hash of the *order details* in the body of
the signed x9.59 transaction. the consumer returns such a signed message
to the merchant. at this point the merchant can verify that the hash of
*order details* in the body of the x9.59 digitally signed transaction is
the same as their computed hash of *order details*. This is
countermeasure against consumer attack on the merchant. While the body
of the *order details* isn't part of the actual financial transaction,
in the case of any dispute ... the two parties can produce their
purported versions of *order details* and see which one hashes to the
same value contained in the x9.59 digitally signed transaction.

from 3-factor authentication
http://www.garlic.com/~lynn/subpubkey.html#3factor

* something you have
* something you know
* something you are

the digital signing represents "something you have" authentication (i.e.
the originator has access to and use of the private key).

for lost/stolen countermeasure ... the private key may be protected in a
hardware token and/or software file can require a PIN to operate.

the next level of detail for the relying party (financial responsible
institution performing authentication, authorization and transaction
execution) could be labeled parameterized risk management .... i.e. much
lower level details regarding the integrity of the private key
protection (i.e. evaluation level of any hardware token), environment
and location that the transaction happened, other details of components
involved in the transaction, etc.

part of the conventional, single round trip, *straight-through
processing* financial transaction paradigm is a log as countermeasure
for replay attacks. In many conventional, internet *chatty* protocols,
one side includes a unique random number that the other party includes
in subsequent transactions (as countermeasure to replay attacks). In the
conventional, single round trip, *straight-through processing" model ...
the originator makes the transaction reasonably unique (like including
date/time, etc) and the relying party checks the current transaction
against a log of previous transaction (as countermeasure to replay attack).

turns out that logs/audit trails as useful in general ... and frequently
required anyway when performing financial transactions.

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