Hello Martin, to make a long story short, there is an (easy?) way to get ride of the whole flag magic.
It would require more attention on TokenInfo.SupportedAlgorithms and implementation of CKA_ALLOWED_MECHANISMS. That's it. When these to mechanism are in place, things would still happen auto-magically. But in a more appealing way. Facts: 1. CommonKeyAttributes.algReference and PrivateAbcKeyAttributes.keyInfo.reference These two fields are supposed to reference one or more algorithms in TokenInfo.SupportedAlgorithms. For a visual representation of the information contained in TI.SA see [1]. For descriptions have a look at the specs. 2. With the above information an implementation of CKA_ALLOWED_MECHANISMS is trivial. 3. If CKA_ALLOWED_MECHANISMS is working, then the calling application can use C_SignInit only with mechanism actually supported by the given private key. 4. The buffer given in C_Sign could pass through down to the driver/card because we know that the key in question supports the requested mechanism. 5. Additionally the value of AlgorithmInfo.algRef should be passed to set_security_environment. It could be used in tag 0x80. Or in the case of PIV, as P1 or P2 in GENERAL AUTHENTICATE. That may sound strange at first, but all these pieces fit nicely together. Regards Andre [1] http://www.opensc-project.org/pipermail/opensc-devel/2010-October/015210.html On Mon, 2010-12-13 at 11:53 +0200, Martin Paljak wrote: > Hello, > > I'm somewhat confused by how OpenSC interprets the different algorithm > flags in PKCS#11 [1] and in the generic libopensc PKCS#15 code[2]. > Could somebody explain your view or what I get wrong. > > - SC_ALGORITHM_RSA_RAW (CKM_RSA_X509) - card is capable of raw RSA, > meaning it is willing to take in any data up to the modulus size and > encrypt/decrypt it, without additional processing (caller needs to > take care of details) > - SC_ALGORITHM_PAD_PKCS1 (CKM_RSA_PKCS) - card will take the input, > pad it with PKCS#1 and give the encrypted/signed result or decrypt, > remove padding and return the data. > - SC_ALGORITHM_RSA_HASH_NONE - Signals "the input is not a hash" ? > - SC_ALGORITHM_RSA_HASH_MD5_SHA1 - (SSL) - This should probably not > exist at all, SC_ALGORITHM_RSA_HASH_NONE should cover this. > - SC_ALGORITHM_PAD_NONE - ? Same as RSA RAW? Who will deal with > necessary padding? > - SC_ALGORITHM_HASH_SHA1|SC_ALGORITHM_PAD_PKCS1 (CKM_SHA1_RSA_PKCS) - > input is a SHA1 hash and card returns a PKCS#1 padded signature > - what about DigestInfo header? SC_CARD_CAP_ONLY_RAW_HASH and > SC_CARD_CAP_ONLY_RAW_HASH_STRIPPED, card flags for D-trust, should > control exactly this, but this is not a generic mechanism. Shouldn't > this be part of the algorithm specification, it is not a card > capability IMHO? > > If a card claims support for only _PAD_PKCS1 and _HASH_SHA1 only > (meaning it would like to sign SHA1 hashes and pad the result with > PCKS#15 and remove the PKCS#1 padding itself when decrypting), > sc_pkcs15_compute_signature will strip the DiggestInfo header if the > card does not claim SC_ALGORITHM_RSA_RAW and send the raw hash to the > card (similar to SC_CARD_CAP_ONLY_RAW_HASH_STRIPPED? I don't have > CardOS, so I don't know the cardos tricks.) Is it supposed to be so? > I'm confused. > > I would like it to be very explicit, without "surprises" or too much > automagic adjustments done by OpenSC (eventually the caller should > know almost exactly what is the input and the expected output what the > card supports, without much automagic transcoding in OpenSC), but I'm > not sure if I understand something basically incorrectly or the code > in pkcs15-sec.c and padding.c (sc_get_encoding_flags) is smarter than > I can manage. > > > [1] > http://www.opensc-project.org/opensc/browser/trunk/src/pkcs11/framework-pkcs15.c#L2511 > [2] > http://www.opensc-project.org/opensc/browser/trunk/src/libopensc/pkcs15-sec.c#L294 > > -- > @martinpaljak.net > +3725156495 > > I'm moving! martin.paljak.pri.ee -> martinpaljak.net > _______________________________________________ > opensc-devel mailing list > [email protected] > http://www.opensc-project.org/mailman/listinfo/opensc-devel _______________________________________________ opensc-devel mailing list [email protected] http://www.opensc-project.org/mailman/listinfo/opensc-devel
