[ale] Smart cards

[Michael H. Warfield]

As many already know, crypto is one of my bigger passions.

I missed an important point I meant to address...

On Thu, 2011-10-06 at 21:41 -0400, Michael B. Trausch wrote: 
> On Thu, Oct 06, 2011 at 06:52:43PM -0400, Michael H. Warfield wrote:

Big snip...

> > All that said...  There are 2 types of Aladdin eToken cards.

> > There are the 72K (yes, I said "K" - you don't need much space for
> > keys) Java tokens (smart cards in a USB format).  These use their
> > Java cardlet to actually implement the crypto stuff in Java.  They
> > reserve some of the space for updates to the Java cardlet so you
> > really only have about 64K available on the card for keys (which can
> > store a couple dozen private keys - you don't store public keys or
> > whole certs on them).  Those will run you in the $30-$40 range from
> > CDW (cdw.com).  I've got a couple of those and don't really care for
> > them.  People claim the Aladin middleware (which uses a proprietary
> > protocol to talk to the cardlet) is buggy and klunky.

> Java.  On a card.  Sheesh.

Ok, I'm no big fan of Java either but all this crypto engine stuff is
implemented in some sort of software.  On some cards, it's done totally
closed in a "CardOS" (or similar proprietary) operating system that's a
total pain if something were to get screwed up.  CardOS is obviously
expensive and is WHY the CardOS cards are more expensive than the Java
cards.  Java amounts to the OS and the cardlet is the crypto engine
implementation.  Obviously, Java is not going to be as efficient or fast
as a down to the metal assembly language (assembly language peculiar to
the smartcard cpu - which is not a common chip) but do you really trust
a complex long advanced math crypto engine to assembly language like
that?  Pick yer poison, my friend.  You've got to trust something here.

> I must be missing something, though.  How can you do authentication if
> there aren't any certificates involved, unless you are keeping a
> database with every single public key.  I'd like to just sign a
> certificate and they can present that client certificate (or use it in
> any other valid way, for that matter).

[This is really the point I needed to address and missed - my
apologies].

No!  Certificates are involved.  There's just no need to store them on
the smart card.  The certificates do NOT include the "private key" of
the PKI key pair.  That's your secret key you use for all private key
operations on the card.  That's the only bit you need on the smart card
and it's relatively small compared to the cert (which is why the smart
card crypto store can be so small).  The certificate is all the public
information plus any metadata plus any signatures from CAs or CA chains.

With simple key authentication, you must keep a database of all the
public keys of the issued cards / tokens / keys that are active  That's
a given.

With certificates and a private CA, the client presents a blob that is
their certificate containing their public key signed by their private
key (that's a bit of a generalization that's implementation dependent)
with some meta data (X.509 ASN.1 format).  That includes the signatures
of the certificate made by the CA, which you can then verify.  You go
through a bit of a handshake with a nounce or some challenge to verify
that they really do have the private key that matches that certificate
which they presented (verified by the public key in the certificate from
them which was signed by your private CA).  That can actually be a
single pass challenge and response in the protocol.  The server
challenges with a nounce or challenge and the client responds with their
certificate and a signature matching the nounce and the cert.  I believe
SSL leads off with the cert first, though.  But it's not the only way
you can do it.

So, now the authentication chain is complete.  You know they have the
private key because it signed your challenge which you verified by the
public key they presented in their cert which was verified by confirming
the signature on that public key matches your CA private key by
verifying it against your CA public key.

You, the authenticator, don't need their private or public key in
advance and never need your CA private key, only its public key.  They
need their private key, which is from some sort of crypto storage device
(which could be just the secret key file) and their complete, signed,
certificate from their public storage.

In the meta data from that cert, you find start and end dates and
various other bits and attributes, all signed by your CA private key,
which you can verify using its public key.

The only other thing you need now to keep track of is a CRL (certificate
revocation list) in case you need to revoke or cancel a certificate.
That's your database in the CA authentication case.  In the simple case,
you track the authorized certs, in the CA case, you track the revoked
certs (which should, hopefully, be a much smaller database).


Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
Url : http://mail.ale.org/pipermail/ale/attachments/20111007/f36fb5d0/attachment.bin