Aaron Whitehouse wrote:
None. But a machine that had one purpose in life: to manage the bearer bond, that could be trusted to a reasonable degree. The trick is to stop thinking of the machine as a general purpose computer and think of it as a platform for one single application. Then secure that machine/OS/ stack/application combination.
Oh, and make it small enough to fit in the pocket, put a display *and* a keypad on it, and tell the user not to lose it.
iang
How much difference is there, practically, between this and using a smartcard credit card in an external reader with a keypad? Aside from the weight of the 'computer' in your pocket...
Theoretically, there may not be much difference, depending on where the theory starts...
Practically there are a bunch of differences, which are more or less issues, depending.
1. The data store (a.k.a. the smart card) is separated from the IO package. Is this an advantage or a disadvantage? For the most part it gives the user 2 tokens to worry about, the expense of an additional interface, and more mass, as you point out. I can't quite see any offsetting advantage myself in all that over one box that does the lot. So that's a minus.
2. The data store is in some sense secure. If it's got a car-valued bearer bond on it, that's probably not secure enough. It might give some security in the event of loss, but so would a combined package with some other password on it. It is a marginal security improvement over a single purpose non-smart package, and thus would have a primary benefit in marketing (see Blue). It's a plus, but a small plus, as a single-purpose package could just build in a smart card if it so desired.
3. The smart card interface is not good. It has to be taken out of your trusted reader and put in someone else's trusted reader. Bad news. So someone else's trusted reader tells you it is paying you dividends on your bond, when in fact it is replacing the bond with a mickey mouse loyalty coupon. Getting around that disadvantage costs systems operators a bundle of money and restrictions. This makes for a huge minus.
4. The smart card interface, part 2. In practice, smart card readers are an example of historical detritus. We all said "next year is the year of the smartcard" in 1995, and it still is. In practice, the interfaces we want on our bearer bond hardware token are these: 802.11x, ethernet, bluetooth, IR, ... in that approximate order, all with IP layered over and our real hot bearer transfer protocol, and not some hokey old telco thing. The smart card interface is another huge minus, because it means that the infrastructure is all specialised, the protocols are all closed, and the system is all controlled at some level or other, which means some big fella has to dig deep in the pockets to finance it.
Score card so far: 2 big minuses, one small minus, and a small plus.
That would seem to me a more realistic expectation on consumers who are going to have, before too long, credit cards that fit that description and quite possibly the readers to go with them.
Next year is the year of the smart card! In practice, that advantage is just a rationalisation. We can't use any of those tokens to store your bearer bond. If we are going to ask someone to store a bearer bond, we have to give that person the token. Which means we can start with a blank sheet of paper, we don't need to use any smart card patriotism to justify your choices.
iang
--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]