On Thu, 2010-09-16 at 19:21 +0200, Viktor TARASOV wrote: > Hello Andre, > > Andre Zepezauer wrote: > > Hello Viktor, > > > > there are two distinct properties of CardOS, which I belief you have > > mixed. On key generation time one has to decide: > > > > 1. if the key can be used with sign or decipher (but not both) > > 2. the padding algorithm the card performs when executing a security > > operation with the generated key > > > > Now someone may wonder, why there are keys that can be used with both > > operations (sign+decipher). This is possible, because the RSA_PURE > > padding schema allows the emulation of one operation with the other one. > > That means, decipher can be emulated with sign and vice versa. > > > > Well, probably I've missed something. > > In the manual I see the chapter "3.43 SIGN BY DECRYPTION KEY". > It explains that the algorithm 'RSA_SIG (algo-id=0x88/0x86)' can be > performed when the proprietary command 'SIGN-BY-DECRYPTION' is applied > to the key, created with the algorithm 'RSA (algo-id=0x08/0x06)' . > > I tested this mechanism in a 'manual' APDU mode for the imported 1024 > and 2048 bits keys . > > PSO_DEC do not support the chaining and to perform decryption with > RSA2_PURE 2048bits the support of extended APDUs is needed. > For a while it do not works for me.
It works! Check that your reader supports extended APDUs and that the ifd-handler does it too. We are using omnikey readers with proprietary omnikey ifd-handler. > SIGN-BY-DECRYPTION, like PSO_CDS, uses internal padding, that's why no > needs of extended APDUs to use the key 2048bit. > > For that reasons I was considering this mechanism as a good one to > implement the double key usage. > > > > In general, only one single generic security operation is sufficient to > > perform signing _and_ decrypting operations, if RSA_PURE padding schema > > is used ***by the card***. This holds for every card! > > > Sorry, does the RSA_PURE algorithm uses the padding by card? If the BSO for a key was created with RSA_PURE algorithm, then the card performs PSO_DEC with 'rsa raw' padding internally. The resulting output will match the size of the key. For example when performing PSO_DEC with 2048b keys the response is always 256 bytes. > > Current opensc supports such a scenario through the NEED_USAGE flag, > > which is set by the CardOS driver of course. It works something like > > this: > > > > 1. if NEED_USAGE flag is set, then it is known to opensc that the card > > supports only a single operation per key (sign _or_ decipher) > > 2. if on card pkcs15 structure states key usage sign _and_ decipher > > for a single key, then opensc assumes: > > * padding schema RSA_PURE (correct assumption) > > * PSO_DEC for sing _and_ decipher > > (wrong assumption, because PSO_CDS is possible too) > > > Afais, PSO_CDS supports RSA_PURE_SIG, not RSA_PURE. > The RSA_PURE_SIG uses the card's padding. RSA_PURE_SIG means that 'rsa raw' is performed by PSO_CDS internally. Which will led to absolutely the same result as RSA_PURE and PSO_DEC. What is important here is the fact, that in both cases the raw padding is performed. > > Besides the sigh_with_decipher hack there is another problem which > > arises when on card pkcs15 structure states only one operation per key. > > > It's the subject of the next enhancement. > I suggest something like > http://www.opensc-project.org/opensc/browser/branches/vtarasov/opensc-sm.trunk/src/libopensc/pkcs15-prkey.c#L38 > > > > Then the padding schema ***used by the card*** is unknown to opensc. It > > hasn't to be RSA_PURE! Here the problem is, that it is impossible to > > decide if padding is done by opensc or the card itself. > > > Padding schema supported by key can be presented in the pkcd15 key > attributes as an 'mechanism' and 'algo_id' > of the supported (by key) algorithm. > http://www.opensc-project.org/opensc/browser/trunk/src/libopensc/opensc.h#L118 > > > On Thu, 2010-09-16 at 11:51 +0200, Viktor TARASOV wrote: > > > >> Hi, > >> > >> I would like to advance the ticket #151, > >> this ticket needs the clarification of the 'Sign by Decryption' status. > >> > >> As it actually implemented, sign-by-decrypt uses on the card level the > >> same command as for the 'PSO DEC' operation. Probably it works for other > >> cards, but not for CardOS. > >> (I use CardOS v4.3B and manual 'CardOS v4.2B User's Manual 09/2005'). > >> > > > > For me it works (CardOS v4.3B). But last svn check out is some weeks > > ago. Did you generate keys for PSO_DEC and with RSA_PURE? > > > > For the tests I used the imported keys Correction: Did you have created BSOs for PSO_DEC and with RSA_PURE? > >> To use sign-by-decrypt this card needs a distinct 'algo-id' when > >> creating key ('RSA' instead of 'RSA_PURE' currently used by card > >> driver), and an APDU distinct when getting signature. > >> > >> For CardOS card there is no means to get the 'algo-id' of existing key, > >> and the pkcs15 attributes are the only source of this value. > >> As for me, the most evident way to support sign-by-decrypt for CardOS is > >> to enrich 'security environment' with the 'algo-id', to store this value > >> into the private data of the card driver for the period between > >> 'set_security_env' and 'decipher' and finally deviate to the card > >> specific 'SIGN BY DECRYPTION KEY' procedure. > >> > > > > Would this also work for 'DECRYPT BY SIGNING KEY' scenarios? > > > > > >> Another way is to implement the common 'sign-by-decrypt' handlers, but, > >> as for me, it's not yet completely justified. > >> > >> I wonder if CardOS maintainers or CardOS users are interested by such > >> enhancement, otherwise I propose to change the type of ticket from > >> 'defect' to 'enhancement'. > >> > > > > Better support for CardOS would be very welcome. > > > > Regards > > Andre > > > > Kind wishes, > Viktor. > _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
