Is there any future for smartcards?

[Anne & Lynn Wheeler]

Jaap-Henk Hoepman wrote:
> I believe smartcards (and trusted computing platforms too, btw) aim to solve
> the following problem:
> 
>   "How to enforce your own security policy in a hostile environment, not
>    under your own physical control?"
> 
> Examples:
> - Smartcard: electronic purse: you cannot increase the amount on
>   your e-purse (unless reloading at the bank).
> - Trusted computing: DRM: my content cannot be illegally copied on 
>   your machine.
> 
> As soon as the environment is under your won physical control, software only
> solutions suffice. 

a couple years ago ... i was on an assurance panel in the tcp/tpm track
at idf. during my 5 minutes ...
http://www.garlic.com/~lynn/aadsm5.htm#asrn1

i happened to comment that over the previous couple years that tpm had
gotten simpler and started to look more and more like aads
http://www.garlic.com/~lynn/index.html#aads

one of the tpm people was in the front row ... and replied that i didn't
have a couple hundred people on a committee helping me design a chip.

I even claimed that the original aads chip design could meet the then
tpm requirements with no changes.

some side drift into finread
http://www.garlic.com/~lynn/subpubkey.html#finread

a minor anecdote
htt://www.garlic.com/~lynn/2001g.html#57 Q: Internet banking

one of the things considered in the x9.59 financial standard
http://www.garlic.com/~lynn/index.html#x959

was the provisions of have two digital signatures on a transaction ...
one authenticating the originator and one from the signing environment.

two issues with respect to the finread standard has been 1) secure
pin-pad and secure entry of pin entry and 2) is what you are signing
what you see. finread provides for a hardened external device that
attempts to address both of these issues. the issue from a financial
institution authenticating and authorizing the transaction for risk
management ... is how does the financial institution (or other relying
party) really know that a finread terminal was used for a particular
transaction (as opposed to any other kind of terminal).

the finread standard specifies the operational
characteristics/objectives of the terminal/reader ... but doesn't
actually provide assurance to the financial institution (or other
relying party) that a certified finread terminal was used for the actual
signing environment.

this is sort of out of risk adjusted capital from basel
http://www.bis.org/publ/bcbsca.htm

.... all the possible risks are evaulated for an institution ... and
capital assets are put aside proportional to the evaluated risks.
approved transactions that have been signed by both the account owner
and a certified finread terminal should have lower possible risk than
transactions simply signed by the account holder (more unknowns and
possible vulnerabilities)

in financial transactions there typically are (at least) two interested
parties ... the individual as the account owner ... and the financial
institution as the relying party & potentially having significant
liability with respect to fraudulent transactions.

software may surfice when things are under your own phsyical control AND
nobody else has exposed risk related to operations performed in that
environment under. however, when there are other parties at risk, they
may ask for a higher level of assurance than simply a statement from the
individual that there have been no compromises. some collected postings
on assurance
http://www.garlic.com/~lynn/subpubkey.html#assurance

and fraud
http://www.garlic.com/~lynn/subpubkey.html#fraud

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