How to store the car-valued bearer bond? (was Financial identity...)

Ian Grigg iang at
Sat Oct 23 07:07:39 EDT 2004

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.


The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at

More information about the cryptography mailing list