Andre Zepezauer wrote: > 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. >
Thanks, I see better. Finally on Windows it also 'works for me' with the key 2048 bits . So, do you agree to close this ticket as 'already implemented' ? >>> 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. >> >> > > > -- Viktor Tarasov <viktor.tara...@opentrust.com> _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
