> 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.
> Wrt PKCS#15 cards and such like. If they can be supported at the
> MuscleCard layer then that would be great. I think if a typical PKCS#15
> card could be handled then I think GPK and/or GemSAFE could also be
> handled. I'm not too sure how this would be done. For example how would
> issues like this be handled:
>
> 1. The card doesn't support the full range of algorithms: say RSA only,
> no DSA or DES, 3DES.
> 2. The card is read only: you can't create or delete objects at all.
>
> These could presumably be handled by some "query capabilities" function
> or similar. Does such a thing exist under MuscleCard or would an
> application have to interpret SW_UNSUPPORTED_FEATURE return codes?
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.
> 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.
Dave
***************************************************************
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
***************************************************************
