Financial identity is *dangerous*? (was re: Fake companies, real money)

[Anne & Lynn Wheeler]

At 10:29 AM 10/28/2004, James A. Donald wrote:
>Is there a phone that is programmable enough to store secrets
>on and sign and decrypt stuff?
>
>The ideal crypto device would be programmed by burning new
>proms, thus enabling easy reprogramming, while making it
>resistant to trojans and viruses.


there are a couple different trust relationships ... the issue of the user 
trusting the keyboard/terminal ... and the issue of the relying party 
trusting the keyboard/terminal.

The FINREAD terminal ... misc. (EU) finread references:
http://www.garlic.com/~lynn/subpubkey.html#finread

supposedly is certified as an stand-alone external keypad and display that 
can't (very difficult) in being hacked. the financial scenario is that the 
display can be trusted to display the amount being approved .... the user 
puts in his card and enters their pin/password. The pin-pad is certified as 
not being subject to virus keyloggers (that you might find if a PC keyboard 
was being used).

For the relying party (say an online financial institution) ... the user 
putting their card into the reader ... and the card generating some unique 
value ... would indicate to the relying party "something you have" 
authentication. The user entering a PIN can both indicate "something you 
know" authentication as well as implying that the user aggrees/approves 
with the value in the display.

Note that the implied agreement/approval ... in not just dependent on the 
user entering the PIN ... but also on the certification of the terminal ... 
that the terminal doesn't accept the PIN until after the certified terminal 
displays the correct value (i.e. there is a certified business process 
sequence).

The entering of the PIN can also involving transmitting some form of the 
PIN to the relying party ... and/or the PIN is passed to the smartcard/chip 
... and the chip is known to only operate in the appropriate manner when 
the correct PIN is entered. In this later case, the relying party doesn't 
actually have knowledge of the "something you know" authentication .... but 
the relying party can infer it based on knowing the certified business 
process operation of all of the components.

Lets say the unique value provided by the smartcard is some form of digital 
signature ... and the relying party infers from the correct digitial 
signature "something you have" authentication. There is still the trust 
issue between the relying party and the terminal used by the user .... 
which may also require that the (certified eu finread) terminal also 
performs a digital signature .... in order for the relying party to be able 
to trust that it really was a terminal of specific characteristics ... as 
opposed to some counterfeit or lower-trusted terminal.

There is still the issue of the user trusting such a terminal. If the 
terminal belongs to the user .... in the user physical home space .... then 
there isn't as much of a trust issue regarding the user trusting the terminal.

The problem arises for the user if they are faced with using a terminal in 
some random, unsecured location some place in the world. Even in the 
situation where a relying party receives a valid transaction with a valid 
digital signature from a certified, known finread terminal ... there are 
still a number of MITM attacks on finread terminals that might be located 
in unsecured locations (various kinds of overlays and/or intermediate boxes 
capable of performing keylogging and/or modified display presentation).

The personal cellphone and/or PDA ... with user "owned" display and key 
entry .... is a countermeasure to various kinds of MITM attacks on 
terminals in public &/or unsecured locations
(user has no way of easily proofing that they aren't faced with some form 
of compromised terminal environment).



--
Anne & Lynn Wheeler    http://www.garlic.com/~lynn/
   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20041029/9172661a/attachment.html>