On Feb 22, 2010, at 9:48 PM, Martin Paljak wrote: > On Feb 23, 2010, at 02:59 , Nick Sayer wrote: >> Until and unless I load the muscle card applet, and format it, pkcs15-tool >> (which I believe is part of opensc) says the card is not supported. So >> musclecard appears to create a pkcs15 space that opensc can play in. > pkcs15-tool is part of OpenSC and thus should be discussed on opensc-devel > (or -user but there seems to be more people on -devel) > >> I was using the opensc pkcs11 module to do all of this. Switching over to >> the musclelib pkcs11 module, it says that the card is empty. >> So clearly the pkcs11/pkcs15 (whichever) space that is created as a side >> effect of loading the applet is permissive (despite the attributes on the >> keys denying it) about allowing private keys to leave the card. Shocking. > > PKCS#11 is a software API, PKCS#15 is an on-card structure specification. > Both OpenSC and Muscle implement the PKCS#11 API but only OpenSC > supports/creates/uses PKCS#15.
Well, I just want a solution. I don't really care which camp supplies it. :) Where I am now is that opensc pkcs11 works, but is insecure, and muscle pkcs11 is secure, for certain definitions of the word (that is, is useless). > > MuscleApplet is not a PKCS#15 applet so the support in OpenSC emulates a > filesystem (which is required for PKCS#15) for it to work. I'm not sure if > the structures created by OpenSC should be usable with the Muscle PKCS#11 > driver but apparently it is not. > > >> Now, signing jars with a smart card isn't what I set out to do, but I figure >> if I can sign jars with the JCE, that means that openssl ought to be able to >> use the pkcs11 functionality in the same way to set up SSL connections. > It should be like that indeed. Well, if I turn on the tracing in libmusclepkcs11, what I see is that when attempting to fetch the 0x103 (sensitive) and 0x162 (exportable) attributes on the key, the error is being returned. The JCE PKCS11 provider is attempting to use those attributes to determine whether or not the key is available to be returned, or, instead, it should use a shim object to wrap the key ID (which is going to be the case for an RSA private key). It gets back the ATTRIBUTE_TYPE_INVALID and vomits. I have spent the entire evening trying to write a bogus workaround that detects this situation and instead returns a boolean TRUE for 103 and FALSE for 162, only to wind up being hopelessly bogged down in trying to figure out how to make up the return type. Meanwhile, I wonder to myself why the applet wouldn't have those attributes set that way for a private key. _______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
