Hi. I have a generic question regarding this issue and a possible "fixup" for it as well.
A security audit which included Estonian eID code paths in OpenSC (via PKCS#11 module) and OpenSC.tokend noticed that there are several places that cache (the) PIN code(s) (In case of Estonian eID it is only PIN1 as PIN2 never gets cached because of non-repudiation/user consent implementation), do it differently and do it insecurely - without limiting its re-use, protecting the memory from being swapped/ read etc. Uniform PIN handling is also important for pinpad integration - for example to enforce a common policy for both PKCS#11 and Tokend. There are currently multiple pieces of code that deal with PIN caching: PKCS#11 module which caches PINs and has its re-validation logic and has the option to turn it on or off; OpenSC.tokend caches PINs and has it's own caching and re-validation logic without a way of turning it off; then there is sc_keycache_* in src/pkcs15init which is used by pkcs15-init tool and in the PKCS#11 module. As I understandit, in the PKCS#11 module it is there only for presenting the PIN-s that have been presented to the PKCS#11 module to the pkcs15init library so that it would work. So basically the sc_keycache code in framework- pkcs11.c translates the PKCS#11 PIN cache to the pkcs15init/keycache.c to be used by another PIN cache implementation Looking at pkcs15init/keycache.c, I understand that it tries to be a generic key caching framework (for pkcs15init only?) as it has references to things like "128bit symmetric keys", but all uses of sc_keycache_* in other files seem to only deal with adding/forgetting/ finding PIN codes. I don't know if/how the keycache.c implementation could or should be used for example with secure messaging or if there are any other caching scenarios. I'm not an expert on pkcs15init nor know the historical and philosophical reasons for the separation between libopensc and pkcs15init. To fix the issues I mentioned, I removed PKCS#11 PIN cache, removed Tokend PIN cache and implemented a common PKCS#15 layer (attached to sc_pkcs15_card_t, named sc_pkcs15_pincache_*()) PIN cache that operates in pkcs15-pin.c, is used from pkcs15 layer functions (adding a PIN to cache in case of verify, change, unblock; using it in pkcs15-sec.c for sign, decrypt) and has minimal "advanced" features like locking the memory and having a configurable retry counter (Need to re-enter the PIN code after it has been used for 3 times. Maybe a time based policy will be implemented in the future). The sc_keycache things I did not understand nor need for the read-only Estonian eID, so I just commented out the relevant code in pkcs11/ framework-pkcs15.c. I'll push the change to my 0.12 branch for review, but I have a few questions that can be answered without the patch: - Why a separate pkcs15init library? Are there any real life users of the separate library? What are the reasons? Do we need it? Why not a single libopensc.so? - Do we really need 3 implementations for PIN caching? Why a sc_keycache thing in src/pkcs15init when by name it should belong to src/libopensc, as a "generic keycache" ? Does a sc_pkcs15_auth_id -> PIN value mapper suffice? My suggestion would be to remove pkcs15init as a separate library and have a single libopensc.so; to have a single PIN cache that deals only with PIN codes and it's peculiarities (namely user consent, pinpads, memory handling and cleaning) and have it on the lowest common nominator, which seems to be the PKCS#15 layer and mapping sc_pkcs15_id_t auth_id things to PIN values, in src/libopensc; to clean the code up of things that try to do something but don't really do it, which no-one maintains and no-one really knows about and give OpenSC a better shape. Answers to questions and thoughts on this subject are most welcome. On 17.09.2009, at 9:37, Ludovic Rousseau wrote: > Hello Roman, > > I have no idea what your patch is doing. So I can't say if it works or > not, or has side effects. > > Anyone else has a comment on it? > Should we just (blindly) apply it? > > Bye > > 2009/9/10 Roman Himmes <him...@idev.de>: >> Hi, >> >> regarding to our problem with accessing multiple PIN protected >> storages with pkcs11, we investigated the problem. >> It seems that the keycache may get entries, with an invalid length >> arguments. >> >> >> Problem that has been solved with the attached patch: >> >> Prerequisite: 2 PIN protected areas on CryptoToken ( We used the >> Alladin eToken32 ) >> >> If you have logged into PIN1 and closed the session, and immediately >> log into PIN2, creating Objects may fail with different error >> messages. ( Internal OpenSC Error / Free space too small etc ... ) >> >> >> Index: opensc-0.11.9/src/pkcs15init/keycache.c >> =================================================================== >> --- opensc-0.11.9/src/pkcs15init/keycache.c (revision 21) >> +++ opensc-0.11.9/src/pkcs15init/keycache.c (working copy) >> @@ -264,6 +264,10 @@ >> s = new_entry(path, SC_AC_CHV, ref); >> if (s == NULL) >> return SC_ERROR_OUT_OF_MEMORY; >> + >> + s->len = sc_keycache_get_key(path, >> SC_AC_CHV, -1, s->value, >> MAX_SECRET); >> + if(s->len < 0) >> + return SC_ERROR_OBJECT_NOT_FOUND; >> } >> >> /* Set the pin name */ >> >> _______________________________________________ >> opensc-devel mailing list >> opensc-devel@lists.opensc-project.org >> http://www.opensc-project.org/mailman/listinfo/opensc-devel >> > > > > -- > Dr. Ludovic Rousseau > _______________________________________________ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel -- Martin Paljak http://martin.paljak.pri.ee +372.515.6495 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
