Re: [opensc-devel] Middleware-free USB PKI Tokens?
Andreas, Thank you for verifying that Microsoft's opinion that the card industry is striving for "card-edge compatibility" making you only need a single Microsoft-supplied driver, is completely unfounded! Although you didn't mention it, card initialization is the thing that really makes things difficult for customers. FIPS201/PIV does not even specify that part and we surely understand why :-) I'm still quite uncertain on what to emulate in order to get a middleware-free token. CCID yes, but above that level things looks much more unclear. Regards, Anders continuing the slow but not ceased development of a token that the card industry could never do... Andreas Jellinghaus wrote: > Am Freitag 16 April 2010 09:38:16 schrieb Anders Rundgren: >> If you wanted to provide a USB PKI token that would give the user maximum >> flexibility it seems that the device should support CCID. >> >> 1. As I understand,CCID only provides the basic communication and does not >>address higher level issues such as PKI, right? > > CCID is "reader level" i.e. how to talk to the card, make sure that > both small and large data blocks can be transfered, communication > speed, detecting and resetting cards, and - if the reader has a pinpad - > then also pinpad operations. > > my view on this issue is this: > if you buy a smart card reader or usb crypto token, make sure it works > perfectly with the original microsoft CCID driver, and the open source > libccid driver for linux. if the device needs its own driver instead > or has any problem with those standard drivers, it is not worth the > hazzle and should be avoided. > > (not comment on mac os X, as apple seems to be slow in using the > lastest libccid, and maybe does strange modifications on it...) > >> 2. Would a token that emulates FIPS201 and CCID be usable in most >>systems as is or is there another emulation that would be better? > no idea what FIPS201 is. > >> 3. You would need to "hijack" somebody else ATR in order to emulate >>in a (for the user) hassle-free way? >> >> 4. Other question: CCID allows you to exchange arbitrary data between >>the token and the host, right? > > with pcsc subsystem and a driver for it, you can ignore the details > how the device it attached to the pc (usb / serial / build-in), and > what vendor and product it is, as all that is solved. you can now > focus on the card. > > each card of course is different. it starts with the ATR and then > you have all the card capabilities, the commands, the security model, > and unique features. > > > hard disks are great - you can replace them, and they only differ > with speed and storage size and maybe seek time, but to the pc > they all look the same, and that is great - buy a new one, copy > the data, replace the old, done. > > in the smart card world everyone is doing their own thing, trying > to be different, implements different commands, different profiles, > different algorithms, different security modules, different features > and so on. that prevents unification and keeps the prices high. > > of course there is javacard, but it is expensive due to the patent > fees, and it doesn't help much, as everyone implements different applets > on top of it, so the result is different again. > > if you build a new device, and can implement any atr and command set etc. > that you want, you could clone some well known product, but that would > most likely get you into copyright issues, even if only the interface > was copied. (I'm no lawyer, so no idea here.) > > but maybe iso 7816-* is now good enough to code those commands the > iso spec has for a full working card? I'm no expert on the later > parts, as each card I know is different from them anyway. > > Regards, Andreas > ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] opensc 0.11.13 and openssl 1.0 oddity
Hello,
Jan Just Keijser wrote:
Martin Paljak wrote:
On Apr 16, 2010, at 09:51 , Aleksey Samsonov wrote:
I commented out the OPENSSL_config(NULL) and now it works ...
should this added as a patch? the FIXME seems to be to *remove* the
explicit call to OPENSSL_config; I can confirm that this works for
both openssl-1.0.0-beta4 and the official openssl-1.0.0 release
The FIXME means that call OPENSSL_config(NULL) may have problems and
needs more cleanup solution for loading GOST algorithms' implementation.
Does this mean that a fix in OpenSC is not needed and the problem lies
in OpenSSL land?
the problem is not in openssl land but in the way the GOST engine is
loaded by the pkcs11 software. The GOST engine requires a section in the
openssl.cnf file to load the appropriate shared library. The problem
(with openssl) is , is that you cannot register an engine twice. So when
a program loads and parses an openssl.cnf file which contains engine
definitions then the second attempt to register that enginte will cause
a failure.
I've built the GOST engine myself and did *NOT* specify an openssl.cnf
file : the gost engine still loads, but I am not sure if it is
functional. So the real question becomes: is this openssl.cnf section
still necessary?
Yes, this section is necessary for using GOST engine.
is it still required to run
OPENSSL_config()
during opensc initialisation?
Another solution might be to not call
OPENSSL_config()
but call
OPENSSL_config( "gost" )
instead; this will cause the openssl library to only parse the GOST
section (provided there is one) which should solve the problem as well.
Thank you! It works.
Could you please test attached patch?
However, what happens if the "gost" section is missing?
I think error must be ignored.
Finally, I also noticed that the behaviour of loading the
engine_pkcs11+opensc-pkcs11 is different when a card is present or not:
without a card the library initialized just fine (without patching
opensc , that is) . If I insert a card and then try to run
openssl engine -vvv -t -c
then I get the error reported previously . The same is true for trying
to sign a certificate request using a card.
cheers,
JJK
Index: src/pkcs11/openssl.c
===
--- src/pkcs11/openssl.c(revision 4246)
+++ src/pkcs11/openssl.c(working copy)
@@ -186,8 +186,8 @@
sc_pkcs11_register_openssl_mechanisms(struct sc_pkcs11_card *card)
{
#if OPENSSL_VERSION_NUMBER >= 0x1000L
- /* FIXME: see openssl-1.0.0-beta3/engines/ccgost/README.gost */
- OPENSSL_config(NULL);
+ /* see openssl-1.0.0/engines/ccgost/README.gost */
+ OPENSSL_config("gost");
#endif
openssl_sha1_mech.mech_data = EVP_sha1();
sc_pkcs11_register_mechanism(card, &openssl_sha1_mech);
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] opensc 0.11.13 and openssl 1.0 oddity
Hello, Call OPENSSL_config(NULL) was need for loading GOST engine. It was need for applications which use PKCS#11 (opensc-pkcs11.so) with GOST algorithms and which don't use openssl directly (not call OPENSSL_config(NULL)). Jan was right, he wrote more detailed: Jan Just Keijser wrote: > the problem is not in openssl land but in the way the GOST engine is > loaded by the pkcs11 software. The GOST engine requires a section in the > openssl.cnf file to load the appropriate shared library. and to load (if not defined OPENSSL_NO_STATIC_ENGINE) static engine. > The problem (with openssl) is , is that you cannot register an engine twice. So when > a program loads and parses an openssl.cnf file which contains engine > definitions then the second attempt to register that enginte will cause > a failure. > > I've built the GOST engine myself and did *NOT* specify an openssl.cnf > file : the gost engine still loads, but I am not sure if it is > functional. In this case GOST algorithms do not work. In this case command "openssl genpkey -engine gost -algorithm gost2001 -pkeyopt paramset:A" works. But application which use PKCS#11 (not called OPENSSL_config) doesn't work. > So the real question becomes: is this openssl.cnf section still necessary? Yes, it is. Andreas Jellinghaus wrote: > Am Samstag 17 April 2010 16:30:02 schrieb Martin Paljak: >> Compatibility with OpenSSL 1.0 is a good reason for a new release but I've >> not yet understood if it really is a problem with OpenSC or OpenSSL >> (reading up) > > as far as I understand the issue: > * the combination of openssl, gost engine and opensc has problems > * to work around that, the config loading in opensc was disabled > * that breaks normal openssl + engine_pkcs11 + opensc combination. > > so I think it is best to revert the hack for gost, so normal users > can again use opensc with openssl and engine_pkcs11. > > the problem with gost engine remains then, but I don't know it > well enough to say if the problem is in openssl, gost or > opensc. > > or maybe the problem is using openssl with two engines > (gost and engine_pkcs11) which both load opensc? not > sure if I understood this right. but if the situation is like > that, maybe the engines should be merged into one engine that > handles both rsa and gost encryption? > > I guess Aleksey can explain the situaiton best (added as cc:). > > Andreas > ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Fix Netkey SigG application
Hi Christian Somewhere between 0.11.4 and 0.11.8 the SigG application of > "TeleSec GmbH" Netkey cards got broken. > Yes and this was due to an incorrecr renumbering of the PINs. The SigG-key of both TCOS2 and TCOS3-cards are protected by PIN 5. Both cards have 6 different PIN (PIN 1 - 6), but these PINs were incorrectly given the following IDs: 1,2,3,4,6,7. No wonder OpenSC had problems when trying to use the SigG-key after verification of PIN 5. Sorry for any inconveniences this might have caused. And thanks very much Christian for your testing an patching efforts. By the way: OpenSC does not support the SigG-key of TCOS3-cards as this key can used with secure messaging ONLY, And OpenSC does not support SM yet. So I assume you are still using TCOS2-cards. But all Signature-Law conforming 1024bit certificates should have expired by now. So for my own curiosity: What are using the SigG-key on TCOS2 cards for? Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [OpenSC] #216: By default support just a single reader subsystem (on Linux)
On Sat, 2010-04-17 at 08:10 +, OpenSC wrote: > I don't think we should discuss pcsc-lite issues in the OpenSC bug > tracker. At least, it allows anyone to participate. I have beed testing OpenSC pcsc+ccid extensively and I think it needs fixes as regards USB and concurrent access. IMHO every developer should stop working and its own project during 2 weeks and we should organize a run to fix these libusb + OpenCT + OpenSC issues. Kind regards, Jean-Michel -- Jean-Michel Pouré - Gooze - http://www.gooze.eu ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
