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 [EMAIL PROTECTED]