G'day,
Some background on CAC.
The common access card contains a
collection of Java applets. There is a well-defined API for the PKI applet,
which allows access to a certificate, PIN verification and
certain cryptographic operations. There should be three instances of the
PKI applet on the card: one for the authentication certificate, one for the
email signing certificate, and one for the email encryption certificate. In my
application I am only interested in the email signing certificate since it
contains the necessary Microsoft extensions for smartcard logon via
PKINIT.
The PKI applet API is quite simple and it
took me only a few days to construct the necessary smartcard protocol
commands and make the necessary PC/SC calls to access a CAC (Coolkey is
fine, but I just wanted a CAC implementation, not a CAC implementation +
arbitrary MUSCLE app implementation, so I went back to the reference
documentation and built my own).
But there is no PKCS#11 profile defined
(that I am aware of) that sits above the PKI applet. There is a Basic Services
Interface (BSI) layer defined, but nothing higher level than that. Any PKCS#11
implementation needs to make arbitrary decisions on how certain PKCS#11 meta
data (such as token labels, CKA_ID attribute values, etc) are
represented.
It should also be noted that CAC is being
replaced by PIV, although there are plans to introduce transitional cards
that are CAC with PIV.
> 1. PKCS11 cert labels are
arbitrary: while this is not
> technically incorrect, it is
inconsistent from one PKSC11
> library to another.
Is there anything _actually_ on the
> CAC itself that can/should be
used as the label?
PKCS#11 token labels are not defined by
CAC, so the actual values are arbitrary and up to the particular PKCS#11
library. Similarly for other meta-data such as token manufacturer
ID.
> 2. PKCS11 key usage attributes
for certificates/keys. While
> they seem to match the EKUs of
the certs (card applets), the
> SIGN/DECRYPT/ etc. attributes of key
objets are hard-coded
> in the lib.
The PKCS#11 key objects have capabilities,
but PKCS#11 does not enforce any restriction other than PIN verification on
whether such capabilities can be accessed. It is really up to the application to
get the key usage details from the certificate (and also check that the
certificate has not been revoked, etc) and then decide if the appropriate
PKCS#11 private key operation should be called.
> 3. "Other" Mechanism support. Is CKM_RSA_PKCS really the
> only supported PKCS11 mechanism
for CAC?
The PKI applet on the CAC supports a PRIVATE SIGN/DECRYPT operation, and since the CAC only contains certificates with RSA keys, this means that only raw RSA with PKCS#1 padding operations are supported. This maps neatly to CKM_RSA_PKCS mechanism in PKCS#11.
Of course, the PKCS#11 library may implement SHA1 internally to allow CKM_SHA1_RSA_PKCS mechanism on top of CKM_RSA_PKCS, if necessary. But in general some other crypto library would be used to generate the SHA1 digest and create the necessary ASN.1 DigestInfo encoding before calling C_Decrypt or C_Sign.
> 4. Did the actual CACs recently
go from a 1-byte to a 2-byte CKA_ID
> for cert/key objects or is the size of
the CKA_ID value a library-
> specific thing?
How a PKCS#11 CKA_ID attribute is
defined is up to the PKCS#11 library. This has nothing to do with CAC. The
PKCS#11 library built on top of CAC can use arbitrary values, so long as the
CKA_ID for the certificate, public key, and private key objects are matched. I
think that Coolkey uses the PKI applet instance here (in two bytes), but
generally the CKA_ID would be the subject key identifier value.
> Is there even a decent mapping between the CAC applet
> API and the PKCS11
interface?
Not that I am aware of.
> I don't know what the CAC applet API looks like, if this is
> even possible, but looking
through the CoolKey code that
> supports CAC (as well as the code
for MUSCLE-based
> implementations such as
MacOS PKCS11), it just seems
> very arbitrary. If a CAC applet
API document exists, I
> would like to see it.
Send an email to cacsupport@xxxxxxxxxxxxxxxx and ask
for the CAC developers kit and some test cards. You may also wish to request the
"DoD Implementation Guide for Transitional
PIV II SP 800-73 v1" document as well.
-- Geoff
_______________________________________________ Coolkey-devel mailing list Coolkey-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/coolkey-devel
