Hello Martin, On Fri, 2010-08-20 at 11:02 +0300, Martin Paljak wrote: > 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?
Correct. That's also the tag which is effectively used in the composed apdus. At least in the default driver. Maybe "sed s/SC_SEC_ENV_KEY_REF_ASYMMETRIC/SC_SEC_ENV_KEY_SYMMETRIC/g" would produces the code, the original author was intended to write. > To be honest, some things, like matching and passing around 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? Yes. > > 3. Support for symmetric encryption/decryption > Would be nice to have. For which card? Most cards should support at least 3DES. Newer ones maybe AES. CardOS does 3DES. > > 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. Is in preparation. Some things have to be cleaned before submission. > > 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. For shared keys, key import is required anyway. If this functionality where implemented, the encryption/decryption stuff could be worked on. > > Now what do you think? Are this the kind of improvements you would like > > to see in opensc? > Sure! _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
