RE: Hello to the list (UNCLASSIFIED)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


Title: Re: Hello to the list (UNCLASSIFIED)
> > This means the enforcement of any attributes are in the middleware 
> > layer and not in the raw token itself.
> There already seems to be some enforcement (such as cannot sign
> with CAC Email Encryption Cert).
The PKI Applet specifications that I have seen do not mention any restriction on using the PRIVATE SIGN/DECRYPT command other than verifying the PIN first. I'm assuming that a signing operation using the private key associated with the email encryption certificate will be permitted by the PKI applet, and I will try this out later to confirm, but can you tell me where are you seeing this enforcement?
> What I'm reading is that the CAC API just does not align well with
> PKCS11.  Since you need to know the internals of a PKCS11 library
> (what label strings or CKA_ID values are used), the idea of a generic
> smartcard interface library is just not applicable to CAC. 
CAC was not designed with PKCS#11 in mind.  It is not an API itself, but a collection of java applets and a set of commands for accessing the applets on the card. The commands use standard Global Platform instruction set and additional instructions. 
In this respect it is no different to an Axalto Cyberflex card (for example), which also has a collection of java applets and a well-defined set of instructions for accessing those applets. I haven't seen the instruction set that Axalto publishes, but it will be Global Platform compliant, and in all probability does not include specific PKCS#11 data such as CKA_ID values. Those values will be determined in the Axalto PKCS#11 library.
I don't understand your concern with CKA_LABEL and CKA_ID attributes. The PKCS#11 standard mentions that CKA_ID attribute is only meant to distinguish multiple key pairs held by the same subject, but what the CKA_ID value should be is not defined or enforced. It is suggested, for interoperability, that this value should be the subject key identifier, but in reality it can be any value. Generally you locate the certificate you want, get its CKA_ID value, then locate the private key with the same CKA_ID value.
The CKA_LABEL is simply a description of the object, and may in fact be empty. There is no further information in PKCS#11 about the value that should be found in CKA_LABEL.
>  Further, I would infer that the CAC was never designed in a way to
> support a generic interface.  As an application developer, you would
> write your CAC application to use the "Acme Brand" CAC interface
> library.  Just hope that Acme doesn't go out of business or stop
> supporting your OS.
There are multiple references in the CAC documentation to the Basic Services Interface (BSI), which is a C language binding of an API defined in GSC-IS. I think there is a bundle in MUSCLE that uses BSI?  So if you write a BSI implementation that makes the appropriate PC/SC calls using the CAC instruction set, then it should just "plug in" to the MUSCLE PKCS#11 library (I'm not sure about this, but I think it is possible).
I haven't implemented a BSI layer yet (I'm calling PC/SC directly, as does Coolkey), but it looks trivial. There's no reason why a PKCS#11 library could not be built on top of BSI. There are various PKCS#11 vendors that provide a BSI implementation for CAC (such as ActivIdentity).
> Is the PIV any better in this respect?
Not to my understanding. It is a card layout and communication standard, just like CAC.

>>  In short your best bet is to build your applications on a crypto 
>> library that uses PKCS #11 (like NSS).
> When writing a security application, adding a such a large library
> where I'm using only 1 or 2 functions is undesirable (support,
> security, size, memory, etc).  All I need is a interface to the 
> token, preferably something standard and consistent.
PKCS#11 is that standard. But you must remeber that the token generally provides limited cryptographic support. Most tokens I have seen (Axalto, Gemplus, CAC, etc) will provide CKM_RSA_PKCS mechanism for signing and decrypting.  CKM_SHA1_RSA_PKCS may be provided for signing, but that is generally not done in hardware. So either the PKCS#11 library provides the hashing algorithm, or this is left up to the application before calling PKCS#11.
There are no standard set of mechanisms or operations that must be provided on the token. The application needs to interrogate the token to see what mechanisms it supports so that it can determine how to perform its cryptographic operations. Typically openssl would be used, and a EVP_PKEY that delegates its RSA operations to PKCS#11 would be required.
But if you do not want to use openssl, then your application must at least know how to generate SHA1 digests to be interoperable with most tokens. SHA1 is not difficult. You also need to know how to generate DigestInfo encodings, but these are constant and are defined in PKCS#1.
-- Geoff
Coolkey-devel mailing list

[Index of Archives]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Women]

  Powered by Linux