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