Under the hood (was RE: How much is too much?

[Kevin McLauchlan <KMcLauchlan -at- chrysalis-its -dot- com>]

Well, thanks hugely to all who replied, 
especially Geoff, who had the most detailed 
help, including some specific suggestions that 
I shall immediately co-opt.   :-)


To clear up a couple of misconceptions -- if 
anybody is interested -- the product and procedure 
are not quite what some people imagine.

The product is a cryptographic token (it's built 
into a PCMCIA card). To meet the requirements of 
FIPS 140-1 level 3, it requires a specially-modified 
card-reader and a hand-held device that uses a 
non-standard, secure port to perform access control 
and maintenance functions.  That is, you plug the 
token into the reader, and your computer (usually 
an enterprise Certificate Authority server) can do 
certificate operations via the token.  No crypto 
or certificate material ever enters or leaves the 
token in clear. The access-maintenance device (the 
hand-held thingie) uses a separate port (mentioned 
above) so that no passwords ever pass through a 
host bus, nor ever reside in host memory, nor ever 
reside on the host hard disk.  All transactions 
along that special interface cable are also encrypted.

The token is about as flexible as can be made, 
within the FIPS restrictions.  The handheld 
device accepts key-like devices that carry the 
passwords for User and Security Officer -- these 
would be "something you have" in security parlance.
Additionally, there is the option for a separate 
PIN that can be typed in from the keypad of the 
handheld device -- this would be "something you 
know" in security parlance.

There's another key-like device that carries what 
we call a "domain" that can be applied to several 
tokens, allowing them to be clones of each other. 
That feature allows backups and allows more than 
one "operational" token, all containing the same 
cryptographic entities to co-exist. Other tokens 
in the world might belong either to no domain or 
to other domains.

For those who are paranoiacally fanatic about security, 
there's a feature (using some more key-like devices) 
that allows yet another access-control secret to be 
split over several physical "keys" so that the token 
can be maintained or activated (for use by your application 
program) *only* if a certain number of these key-holders 
come together simultaneously, with the holder of the 
SO or User key...  who also need to know the typed-in 
PIN, if that option was activated...  
(paraNOY-ya will desTROY ya...)   Think of the antics 
required to launch a nuclear missile, and you have 
some idea.

As the manufacturer, it's not our place to set up all 
these controls, nor to decide which of them the customer 
will select. Our place is to provide the token and to 
make the selection/set-up possible... and to explain 
what all the options are, and to explain what the 
likely-non-obvious implications of each option might 
be.... and to explain what the very-non-obvious 
implications of COMBINATIONS of those options might 
be, and to tie the choices and the implications to 
what *should* be (but sadly, often isn't) a well-
thought-out security protocol at the customer location.

That is, by rights (because they are IN the business 
that needs our kind of product) the customer should 
have a comprehensive and severely-over-planned security 
procedure in place, and that procedure should now be 
modified to accomodate the introduction of our product.
Some are too young in the business to have had it all 
worked out. Some have lost key, experienced employees 
to competitors via the usual employee-churn that happens 
in any fast-paced business.

Anyway, you get one of our tokens -- and its ancillary 
equipment -- and you need to do two things. You need 
to initialize the token (and associated key-thingies) 
and to decide to what groups it will belong, what 
backups you will make, what options you will invoke, 
how many people (and which ones) will be involved, etc.
Having done that, you need to tell your own application 
program to start using our tokens, and to stop doing 
everything in horribly-insecure host-space.

The token enforces time-outs for security reasons. It 
simply can't allow itself to lie around being massaged 
for long periods by possible attackers who are trying 
to get at its contents.  The hand-held access device 
has time-outs for similar reasons.

Our interface program could certainly be lots nicer, 
but the constraints of the hardware/firmware are 
deliberately in place and not subject to loosening 
any time soon.

The whole process of initializing a token would take 
well under ten minutes.  The operator is prompted 
at every step.  Unfortunately, the choices the operator 
must make have implications.  If you put the token into 
operational status and THEN decide you made some 
inconvenient choices, you CAN re-initialize, but at the 
cost of any certificates/contents.  If the contents 
included the root-key for your enterprise... then you 
have a huge expense and a credibility problem.

Similarly, when you initialize a token, you can have 
it create a new domain on itself and on the domain key, 
implying that this token is to be the first of a new 
domain group. You make that choice by a Y/N answer on 
the handheld device.  If you make the choice that says 
"this token begins a new domain/cloning-group", then 
you've ensured that it can't belong to an existing 
group... and that the associated key can't either. 
Of course if that key DID belong to another group, it 
just got overwritten and you can't use it to 
unlock the previous group of tokens... whoops! Hope 
you made a backup.

This little peek at my nightmare has no doubt been 
too long and boring, but it's been just a peek. You 
really don't want me to get into what's involved 
when you have several tokens in operation, at least 
that many in secure storage as backups, some of them 
sharing key-like devices while others have their 
very own that they do not share, but all of the 
key-like devices also have physical backups... and 
then your house security commandments tell you to 
change your passwords monthly.  Um, the authentication 
codes on the key-like devices are considered to be 
passwords, for the purposes of your security policy, 
right?

Hmm.  Well, you know those little puzzles that have 
letter/number tiles with one open space, and you 
have to slide all the tiles around, one at a time, 
until they line up in the correct order?  Well, it's 
like that but a bit more complicated.  I use terms 
like "round-robin updating scheme", "exponential 
increase in complexity", and "do you really want to 
do this?"

But hey!... if it wasn't a challenge, would *I* be 
doing this?     :-)


/k

"Goodight, Mrs. Calabash, wherever your are.
 HOT-chachacha-CHAH!"