David Corcoran wrote:
>
> > I'm not sure I follow this. PKCS#11 implementations have been written
> > with no certificate handling at all: that is they just blindly store
> > them as an opaque blob with a set of attributes provided by the
> > application.
>
> Yes, but there is an interface to X509 certs in P11, which is the API an
> application or security framework needs unless they are just using the
> card for storage in which the MuscleCard API would be just fine.
>
Yes but it doesn't treat certificates in any special way. They can be
treated as an opaque binary blob thats just got a tag calling it a
"certificate" and various related attributes.
There are two separate issues here. If a card is always being used for
Netscape then it will automatically create the correct set of attributes
for it and the PKCS#11 implementation doesn't need to know anything
about certificates at all.
If however a card which contains existing certificates needs to be
"visible" on PKCS#11 then it needs a minimal ASN1 parser to fill the
relevant PKCS#11 attributes from the encoded certificate. Using
something like OpenSSL or an ASN1 compiler like SNACC is overkill for
this kind of thing. A minimal parser could just extract the relevant
fields using very little code.
>
> We are adding a GetCapabilities function - first to the client side API
> and then to the applet. For now XCard interprets the
> SW_UNSUPPORTED_FEATURE return. For example on Cryptoflex there is no
> RSA_1024_PRIV_EXPONENT, just CRT so I return SW_UNSUPPORTED_FEATURE.
> Also, I can only have 4 PINs currently. GetCapabilities will return it's
> crypto capabilities, number of keys/pins supported, a bitmask showing
> which functions are supported, etc.
>
> Here is how I did cryptoflex:
>
> /3F00
>
> 3FCE - directory for Objects
> FFFE - hidden status object (stores KeyInfo structs)
> 3FCF - directory for keys
> 1012 - public RSA key file
> 0012 - private RSA key file
>
> When I create directory 3FCE I set the size to 4k. When I do a dir on
> /3F00 I get it's size which is (totalMemory) I then subtract it's
> contents + header size and get (freeMemory) The FFFE key object file
> stores KeyInfo structs so I know what keys are on my card for ListKeys.
> It also maps Cryptoflex keynumbers to MuscleCard numbers through the
> keyPartner field. It all works perfectly - do don't even know it's a
> cryptoflex.
>
Well AFAICS for "classical" PKCS#11 you only need 2 pins. A user PIN and
an admin PIN. The admin pin unblocks the user PIN and doesn't do much
else.
Objects can be "public" (unprotected) or private (protected by the user
PIN).
Not a great deal more is needed for PKCS#11.
For GPK cards you can protect keys and EFs with one of two PINs from a
set of 8. They can also be protected with a two key triple DES
authentication scheme which relies on creation of a session key from a
key on the card. RSA keys files are a special format which typically
will contain the public key, some "use" ACL. The private key components
can never be read from a key EF but the public ones can if the ACL
permits it.
However the lack of any way to delete files makes things less straight
forward.
A typical layout might be like this (irrelevant stuff deleted):
0200/ crypto object DF
0002 transparent - public object store (public read and update)
0004 transparent - private object store (read and update protected by
user PIN)
0006 secret code (PIN) file containing 2 PINs, first unblocked by
second.
0007 RSA key file 1024 bits
0008 RSA key file 1024 bits
more RSA key files.
The number of key files and the size of the public and private object
files is typically determined when the card is personalised.
the PKCS#11 code then packs object data into the public or private
object file as required including certificates.
> > 3. The card has objects with a specific meaning: e.g. certificates.
> >
> > I'd guess that PKCS#11 stores things like certificates on a MuscleCard
> > as
> > objects with some additional header information to indicate the stored
> > object is a certificate. Presumably a driver for something like a
> > PKCS#15 card would need to make certificates (and other objects) emulate
> > the MuscleCard headers?
>
> Probably. For cryptoflex - a MuscleCard RSA_CRT looks like the following:
>
> [Keyblob Header (type size, optional ciphermode)][keyBlob (P, Q ... )]
>
> I unwrap this keystyle and place it in file 0012 depending on it's
> keynumber. It's pretty simple, just moving the CRT values around.
>
I'm more thinking about how you handle the PKCS#11 attributes such as
the local key ID and such like which are typically set by the PKCS#11
application. For things like certificates which can have several
attributes (though to save place some are typically implicit) they are
typically in a data file of some sort in some random format.
Steve.
--
Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED]
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
***************************************************************
Unix Smart Card Developers - M.U.S.C.L.E.
(Movement for the Use of Smart Cards in a Linux Environment)
http://www.linuxnet.com/
To unsubscribe send an email to [EMAIL PROTECTED] with
unsubscribe sclinux
***************************************************************
