Re: [opensc-devel] Initialisation of CardOS
Hello? On Aug 30, 2010, at 11:13 PM, Andre Zepezauer wrote: Hello all, what do you think of dropping the possibility to initialise CardOS smart cards in 0.11.14? The reason of doing so, is to stop the production of more of these questionable split-key cards. What would be the rationale of doing it? I don't think turning it off is a good idea, but a fat warning (Use a more recent version!) could be used, if justified and needed (why?). People who want to initialise CardOS are then forced to do this with either 0.11.13 or 0.12.X. Hopefully they chose the newer release, because it comes with an improved initialisation for CardOS. No more split-keys here! Cards initialised with 0.12.0 should work with the 0.11.X releases too. Verification of this fact is required of cause. I believe documentation is important here. Due to the nature of smart cards, backwards-compatibility for already personalized cards is greatly desired and a topmost priority. At the same time, personalization happens far less frequently than use, so such restriction could, in theory, make sense as well (requiring newer software for personalization but working with older software in read-only mode) Another fact is that for example Ubuntu 10.04 and Debian Squeeze will stay with the 0.11.X branches for at least the next three years. The same holds for other distributions with a long release cycle (RHEL has seven years of support I think). The imagination that someone could easily produce new split-key cards for the next few years isn't very appealing to me. We can't fix what we can't affect. That is Linux distribution release schedules or decisions done between the chair and the keyboard. We need to make the choices and circumstances clear and well documented though. -- Martin Paljak @martinpaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Problem with 2K keys and MyEID
Thanks Victor! No objections here, the patch looks good. br, Toni -Original Message- From: opensc-devel-boun...@lists.opensc-project.org [mailto:opensc-devel- boun...@lists.opensc-project.org] On Behalf Of Viktor TARASOV Sent: 30. elokuuta 2010 16:19 Cc: 'OpenSC-devel' Subject: Re: [opensc-devel] Problem with 2K keys and MyEID Aventra development wrote: The 1K key generation works nicely, but we are having a problem generating a 2K key using OpenSC 0.11.13 and our own MyEID card. OpenSC correctly finds a new file id and creates the file, and after that it tries to store the key to that file. The issue is that the created files size is only 1024 bytes, so the card will answer with 67 00 (Wrong length). Some code in OpenSC decides to create the wrong sized file, but I have not been able to find it. Now Im curious that, does other cards work when generating (or just loading) 2048 byte keys? For me, to generate the 2048 bits key on the Aventra card, the following path was needed to be applied to the OpenSC trunk. If no objection, I'll commit this patch to trunk. Regards, Toni Sjöblom Kind wishes, Viktor. -- Viktor Tarasovviktor.tara...@opentrust.com ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Personal Review Of The Upcoming 0.12.0 Release
On Aug 30, 2010, at 5:16 PM, Andre Zepezauer wrote: Possibly libksba could replace openssl in the future. It provides the functionality required by opensc (certificate and public key handling) but without the cryptographic operations. I haven't used it in the past, therefore I can't tell you any details. But it may be a target of evaluation. http://www.gnupg.org/related_software/libksba/index.en.html http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/trunk/src/ksba.h?revision=322root=KSBAview=markup Alternative possibilities would be nice, but unfortunately OpenSC is pretty deeply interwoven with OpenSSL, as it has been an approved library. It would be nice to collect Windows specific (mostly registry) code in OpenSC into a platform_windows.c kind of place and OpenSSL related things to crypto_openssl.c with a common interface, so that it could be switched to crypto_gnutls.c for example (or to libksba). But that's pretty low priority. It also causes some confusion, like unwanted behavior differences depending on the chosen crypto library (some Linux software can be used with GnuTLS or OpenSSL (and maybe also NSS?) and behave differently). At least subversion and the SSL renegotiation issue behaved differently with libneon (with OpenSSL) and libneon (with GnuTLS). -- Martin Paljak @martinpaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] use algorithm_ref in set_security_env
Andre Zepezauer wrote: On Mon, 2010-08-30 at 17:50 +0200, Viktor TARASOV wrote: Hello, Andre Zepezauer wrote: Hello, attached is a patch which makes it possible to explicitly request specific algorithms for the cryptographic operations. The advantage is, that if the token provides sufficient information about itself, then the driver is not required to do any guess work. Which in turn could result in a more reliable operation of libopensc. Furthermore there could be positive effects in terms of compatibility with tokens not initialised by opensc. My recommendation is to test/improve this patch in an experimental branch or something like that. The reason for this is, that ALG_REF_PRESENT is not in use since revision 177 and I assume a lot of drivers to misbehave or crash at first. Few remarks about your patch. Private key can be used with more than one algorithm. So, IMHO, in the 'sc_pkcs15_prkey_info' it's better to have some array with the references to the crypto algorithms supported by PKCS#15 card (and defined in tokenInfo). Not a good idea, I think. Because the sc_pkcs15_prkey_info structure should also be the input of the prkey-Encoder. Remember that the standard allows only one reference per key. If the encoder gets an array of references, then all references of this array must be dropped except one. Which one? Can you develop, please? Prkey-Encoder? One 'key reference' or 'algorithm reference' per key? 1) The scenario you described would also be possible through a direct lookup of TokenInfo.supportedAlogrithms. The algorithms supported by key is not the same as algorithms supported by PKCS#15 card. The first one, in general, is the sub-set of second. 2) Another point to mention is, when using X.509 certificates the algorithm to use is fixed by the certificate. For example: SubjectPublicKeyAlgorithm := PKCS#1 SHA-1 With RSA Encryption Because X.509 is predominating at this time, there is little use for multiple algorithms per key. 3) And there is the CKM_RSA_X_509 algorithm, which allows for every kind of padding and hashing with a single key. It can be the cases when private keys are created (or key slot allocated) before the corresponding certificate is imported and without knowledge about the future usage of these keys. For this reason and for the sake of simplicity, there are can be the keys that are able to accept different algorithms -- 'general purpose' keys. The question is -- should PKCS#15 structure reflect the real key attributes or only the 'useful' ones? Looking at all these facts, I think a single reference per key should work fine in almost every case. It's this 'almost' that I'm a little bit worried about. The same concerns security environment (SE) -- the number of algorithms can be defined in one SE. Haven't worked on this. Regards, Andre Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] pcscd access rights limitation and scard group
On Aug 30, 2010, at 4:20 PM, Ludovic Rousseau wrote: 2010/8/30 Martin Paljak mar...@paljak.pri.ee: Hello, On Aug 30, 2010, at 12:19 PM, Ludovic Rousseau wrote: As listed on the pcsc-lite TODO file [1] I would like to run pcscd as a normal user instead of root. To do this I need to: Good idea. But since both OpenCT and pcsc-lite should not be installed at the same time the problem is very limited. I'm sure there will be accidental violations of this (IMHO essential) rule for quite some time. So better to have different group names. I thought that OpenCT changes the access rights of the devices. But it looks like it is not the case. The udev rule is just used to start openct-control (as root?). Exact? Any OpenCT expert (or user) can confirm? Apparently correct. ps: root 2720 0.0 0.0 1932 456 ?Ss 11:14 0:00 /usr/sbin/ifdhandler -H -p ePass3000 usb /dev/bus/usb/002/003 ls: crw-rw-r-- 1 root root 189, 130 Aug 31 11:14 /dev/bus/usb/002/003 -- Martin Paljak @martinpaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Problem with 2K keys and MyEID
Martin Paljak wrote: On Aug 30, 2010, at 4:19 PM, Viktor TARASOV wrote: For me, to generate the 2048 bits key on the Aventra card, the following path was needed to be applied to the OpenSC trunk. If no objection, I'll commit this patch to trunk. Do you know which changeset caused it? It seems that generation of 2048 bits key was never possible for the Aventra cards. The key file was instantiated from the card profile, but the file size was not changed to the size of the key to generate. Look starting from: http://www.opensc-project.org/opensc/browser/releases/opensc-0.11.13/src/pkcs15init/pkcs15-myeid.c#L329 Regards, 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
Re: [opensc-devel] Problem with 2K keys and MyEID
On Mon, 2010-08-30 at 15:19 +0200, Viktor TARASOV wrote: Aventra development wrote: The 1K key generation works nicely, but we are having a problem generating a 2K key using OpenSC 0.11.13 and our own MyEID card. OpenSC correctly finds a new file id and creates the file, and after that it tries to store the key to that file. The issue is that the created file’s size is only 1024 bytes, so the card will answer with 67 00 (Wrong length). Some code in OpenSC decides to create the wrong sized file, but I have not been able to find it. Now I’m curious that, does other cards work when generating (or just loading) 2048 byte keys? For me, to generate the 2048 bits key on the Aventra card, the following path was needed to be applied to the OpenSC trunk. If no objection, I'll commit this patch to trunk. Hello Viktor, I would write the check for supported modulus length a bit more generic. But it's functional the same like yours, because myeid supports only 1024 and 2048 bit (at least the driver does). Therefore it doesn't matter a lot. #include internal.h pkcs15init/pkcs15-myeid.c:513 /* check that the card supports the requested modulus length */ if (_sc_card_find_rsa_alg(p15card-card, keybits) == NULL) SC_TEST_RET(ctx, LEVEL, ERROR, MSG); On the other hand it would be fine to give a good example, because someone may want to copy+paste your code. See copy+paste in the card drivers [1]. The same check also occurs in line 427, 514, 574, 637. And interestingly _always_ some lines below there is the following conditional assignment: if (file-size 1024) file-size = 1024; Regards Andre [1]http://www.opensc-project.org/pipermail/opensc-devel/2010-August/014615.html ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [Muscle] Re: pcscd access rights limitation and scard group
Johannes Findeisen wrote: I think it is important to pay attention to the original goal: to run pcscd as a normal user instead of root. Yep, that's what I want too. But, when running pcscd as normal user, this normal user need access to the device. Ok, you could make it usable for all users. Then you are right. No need for an extra group. I sense a miscommunication. Is the desire to: 1. run pcscd as the particular logged-in user or 2. always run pcscd as one *particular* user, which can not log in I believe 2 is what was proposed. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Problem with 2K keys and MyEID
Andre Zepezauer wrote: On Mon, 2010-08-30 at 15:19 +0200, Viktor TARASOV wrote: Aventra development wrote: The 1K key generation works nicely, but we are having a problem generating a 2K key using OpenSC 0.11.13 and our own MyEID card. OpenSC correctly finds a new file id and creates the file, and after that it tries to store the key to that file. The issue is that the created file’s size is only 1024 bytes, so the card will answer with 67 00 (Wrong length). Some code in OpenSC decides to create the wrong sized file, but I have not been able to find it. Now I’m curious that, does other cards work when generating (or just loading) 2048 byte keys? For me, to generate the 2048 bits key on the Aventra card, the following path was needed to be applied to the OpenSC trunk. If no objection, I'll commit this patch to trunk. Hello Viktor, I would write the check for supported modulus length a bit more generic. But it's functional the same like yours, because myeid supports only 1024 and 2048 bit (at least the driver does). Therefore it doesn't matter a lot. #include internal.h pkcs15init/pkcs15-myeid.c:513 /* check that the card supports the requested modulus length */ if (_sc_card_find_rsa_alg(p15card-card, keybits) == NULL) SC_TEST_RET(ctx, LEVEL, ERROR, MSG); Agree, it's much better. I hope that Toni (maintainer of myEID driver) have no objections. On the other hand it would be fine to give a good example, because someone may want to copy+paste your code. See copy+paste in the card drivers [1]. The same check also occurs in line 427, 514, 574, 637. And interestingly _always_ some lines below there is the following conditional assignment: if (file-size 1024) file-size = 1024; Will you prepare the patch? Regards Andre Kind wishes, Viktor. [1]http://www.opensc-project.org/pipermail/opensc-devel/2010-August/014615.html -- 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
[opensc-devel] new anti spam configuration
Hi everyone, we got some spam on our list, send by people using the list address as from: in smtp. I changed our email config to check the smtp sender address properly (valid host etc.) and also blacklisted our mailing lists as from address. I hope that works - reduces spam send to opensc and delivered to you via opensc, and not blocks any other legal mails. but if it does, please send me an email with the mail header / details of the mails rejected, so I can debug and fix the mail system configuration. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Personal Review Of The Upcoming 0.12.0 Release
Le 30 août 2010 14:52, Jean-Michel Pouré - GOOZE jmpo...@gooze.eu a écrit : On Mon, 2010-08-30 at 13:42 +0300, Martin Paljak wrote: Providing official unofficial .deb and .rpm packages would be nice (as said in a previous e-mail). Feel free to work on that. Not sure. The availability of packages is linked to the Debian release schedule. After Debian Squeeze is released, it is possible to ask maintainers to release packages. The Debian packaging files are available from [1] in the general part. The files are stored in a Git repository at git://git.debian.org/git/pkg-opensc/opensc.git Feel free to provide patches for the Debian packaging. For example I think Eric Dorland (actual Debian packager) would be happy to have the files correctly updated to version 0.12.x. I could do that myself but my free time is very limited (or even has a negative value). Bye [1] http://packages.qa.debian.org/o/opensc.html -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Personal Review Of The Upcoming 0.12.0 Release
On Tue, 2010-08-31 at 14:06 +0200, Ludovic Rousseau wrote: The Debian packaging files are available from [1] in the general part. The files are stored in a Git repository at git://git.debian.org/git/pkg-opensc/opensc.git Thanks. Feel free to provide patches for the Debian packaging. For example I think Eric Dorland (actual Debian packager) would be happy to have the files correctly updated to version 0.12.x. I could do that myself but my free time is very limited (or even has a negative value). I will. -- Jean-Michel Pouré - Gooze - http://www.gooze.eu smime.p7s Description: S/MIME cryptographic signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Problem with 2K keys and MyEID
On Tue, 2010-08-31 at 18:40 +0200, Viktor TARASOV wrote: Andre Zepezauer wrote: On Mon, 2010-08-30 at 15:19 +0200, Viktor TARASOV wrote: Aventra development wrote: The 1K key generation works nicely, but we are having a problem generating a 2K key using OpenSC 0.11.13 and our own MyEID card. OpenSC correctly finds a new file id and creates the file, and after that it tries to store the key to that file. The issue is that the created file’s size is only 1024 bytes, so the card will answer with 67 00 (Wrong length). Some code in OpenSC decides to create the wrong sized file, but I have not been able to find it. Now I’m curious that, does other cards work when generating (or just loading) 2048 byte keys? For me, to generate the 2048 bits key on the Aventra card, the following path was needed to be applied to the OpenSC trunk. If no objection, I'll commit this patch to trunk. Hello Viktor, I would write the check for supported modulus length a bit more generic. But it's functional the same like yours, because myeid supports only 1024 and 2048 bit (at least the driver does). Therefore it doesn't matter a lot. #include internal.h pkcs15init/pkcs15-myeid.c:513 /* check that the card supports the requested modulus length */ if (_sc_card_find_rsa_alg(p15card-card, keybits) == NULL) SC_TEST_RET(ctx, LEVEL, ERROR, MSG); Agree, it's much better. I hope that Toni (maintainer of myEID driver) have no objections. On the other hand it would be fine to give a good example, because someone may want to copy+paste your code. See copy+paste in the card drivers [1]. The same check also occurs in line 427, 514, 574, 637. And interestingly _always_ some lines below there is the following conditional assignment: if (file-size 1024) file-size = 1024; Will you prepare the patch? Haven't the required hardware, therefore testing isn't possible to me. But if someone would send me some pieces of these cards, I could do it myself the next time. Regards Andre Kind wishes, Viktor. [1]http://www.opensc-project.org/pipermail/opensc-devel/2010-August/014615.html ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] use algorithm_ref in set_security_env
On Tue, 2010-08-31 at 10:14 +0200, Viktor TARASOV wrote: Andre Zepezauer wrote: On Mon, 2010-08-30 at 17:50 +0200, Viktor TARASOV wrote: Hello, Andre Zepezauer wrote: Hello, attached is a patch which makes it possible to explicitly request specific algorithms for the cryptographic operations. The advantage is, that if the token provides sufficient information about itself, then the driver is not required to do any guess work. Which in turn could result in a more reliable operation of libopensc. Furthermore there could be positive effects in terms of compatibility with tokens not initialised by opensc. My recommendation is to test/improve this patch in an experimental branch or something like that. The reason for this is, that ALG_REF_PRESENT is not in use since revision 177 and I assume a lot of drivers to misbehave or crash at first. Few remarks about your patch. Private key can be used with more than one algorithm. So, IMHO, in the 'sc_pkcs15_prkey_info' it's better to have some array with the references to the crypto algorithms supported by PKCS#15 card (and defined in tokenInfo). Not a good idea, I think. Because the sc_pkcs15_prkey_info structure should also be the input of the prkey-Encoder. Remember that the standard allows only one reference per key. If the encoder gets an array of references, then all references of this array must be dropped except one. Which one? Can you develop, please? Prkey-Encoder? One 'key reference' or 'algorithm reference' per key? Hello Viktor, first of all some clarifications. With prkey-Encoder I mean the function, which takes a sc_pkcs15_prkey_info as it's input and outputs the corresponding asn1 byte array. And all the references I was talking about are 'algorithm references' on prkeys. Improving opensc that way, that it has a greater awareness of the pkcs15 structures on cards is a goal of mine. If this is the development you ask for, then I could do it. A second goal is, to use these cards according to the information found in the pkcs15 structures (on card). In the long term this will hopefully let to a plug and play experience, where a completely new (but still initialised) card will instantly work with opensc. Without any hacks and emulations of course. That's all pkcs15 is about. Isn't it? What's your opinion on that? Regards Andre 1) The scenario you described would also be possible through a direct lookup of TokenInfo.supportedAlogrithms. The algorithms supported by key is not the same as algorithms supported by PKCS#15 card. The first one, in general, is the sub-set of second. 2) Another point to mention is, when using X.509 certificates the algorithm to use is fixed by the certificate. For example: SubjectPublicKeyAlgorithm := PKCS#1 SHA-1 With RSA Encryption Because X.509 is predominating at this time, there is little use for multiple algorithms per key. 3) And there is the CKM_RSA_X_509 algorithm, which allows for every kind of padding and hashing with a single key. It can be the cases when private keys are created (or key slot allocated) before the corresponding certificate is imported and without knowledge about the future usage of these keys. For this reason and for the sake of simplicity, there are can be the keys that are able to accept different algorithms -- 'general purpose' keys. The question is -- should PKCS#15 structure reflect the real key attributes or only the 'useful' ones? Looking at all these facts, I think a single reference per key should work fine in almost every case. It's this 'almost' that I'm a little bit worried about. The same concerns security environment (SE) -- the number of algorithms can be defined in one SE. Haven't worked on this. Regards, Andre Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [Muscle] Re: pcscd access rights limitation and scard group
2010/8/31 Peter Stuge pe...@stuge.se: Johannes Findeisen wrote: I think it is important to pay attention to the original goal: to run pcscd as a normal user instead of root. Yep, that's what I want too. But, when running pcscd as normal user, this normal user need access to the device. Ok, you could make it usable for all users. Then you are right. No need for an extra group. I sense a miscommunication. Is the desire to: 1. run pcscd as the particular logged-in user or 2. always run pcscd as one *particular* user, which can not log in I believe 2 is what was proposed. More precisely pcscd would be run as the user staring it but in the group pcscd using the sgid-bit mechanism. So the smart card reader devices need to be accessible to the group pcscd. I think that using a special group is more flexible than using a special user. I am not sure it is possible to drop the user privileges and become nobody or something similar (without being root). Bye -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [Muscle] Re: pcscd access rights limitation and scard group
On Tue, 2010-08-31 at 21:07 +0200, Ludovic Rousseau wrote: 2010/8/31 Peter Stuge pe...@stuge.se: Johannes Findeisen wrote: I think it is important to pay attention to the original goal: to run pcscd as a normal user instead of root. Yep, that's what I want too. But, when running pcscd as normal user, this normal user need access to the device. Ok, you could make it usable for all users. Then you are right. No need for an extra group. I sense a miscommunication. Is the desire to: 1. run pcscd as the particular logged-in user or 2. always run pcscd as one *particular* user, which can not log in I believe 2 is what was proposed. More precisely pcscd would be run as the user staring it but in the group pcscd using the sgid-bit mechanism. So the smart card reader devices need to be accessible to the group pcscd. Hello Ludovic, in my own opinion, the user starting it would be root in most cases. Or more precisely the init process. Therefore nothing would change with the exception, that ordinary users can start pcscd too. Given the case, that every user would start it's own instance of pcscd (in opposition to a single instance started by init), then problems arises when there are more than one instance. Which reader for which instance of pcscd for example. Or when a new reader is plugged in, who can access it? First come first serve? In this thread I haven't found any information on the problem to solve. But knowing this problem would be of help, when developing the solution. Have I missed something? Regards Andre I think that using a special group is more flexible than using a special user. I am not sure it is possible to drop the user privileges and become nobody or something similar (without being root). Bye ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Initialisation of CardOS
On Tue, 2010-08-31 at 10:35 +0300, Martin Paljak wrote: Hello? On Aug 30, 2010, at 11:13 PM, Andre Zepezauer wrote: Hello all, what do you think of dropping the possibility to initialise CardOS smart cards in 0.11.14? The reason of doing so, is to stop the production of more of these questionable split-key cards. What would be the rationale of doing it? I don't think turning it off is a good idea, but a fat warning (Use a more recent version!) could be used, if justified and needed (why?). If nobody is willing to write a proper pkcs15-emulation for split-key cards, then the support of it is dropped someday. But why should this ever happen? Because the remaining split-key specific code [1] may slow down new developments or prevent some kind of improvements in framework-pkcs15 and other places. Not yet, but for sure. Every change on framework-pkcs15 (maybe in other places too) must take split-keys into account. Therefore developers are forced to work around this strange concept for years. Hopefully not as many years. To disable the initialisation with split-keys now makes sense, because it will prevent the population to grow. In my opinion this is the best what could been done. Also it will prevent people form _accidentally_ initialise with split-keys. *to disable initialisation with split-keys in 0.11.14 may rise the awareness of the new method in 0.12.X *everyone who wants longer support can use 0.12.X for initialisation *everyone who wants to initialise with split-keys can do this with the releases up to 0.11.13 Since there is a better method of initialising CardOS, why not pushing that? [1]http://www.opensc-project.org/pipermail/opensc-devel/2010-June/014390.html People who want to initialise CardOS are then forced to do this with either 0.11.13 or 0.12.X. Hopefully they chose the newer release, because it comes with an improved initialisation for CardOS. No more split-keys here! Cards initialised with 0.12.0 should work with the 0.11.X releases too. Verification of this fact is required of cause. I believe documentation is important here. Due to the nature of smart cards, backwards-compatibility for already personalized cards is greatly desired and a topmost priority. At the same time, personalization happens far less frequently than use, so such restriction could, in theory, make sense as well (requiring newer software for personalization but working with older software in read-only mode) Another fact is that for example Ubuntu 10.04 and Debian Squeeze will stay with the 0.11.X branches for at least the next three years. The same holds for other distributions with a long release cycle (RHEL has seven years of support I think). The imagination that someone could easily produce new split-key cards for the next few years isn't very appealing to me. We can't fix what we can't affect. That is Linux distribution release schedules or decisions done between the chair and the keyboard. We need to make the choices and circumstances clear and well documented though. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] use algorithm_ref in set_security_env
Andre, please try to trim your replies. Keep in mind that you only spend 1 * time trimming, while everyone who has to read spends n * time seraching for your actual reply. Andre Zepezauer wrote: where a completely new (but still initialised) card will instantly work with opensc. Without any hacks and emulations of course. That's all pkcs15 is about. Isn't it? What's your opinion on that? My experience is that no vendors follow p15 so it doesn't matter. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Personal Review Of The Upcoming 0.12.0 Release
Hello,
Martin Paljak wrote:
2. The announcement of the GOST public key algorithm seems to me very
optimistic. Because the current implementation isn't functional at all
[1][2].
Good catch.
The GOST public key algorithm is working (the current implementation),
but in [1] [2] by a lucky chance. We need to fix logic in this case.
See
http://www.opensc-project.org/opensc/browser/trunk/src/libopensc/card-rtecp.c#L60
[1]http://www.opensc-project.org/opensc/browser/trunk/src/libopensc/pkcs15-sec.c#L86
[2]http://www.opensc-project.org/opensc/browser/trunk/src/libopensc/card.c#L725
Trace example:
Breakpoint 1, _sc_card_find_rsa_alg (card=0x8e2530, key_length=256) at
card.c:730
730 for (i = 0; i card-algorithm_count; i++) {
(gdb) bt
#0 _sc_card_find_rsa_alg (card=0x8e2530, key_length=256) at card.c:730
#1 0x7fce3a329369 in sc_pkcs15_compute_signature (p15card=0x8e2b00,
obj=0x8eaff0,
flags=value optimized out, in=value optimized out, inlen=32,
out=value optimized out, outlen=64)
at pkcs15-sec.c:175
#2 0x0041118d in pkcs15_prkey_sign (ses=0x8ee2c0, obj=value
optimized out,
pMechanism=value optimized out, pData=value optimized out,
ulDataLen=32,
pSignature=value optimized out, pulDataLen=0x7128e8) at
framework-pkcs15.c:2401
#3 0x0040ca98 in sc_pkcs11_signature_final (operation=0x8ee230,
pSignature=0x712860 ,
pulSignatureLen=0x7128e8) at mechanism.c:425
#4 0x0040d546 in sc_pkcs11_sign_final (session=0x8ee2c0,
pSignature=0x712860 ,
pulSignatureLen=0x7128e8) at mechanism.c:307
#5 0x0040a82c in C_Sign (hSession=9364160, pData=0x708de0
1234567890123456789012345678901,
ulDataLen=32, pSignature=0x712860 , pulSignatureLen=0x7128e8) at
pkcs11-object.c:591
#6 0x004079b5 in main ()
(gdb) finish
Run till exit from #0 _sc_card_find_rsa_alg (card=0x8e2530,
key_length=256) at card.c:730
sc_pkcs15_compute_signature (p15card=0x8e2b00, obj=0x8eaff0,
flags=value optimized out,
in=value optimized out, inlen=32, out=value optimized out,
outlen=64) at pkcs15-sec.c:176
176 if (alg_info == NULL) {
Value returned is $1 = (sc_algorithm_info_t *) 0x8e27c0
(gdb) p/x *$1
$3 = {algorithm = 0x0, key_length = 0x100, flags = 0x8011, u = {_rsa
= {exponent = 0x0}}}
(gdb) n
175 alg_info = _sc_card_find_rsa_alg(p15card-card,
prkey-modulus_length);
(gdb)
176 if (alg_info == NULL) {
(gdb)
160 size_t modlen = prkey-modulus_length / 8;
(gdb)
183 if (inlen sizeof(buf) || outlen modlen)
(gdb)
185 memcpy(buf, in, inlen);
(gdb)
180 senv.algorithm = SC_ALGORITHM_RSA;
(gdb)
185 memcpy(buf, in, inlen);
(gdb)
195 if ((alg_info-flags SC_ALGORITHM_NEED_USAGE)
(gdb)
223 if ((flags == (SC_ALGORITHM_RSA_PAD_PKCS1 |
SC_ALGORITHM_RSA_HASH_NONE))
(gdb)
237 r = sc_get_encoding_flags(ctx, flags, alg_info-flags,
pad_flags, sec_flags);
(gdb)
238 if (r != SC_SUCCESS) {
(gdb)
245 if (pad_flags != 0) {
(gdb)
242 senv.algorithm_flags = sec_flags;
(gdb)
245 if (pad_flags != 0) {
(gdb)
242 senv.algorithm_flags = sec_flags;
(gdb)
245 if (pad_flags != 0) {
(gdb)
250 } else if ((flags SC_ALGORITHM_RSA_PADS) ==
SC_ALGORITHM_RSA_PAD_NONE) {
(gdb)
252 if (inlen modlen) {
(gdb)
260 senv.operation = SC_SEC_OPERATION_SIGN;
(gdb)
261 senv.flags = 0;
(gdb)
263 if (prkey-key_reference = 0) {
(gdb)
264 senv.key_ref_len = 1;
(gdb)
265 senv.key_ref[0] = prkey-key_reference 0xFF;
(gdb)
266 senv.flags |= SC_SEC_ENV_KEY_REF_PRESENT;
(gdb)
268 senv.flags |= SC_SEC_ENV_ALG_PRESENT;
(gdb)
270 r = sc_lock(p15card-card);
(gdb)
271 SC_TEST_RET(ctx, SC_LOG_DEBUG_NORMAL, r, sc_lock()
failed);
(gdb)
270 r = sc_lock(p15card-card);
(gdb)
271 SC_TEST_RET(ctx, SC_LOG_DEBUG_NORMAL, r, sc_lock()
failed);
(gdb)
273 if (prkey-path.len != 0) {
(gdb)
274 r = select_key_file(p15card, prkey, senv);
(gdb)
275 if (r 0) {
(gdb)
274 r = select_key_file(p15card, prkey, senv);
(gdb)
275 if (r 0) {
(gdb)
281 r = sc_set_security_env(p15card-card, senv, 0);
(gdb)
282 if (r 0) {
(gdb)
281 r = sc_set_security_env(p15card-card, senv, 0);
(gdb)
282 if (r 0) {
(gdb)
287 r = sc_compute_signature(p15card-card, tmp, inlen, out,
outlen);
(gdb) s
sc_compute_signature (card=0x8e2530, data=0x7fff14921100
1234567890123456789012345678901, datalen=32,
out=0x712860 , outlen=64) at sec.c:48
48 {
(gdb) n
51
Re: [opensc-devel] use algorithm_ref in set_security_env
On Wed, 2010-09-01 at 00:52 +0200, Peter Stuge wrote: Andre, please try to trim your replies. Keep in mind that you only spend 1 * time trimming, while everyone who has to read spends n * time seraching for your actual reply. Andre Zepezauer wrote: where a completely new (but still initialised) card will instantly work with opensc. Without any hacks and emulations of course. That's all pkcs15 is about. Isn't it? What's your opinion on that? My experience is that no vendors follow p15 so it doesn't matter. It's not that easy. Because the big companies doesn't make there money through selling smart cards. They make there business through selling per host licenses. These licences are required to legally use there proprietary host side middle ware. Which in turn is required to access the cards personalised by the same proprietary software. I'm not an expert on that, but I assume that most of the proprietary middle ware only supports the cards of a single vendor. The result would be a vendor login. And of cause, there is little interest by these companies to change that. On the other hand, it's hard for small or new companies to come to market, because they have to develop there own host side middle ware. And they have to support it on different platforms with a multitude of different versions of the same OS. If done right, they can gain profit form vendor login too. Interestingly most of the current cards can support pkcs15 right now. It's only a matter of personalisation. That means, you only have to write the right data structures to the cards file system. And you need the host side software, which cares about these structures. That's it. BTW it's not a card vendor who doesn't follow pkcs15, it's the software used for personalisation. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] use algorithm_ref in set_security_env
Andre Zepezauer wrote: where a completely new (but still initialised) card will instantly work with opensc. Without any hacks and emulations of course. .. It's not that easy. Yes exactly. ;) //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
