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

Subject: Under the hood (was RE: How much is too much?
From: Kevin McLauchlan <KMcLauchlan -at- chrysalis-its -dot- com>
To: "Techwr-L (E-mail)" <TECHWR-L -at- lists -dot- raycomm -dot- com>
Date: Mon, 14 Feb 2000 11:15:48 -0500

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!"




Previous by Author: How much is too much? (Long, as usual)
Next by Author: RE: Typo of the week (was How much is too much?...)
Previous by Thread: Re: Dreamweaver Questions - URGENT
Next by Thread: Typo of the week (was How much is too much?...)


What this post helpful? Share it with friends and colleagues:

Sponsored Ads


Sponsored Ads