Hello, On Aug 20, 2010, at 2:02 AM, Andre Zepezauer wrote: > 1. Fix the SC_SEC_ENV_KEY_REF_ASYMMETRIC magic > See how this flag is used and where it is set! I don't see it being set anywhere and only used in a few set_security_env functions, incl iso7816.c, and most uses being direct copypaste of the iso7816.c logic AND code (relevant if block) with the exception of card-tcos.c where the code is different but logic same.
>From ISO-7816-4, I see: '83' — Reference of a secret key (for direct use), Reference of a public key, Qualifier of reference data '84' — Reference for computing a session key, Reference of a private key Would 84 is the actual wanted tag for RSA private keys? To be honest, some things, like matching and passing aorund in the call stack flags/information about algorithms, hashes and pads and figuring out what the card support and does not support, should be much more explicit than they are now. Some of the SC_* flag magic has evolved to a state where it does not make sense, probably because a bunch of code has been copied around until it started to "feel" right; a bunch of #defines exist for things that are actually not implemented at all (like setting the SC_SEC_ENV_KEY_REF_ASYMMETRIC flag) But improving it is no easy task. > 2. Assign the value sc_security_env_t.algorithm_ref before calling > set_security_env. A lot of drivers could use it. In pkcs15-sec.c? > 3. Support for symmetric encryption/decryption Would be nice to have. For which card? > The first point is the most easy one, if the affected drivers are > maintained and the one and only supported algorithm is RSA. My > suggestion is to rename this flag to SC_SEC_ENV_KEY_ASYMMETRIC. BTW it's > very amusing that two wrong assumptions lead to a correct result. Most card only do RSA, OpenSC PKCS#15 has no capabilities to create symmetric secret keys AFAIK (check pkcs15-init) Cleaning the flagging would be desirable, but having a flag that is not used would not be nice either. > For the second point I can supply a patch, which works for all well > initialised cards. That means for all cards where > PrivateRSAKeyAttributes.keyInfo.reference references an algorithm of > TokenInfo.supportedAlgorithms. If this is the case, algorithm_ref and > required padding are easy to determine for each individual key in use. Yes, please provide one. > Point three could be the hardest one. An implementation of pkcs15-skey.c > is required (pkcs15-prkey.c could be taken as an example). More importantly, the key needs to be exposed properly via PKCS#11 and secure generation of keys (if initialization support is available) to be implemented. Most probably this requires changes in src/pkcs11 as well. > Now what do you think? Are this the kind of improvements you would like > to see in opensc? Sure! Best, -- Martin Paljak @martinpaljak.net +3725156495 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
