Re: [opensc-devel] OpenSC Wiki in github
Hi Viktor, great job. I just looked through our page for the SmartCard-HSM and found only small issues. What do we want to do about the automatic list generation that is not working on GITHUB (e.g. SupportedHardware) ? Do we copy the list as is from the old wiki ? Andreas Am 11.12.2012 16:17, schrieb Viktor Tarasov: Hello, for a while we have no news about migration of tracwiki to the dedicated platform. Meanwhile, waiting for better solution, I migrated OpenSC wiki to github [1] . (Only wiki pages, not tickets.) The OpenSC Wiki pages in github are converted into 'textile' format. The rapid script used for this conversion, the archives with the dump of the OpenSC sub-project wiki pages and wiki attachments are also present in wiki repository. (Files are not accessible with GUI -- you need to clone repository. [2]) Using these files and archives the Wiki of the other OpenSC sub-projects can be also migrated to github. I do not yet looked 'manually' through all the wiki pages to update existing, suppress obsolete or add new information. I will do it gradually and invite you as well to participate in this exciting activity, if you have will, possibility, time, etc... If you notice any 'systematic' conversion error, tell me please, I will change the conversion script and re-submit the pages . Kind regards, Viktor. [1] https://github.com/OpenSC/OpenSC/wiki [2] git clone g...@github.com:OpenSC/OpenSC.wiki.git ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 571 56149 -http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC 0.13.0
A big Thank you to everyone contributing to this release. It's a great piece of work. Andreas Am 04.12.2012 22:13, schrieb Viktor Tarasov: Hello, The next release is tagged on the github OpenSC/OpenSC project, thanks to all of you for your contributions. Tarball and MSI installers can be found on github, sourceforge or the CI server: https://github.com/OpenSC/OpenSC/tags https://sourceforge.net/projects/opensc/files/OpenSC/ https://opensc.fr/jenkins/ The packages for the other OSs will be added. The list, not complete, of the new features: * New card driver ePass2003. * OpenPGP card: greatly improved card driver and PKCS#15 emulation; implemented write (pkcs15init) mode; greatly enhanced documentation and tools. * ECDSA keys supported in 'read' and 'write' modes by internal PKCS#15 library, PKCS#11 and tools. * Minidriver in 'write' mode. * SM: secure messaging in GlobalPlatform-SP01 and CW14890 specifications; supported by ePass2003, IAS/ECC and AuthentIC cards; ACL and APDU modes to trigger secure messaging session; 'local' version of the external secure messaging module. * PKCS#15: support of 'secret-key' PKCS#15 objects support of 'authentication-object' PKCS#15 objects support of 'algReference' common key PKCS#15 attribute support of 'algReference' common key PKCS#15 attribute support of 'subjectName' common public key PKCS#15 attribute * PKCS#11: removed 'onepin' version of pkcs#11 module configuration options to expose slots for PINs and present on-card applications. support GOSTR3410 generate key mechanism support of EC key type * Support of PACE reader. * Remove libltdl reference. * ECDSA supported by MyEID card. * New card driver for the SmartCard-HSM, a light-weight hardware security module. * New useful commands in 'opensc-explorer' tool: 'find', 'put-data', ... * fixes SIGV issue related to the unsupported public key format * fixes for the number of documentation issues This release was pushed ahead by the number of new features and new card drivers eager for their place in the project, as well as by the necessity to restore the regular release process. You are heartily invited to comment/test/use this release. Also at this time we are migrating the OpenSC project to the new hosting. Currently: - the sources of OpenSC sources and its sub-projects are migrated to github (thanks to Ludovic); - mailing-list on sourceforge is ready to substitute the mailing-list on opensc-project.org (once more thanks to Ludovic); - Peter Stuge have to migrate the OpenSC trac wiki onto one of his platform ; - sourceforge will replace the file server hosted by opensc-project.org (currently the CI service sends the release and 'nightly' packages to both sourceforge and opensc-project); - CI service is currently running for OpenSC/OpenSC github project, but can be extended and include the other OpenSC sub-projects. Currently the github OpenSC/OpenSC contains two branches 'master' and 'staging', rigorously synchronized between each other. I guess that we can eliminate the 'staging' branch and use only the 'master' one. The OpenSC wiki pages are largely outdated; but I think it's reasonable to wait Peter to finish migration of existing trac before starting to update it. Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 571 56149 -http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] SmartCard-HSM Tool with key wrap / unwrap
Hi Martin, cards and USB-sticks can be purchased at http://www.cardomatic.de/. The product does not yet show up in the online shop, but you can contact Karsten Niehusen directly (cc-ed above) for sales inquiries. Andreas Am 22.11.2012 12:29, schrieb Martin Paljak: Hello Andreas, Is the applet available for download or cards with pre-loaded applet on sale somewhere? Martin On Fri, Nov 9, 2012 at 7:33 PM, Andreas Schwier andreas.schw...@cardcontact.de wrote: Good evening, we've created a pull request towards OpenSC/staging for adding the SmartCard-HSM tool (sc-hsm-tool). Using version 0.17 or higher, the SmartCard-HSM provides for a key wrap / unwrap mechanism that allows to securely export and import card generated keys. Key values are encrypted under a 256-bit AES Device Key Encryption Key (DKEK) and saved to file with key description and optional certificate. From such a file, the key can be recreated in a SmartCard-HSM that has been set-up with the same DKEK. Using this mechanism, one can securely backup keys or migrate keys between different SmartCard-HSMs. This increases the capacity of the device, as infrequently used keys can be exported and archived externally. It also provides for redundancy and load balancing if keys are replicated in a cluster of SmartCard-HSMs. The DKEK can be recreated from a defined number of key shares. Such key shares are created with sc-hsm-tool and saved to file using password based encryption. Kind regards, Andreas -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 571 56149 -http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 571 56149 -http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] state of the project?
It's probably a good occasion to clean-up the list. We should define a date at which we switch to the new list and send a final termination notice with pointers to the new list. After that notice we should reject any further e-mails to the list and keep the archive around a little longer. Andreas Am 21.11.2012 17:59, schrieb Ludovic Rousseau: 2012/11/18 Ludovic Rousseau ludovic.rouss...@gmail.com: 2012/11/18 Viktor Tarasov viktor.tara...@gmail.com: mailing list will go (without archive ?) to SourceForge, or, in case of the last minute obstacles, to groups.google.com. The numbers of members to the 3 lists hosted at opensc-project.org are: 546 opensc-devel_members.txt 129 opensc-announce_members.txt 39 opensc-commits_members.txt I created 3 mailing lists at SourceForge OpenSC project https://sourceforge.net/p/opensc/mailman/ It looks like it is possible to mass subscribe to a mailman list [1]. But I could not find how using the SourceForge list interface. I found how to mass subscribe to the new mailing lists I created. Maybe the only (and good) solution is to ask people to subscribe at SourceForge. What do you think is best: - mass subscription without asking for permission? - ask people to subscribe to the new lists? Maybe some people are on the list but no more interested by OpenSC. Maybe they just redirect the emails into the spam/trash folder. What do you think? Thanks -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 571 56149 -http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] state of the project?
Hi Ludovic, can you grant me (git-account is CardContact) write access to OpenSC-Java ? Andreas Am 14.11.2012 23:45, schrieb Ludovic Rousseau: 2012/11/14 Andreas Schwier andreas.schw...@cardcontact.de mailto:andreas.schw...@cardcontact.de We are still maintaining a version of OpenSC-Java. If you migrate the repo to GITHUB I will care for it. Now available at https://github.com/OpenSC/OpenSC-Java I pushed 3 branches: - master - pkcs11-0.2-branch - pkcs11-test-0.2-branch The latest commit in master is 4 years old. Bye -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 571 56149 -http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] state of the project?
We are still maintaining a version of OpenSC-Java. If you migrate the repo to GITHUB I will care for it. Andreas Am 14.11.2012 21:20, schrieb Ludovic Rousseau: 2012/11/14 Ludovic Rousseau ludovic.rouss...@gmail.com mailto:ludovic.rouss...@gmail.com I could not migrate: - pkcs11-help. Something fails in the authors names conversion I forked the github repository of Alon. pkcs11-helper is now available under the OpenSC organization. https://github.com/OpenSC/pkcs11-helper I have not tried to migrate: - OpenCT - OpenSC-Java Aren't these projects obsolete now? I tried to convert OpenCT. But I could not get the author correspondence. Some SVN revisions have no author and confuse svn2git. Bye -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 571 56149 -http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] New SE (Security Element) Company Formed
Does the API matter anyway ? No, it's the functionality the TEE provides: Generate, store, maintain and use cryptographic material and do all kinds of risk management. And these functions do not really require web service and overloaded APIs. They require APIs that are consistent, simple to implement and simple to be security evaluated. An ISO 7816-4 API is not an elegant API, but is has been around for a long time, people understand it and it does what it is supposed to do. I would love to see a CC certified TEE that has an embedded JavaCard VM with lots of memory and sufficient processing power. Andreas Am 15.11.2012 00:13, schrieb Peter Stuge: Anders Rundgren wrote: http://www.theregister.co.uk/2012/11/13/trustzone_company Smart cards? Don't think so. TrustZone isn't half bad hardware. But I bet that the solution they come up with will still use exactly the same old APDUs, with just a minimum bolted-on, in order to make something that just barely works. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 571 56149 -http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] PublicKey ASN1 decoding
Dear Viktor, that's fine with me. What I've still on my list is to fix the EC Public Key encoding. The current encoding (basically just the EC point) does not allow to carry domain parameter, so I would like to change that to the SubjectPublicKeyInfo Format. What I'm not sure about is whether the encoding format for other key types (RSA,DSA,GOST etc) should change to SPKI as well. Do you have an overview which cards store the public key encoded with sc_pkcs15_encode_pubkey ? Andreas Am 13.11.2012 10:10, schrieb Viktor Tarasov: Hello, it seems that the reason of recent segmentation faults related to the uninitialized public key components (t451, t455) is here: https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/pkcs15-pubkey.c#L373 /* this publicKeyCoefficients should be required, not optional. But it is missing in some siemens cards and thus causes warnings */ /* so we silence these warnings by making it optional - the card works ok without. :/ */ 'Optional' means that if the encoding of the public key do not conform PKCS#1 (as expected by OpenSC) the ASN1 decoding procedure silently returns the publicKey data with uninitialized components. The checking of input parameters in OpenSC is not always present/perfect and this provokes segmentation fault in the modules that use the 'read-public-key' procedure (tools, pkcs#11). As for me, the common library part has to be free of the card specific issues -- all card specific issues has to be implemented in card drivers. For that reason, recently was introduced new card operation 'read-public-key'. For a while this handler is designed to read out the 'native' public key (stored in SDOs), but it can be extended to allow the read out of the non-PKCS#1 content of the public key EFs . If no objections, I will turn off 'optional' flag for the 'publicKeyCoefficients' and will extend the argument list of 'read-public-key' handler. Then 'someone' who interested in support of the proprietary formats in OpenSC will implement the corresponding parsing procedure in card driver. Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 571 56149 -http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] obtaining a CSR for a token-generated (and locked-on-token) keypair
Hi Anthony, I've tried myself to get it working with openssl and engine-pkcs11. Apparently engine-pkcs11 only implements functions to read certificates and use keys for signing. There is no support to generate keys via openssl using the -newkey option. Because of that, you can not - within the same session - generate a key pair and sign the CSR with that private key. If the key already has a certificate, then it works because opensc extracts the public key object from the certificate. There are two options to fix this: a) Add support for key generation to engine-pkcs11 or b) Store newly generated public keys in the SmartCard-HSM between sessions Option a) seems difficult to me, as I don't know the openssl code well enough. Option b) scarifies a security principle of the SmartCard-HSM: No untrusted information path. Providing the plain public key in a (untrusted) PKCS#11 session is already a trade-off, but maybe we also need a way to make the unprotected public key available between sessions. In the meantime I would suggest to use XCA or the simple CA setup from the support scripts (demo/x509/issuecert.js). Andreas Am 11.11.2012 23:50, schrieb Anthony Foiani: Nikos -- Thanks for the quick reply! On Sun, Nov 11, 2012 at 12:42 PM, Nikos Mavrogiannopoulos n.mavrogiannopou...@gmail.com wrote: Your question was on openssl, Apologies if it was off-topic; it got to the point where I couldn't tell which component was complaining. Also, my initial goal is to use the token to authenticate data from an embedded instrument; as such, I figured that was more in the opensc world than openssl. (Eventually I'd like to use the token to provide that instrument with a server-side HTTPS certificate as well, which would of course get me back to openssl or similar tool. But that's further down the path.) but just in case someone is interested. If you have any recent version of gnutls you could simply do that by using the PKCS #11 URLs of the objects. That is: certtool --generate-request --outfile req.pem --load-privkey pkcs11:yyy --load-pubkey pkcs11:xxx should generate a request from the objects based on a smart card. The pkcs11: URLs are obtained using the p11tool --list-all --login command. Nice -- thank you for the pointer! Unfortunately, I don't think this can work with a keypair generated on the CC-HSM. First, the public key is only available during the same session that generates the pair; it disappears after the session disappears. One can capture the public key at generation time using the instructions provided by CardContact here: http://www.opensc-project.org/opensc/wiki/SmartCardHsm#Generatekeypair This does work, but it leaves me with a public key in SPKI format, and I'm too ignorant to figure out how to turn that into something that OpenSSL can work with. Second, the private key is not extractable, so the certtool won't be able to load it from the card. (Unless --load-privkey actually means use this privkey, but it's really just a reference to doing it on the token itself.) So far as I know, what I would really like the openssl req tool to do is: 1. Read the public key from a given file on the regular OS filesystem [somehow dealing with the SPKI-whatever format issue]; 2. Prompt me for the X.509 request parameters; 3. Construct the X.509 certificate request; 4. Sign that request on the CC-HSM token using the private key on the card; 5. Output the signed CSR onto the regular OS filesystem. But I have not yet figured out the correct incantation for that. Best regards, Anthony Foiani ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 571 56149 -http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] obtaining a CSR for a token-generated (and locked-on-token) keypair
Dear Anthony, I've created a patch [1] that adds storing the internally generated certificate signing request in place of the certificate. This makes the public key available in subsequent sessions until the certificate overwrites the CSR. I've tried it with engine-pkcs11 and got a signed PKCS#10 request. Please let me know if it works for you. Andreas [1] https://github.com/CardContact/OpenSC/commit/9dec8c35c71b94742bc75c08f33b91616bb4c9cb Am 12.11.2012 07:54, schrieb Anthony Foiani: Andreas -- On Sun, Nov 11, 2012 at 6:31 AM, Andreas Schwier andreas.schw...@cardcontact.de wrote: The suggested way in the meantime is to generate the key pair, extract the public key and generate a CSR externally, signing it with the private key on the device. I haven't tried that precise sequence yet -- I tried it with openssl and it complained, I still need to try it with certtool as described by Nikos. I did try creating the keypair and certificate in software, then installing the resulting bits onto the token. I managed to install the certificate (which also provides the public key): $ echo $tool /usr/local/bin/pkcs11-tool --module /usr/local/lib/opensc-pkcs11.so --login --pin 648219 $ LD_LIBRARY_PATH=/usr/local/lib $tool -O Using slot 1 with a present token (0x1) Certificate Object, type = X.509 cert label: Foo ID: 10 Public Key Object; RSA 2048 bits label: Foo ID: 10 Usage: encrypt, verify Although the public key does not have the wrap usage flag set; compare with a keypair generated on the token: $ LD_LIBRARY_PATH=/usr/local/lib $tool \ --keypairgen --key-type rsa:2048 --id 11 \ --read-object --id 11 --type pubkey --output-file foobar.pub Using slot 1 with a present token (0x1) Key pair generated: Private Key Object; RSA label: Private Key ID: 11 Usage: decrypt, sign, unwrap Public Key Object; RSA 2048 bits label: Private Key ID: 11 Usage: encrypt, verify, wrap However, the bigger problem came when I tried to install the private key: $ LD_LIBRARY_PATH=/usr/local/lib $tool --write-object foo2a.key.der --id 11 --type privkey --label Foo Using slot 1 with a present token (0x1) error: PKCS11 function C_CreateObject failed: rv = CKR_ATTRIBUTE_VALUE_INVALID (0x13) Aborting. Turning on debugging (after making trivial repairs to the debug output code), it seems that these are the attributes that are getting stuffed: CKA_CLASS = CKO_PRIVATE_KEY CKA_TOKEN = TRUE CKA_PRIVATE = TRUE CKA_SENSITIVE = TRUE CKA_LABEL = Foo CKA_ID = 10 CKA_KEY_TYPE = 0x7fff6d1c1175 CKA_MODULUS = C770D5... CKA_PUBLIC_EXPONENT = 010001 CKA_PRIVATE_EXPONENT = 97F798... CKA_PRIME_1 = EFE5AD... CKA_PRIME_2 = D4D3F6... CKA_EXPONENT_1 = 5815FD... CKA_EXPONENT_2 = 2DD24D... CKA_COEFFICIENT = 62BD2B... Looking for similar instances on the web, the recommendation seems to be: hack pkcs11-tool to remove individual attributes until you find which one the token is complaining about. With your visibility into the software on the token, I'm hoping that you can help us avoid that kind of trial and error. :) Thanks very much for your help so far, and we're looking forward to hearing the results of your tests with openssl. Best regards, Anthony Foiani -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 571 56149 -http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] obtaining a CSR for a token-generated (and locked-on-token) keypair
very clearly through the options (if at all). For the moment, I guess I'll just generate keys, CSRs, and certs in software, and use the HSM just for storage. I would love to figure out what I'm doing wrong, though. Best regards, Anthony Foiani -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 571 56149 -http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] obtaining a CSR for a token-generated (and locked-on-token) keypair
Dear Anthony, you can not import an externally generated private key. For security reasons, the SmartCard-HSM only supports keys generated internally. We've tested with XCA which uses OpenSSL and the engine mechanism, so I'm quite confident it should work with the command line as well. Let me come back after I tried it. Andreas Am 12.11.2012 07:54, schrieb Anthony Foiani: Andreas -- On Sun, Nov 11, 2012 at 6:31 AM, Andreas Schwier andreas.schw...@cardcontact.de wrote: The suggested way in the meantime is to generate the key pair, extract the public key and generate a CSR externally, signing it with the private key on the device. I haven't tried that precise sequence yet -- I tried it with openssl and it complained, I still need to try it with certtool as described by Nikos. I did try creating the keypair and certificate in software, then installing the resulting bits onto the token. I managed to install the certificate (which also provides the public key): $ echo $tool /usr/local/bin/pkcs11-tool --module /usr/local/lib/opensc-pkcs11.so --login --pin 648219 $ LD_LIBRARY_PATH=/usr/local/lib $tool -O Using slot 1 with a present token (0x1) Certificate Object, type = X.509 cert label: Foo ID: 10 Public Key Object; RSA 2048 bits label: Foo ID: 10 Usage: encrypt, verify Although the public key does not have the wrap usage flag set; compare with a keypair generated on the token: $ LD_LIBRARY_PATH=/usr/local/lib $tool \ --keypairgen --key-type rsa:2048 --id 11 \ --read-object --id 11 --type pubkey --output-file foobar.pub Using slot 1 with a present token (0x1) Key pair generated: Private Key Object; RSA label: Private Key ID: 11 Usage: decrypt, sign, unwrap Public Key Object; RSA 2048 bits label: Private Key ID: 11 Usage: encrypt, verify, wrap However, the bigger problem came when I tried to install the private key: $ LD_LIBRARY_PATH=/usr/local/lib $tool --write-object foo2a.key.der --id 11 --type privkey --label Foo Using slot 1 with a present token (0x1) error: PKCS11 function C_CreateObject failed: rv = CKR_ATTRIBUTE_VALUE_INVALID (0x13) Aborting. Turning on debugging (after making trivial repairs to the debug output code), it seems that these are the attributes that are getting stuffed: CKA_CLASS = CKO_PRIVATE_KEY CKA_TOKEN = TRUE CKA_PRIVATE = TRUE CKA_SENSITIVE = TRUE CKA_LABEL = Foo CKA_ID = 10 CKA_KEY_TYPE = 0x7fff6d1c1175 CKA_MODULUS = C770D5... CKA_PUBLIC_EXPONENT = 010001 CKA_PRIVATE_EXPONENT = 97F798... CKA_PRIME_1 = EFE5AD... CKA_PRIME_2 = D4D3F6... CKA_EXPONENT_1 = 5815FD... CKA_EXPONENT_2 = 2DD24D... CKA_COEFFICIENT = 62BD2B... Looking for similar instances on the web, the recommendation seems to be: hack pkcs11-tool to remove individual attributes until you find which one the token is complaining about. With your visibility into the software on the token, I'm hoping that you can help us avoid that kind of trial and error. :) Thanks very much for your help so far, and we're looking forward to hearing the results of your tests with openssl. Best regards, Anthony Foiani -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 571 56149 -http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] two trivial patches for opensc
Suggested way is to open a pull request toward OpenSC/staging. Our repo is pretty much in sync with the OpenSC repo, but OpenSC has the master. Am 12.11.2012 07:15, schrieb Anthony Foiani: Greetings. I cloned CardContact's repo, since I'm working with their hardware, but it looks like these issues are present in the upstream source as well. https://github.com/tkil/OpenSC/commit/563e264483338ea8eef01b5e5549647916308f3f https://github.com/tkil/OpenSC/commit/4d5993066b4473249682b1bcf0e718373e85b267 Should I make pull requests against CardContact's repo, or just post patches here, or? Thanks, Tony ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 571 56149 -http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] SmartCard-HSM Tool with key wrap / unwrap
Good evening, we've created a pull request towards OpenSC/staging for adding the SmartCard-HSM tool (sc-hsm-tool). Using version 0.17 or higher, the SmartCard-HSM provides for a key wrap / unwrap mechanism that allows to securely export and import card generated keys. Key values are encrypted under a 256-bit AES Device Key Encryption Key (DKEK) and saved to file with key description and optional certificate. From such a file, the key can be recreated in a SmartCard-HSM that has been set-up with the same DKEK. Using this mechanism, one can securely backup keys or migrate keys between different SmartCard-HSMs. This increases the capacity of the device, as infrequently used keys can be exported and archived externally. It also provides for redundancy and load balancing if keys are replicated in a cluster of SmartCard-HSMs. The DKEK can be recreated from a defined number of key shares. Such key shares are created with sc-hsm-tool and saved to file using password based encryption. Kind regards, Andreas -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 571 56149 -http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Progress on Starcos 3.2 cards?
Hi Michael, the Starcos 3.2 specifications are only available under NDA and thus it will be fairly difficult to provide an open source implementation for the driver. Kind regards, Andreas Am 30.10.2012 09:37, schrieb Michael Below: Hi, I would like to use a Starcos 3.2 card with pcscd (this one: http://www.deutschepost.de/dpag?tab=1skin=hicheck=yeslang=de_DExmlFile=link1015459_49595). There is a promising feature request with a partial solution (#373), but the following discussion in the bug tracker seems to focus on general issues of PIN caching. This kind of card is widely used in Germany, I think it would be a good thing to add it to pcscd. I'd be happy to help testing. Cheers Michael ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 571 56149 -http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] adding support for a java applet
Dear Aidin, for writing a card driver I would suggest to pick one of the existing drivers and adapt to your specific needs. It's a little bit of work, but it can be done. It's probably best to start with the integration into opensc-explorer. Once you get that to work, take the next step and develop a read/only driver using a card specific pkcs15 module in libopensc. The final step would be to provide a pkcs15 module in pkcs15init for write support. Expect a lot of debugging, so select a comfortable development environment (we use Eclipse for C/C++ for it). Andreas Am 22.10.2012 08:48, schrieb aidin boghaniyan: Hello again, Do anybody have any idea? Thanks in advance On Tue, Oct 16, 2012 at 9:54 AM, aidin boghaniyan aidinb...@gmail.com mailto:aidinb...@gmail.com wrote: Hi, I have some kona25 http://www.tagsystems.net/downloads java card, and I must provide a pkcs11 interface for them. I know that the best way for using them with OpenSC is loading Muscle applet on it, but I was unsuccessful on this solution. Indeed, I have loaded muscle applet using gpj http://sourceforge.net/projects/gpj/ (java global platform), and I add my card ATR to the list of Muscle card supported ATRs, but when I use this card with OpenSC, I got the unsupported card error, and when I debug code, I detect the problems is from muscle_match_card function. This function doesn't receive what it expects form card, so the card will be unsupported. I tried to load another cap file of the Muscle applet, but there was no change. Does anybody had any advise? Another solution for me is using Java Card Sign http://sourceforge.net/projects/javacardsign/ applet, and writing a PKCS11 driver for this card. I have loaded this applet on my card and communicate successfully with this applet from host application of it. This applet and it's host application are open source. So my main question is that, Is this solution the best solution that I can choose? Regards ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 571 56149 -http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Support for C_InitializeToken and C_InitPIN
Dear all, we've created a pull request towards OpenSC/staging in order to implement support for PKCS#11 like token initialization and PIN management [1]. This patch shall allow a token to perform a one-step initialization rather than deleting the individual PKCS#15 objects from the card. The patch is in particular useful for cards using the PKCS#15 emulation layer. The patch also adds the ability to pass hardware and firmware information from the PKCS#15 level into the PKCS#11 level. C_InitializeToken and C_InitPIN are used by some PKCS#11 aware application (like XCA) to perform a complete re-initialization of the token, removing all keys and resetting the SO and user PIN. Please review and comment on github. Kind regards, Andreas [1] https://github.com/OpenSC/OpenSC/pull/96 -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 571 56149 -http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] new server hoster and adminstrator for opensc-project.org required
Hi, did anyone try the issue tracking and wiki functions on github ? Seems that it provides the same functionality as trac. Migrating the data might be a pain, but also gives the opportunity to clean things up. I would prefer a solution where everything is nicely integrated. Other than that, I agree with Viktor to use the existing CI service and move the other parts there. Andreas Am 03.10.2012 09:43, schrieb Viktor Tarasov: Hello Andreas, On Tue, Oct 2, 2012 at 11:13 PM, Andreas Jellinghaus andr...@ionisiert.de mailto:andr...@ionisiert.de wrote: So, have you agreed on something? I read different opinions, offers, comments, but nothing that points out coming to some consent. What is your preference? Since I'm not really active, I don't want to decide this. I checked googlegroups and code.google.com http://code.google.com, worst case I can figure out how to copy/move things there. I will look into code.google.com http://code.google.com, but beside this, one of the solution could be to : - move the sources of the projects to github; - use my CI service for nightly builds; - install on the same platform file server for release tarbals, RPMs, MSIs, etc; - move onto the same platform wiki, trac and mailing lists. If there will not be other suggestions, and if the study of the googlegroups or similar will not bring other solution, we could start the migration. Regards, Andreas Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org mailto: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 -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 571 56149 -http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] W3C takes on Web+SecurityElements
So why do you think the smart card industry has never managed to get their stuff web compatible ? Isn't OpenSC the best example that Yes, you can access a protected website / webapplication / webservice using a smart card and standard based technology works ? The issue really is, that the topic at hand (PKI) is way to complex for the average Doe to manage. That's always the downside: Security often means complexity and comes with a price tag. And if it is complex, hard to understand and someone offers some cheaper snake-oil, I probably go for that. Rather than exposing the complexity of the matter with a zoo of options you can choose from, we need to focus on a single generic mechanism and a well designed user experience. It's all there (meaning S/MIME and TLS), it just needs to become a little simpler to manage. So rather than re-inventing the n-solution for Web-ID, SSO or One-Time-Passwords, we - as a community - should improve what is already existing. Andreas Am 03.10.2012 11:09, schrieb Anders Rundgren: http://www.w3.org/2012/09/sysapps-wg-charter http://www.linkedin.com/redirect?url=http%3A%2F%2Fwww%2Ew3%2Eorg%2F2012%2F09%2Fsysapps-wg-charterurlhash=Tqzg_t=tracking_disc Since the smart card industry have never managed making their stuff web compatible before, I assume they will fail this time as well. Anders ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 571 56149 -http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] W3C takes on Web+SecurityElements
Hi Anders, fine, just another API to access smart cards, token or secure elements - this time using APDUs from within JavaScript. Why not ? I just don't see the application for it. What problem are they going to solve ? Would I trust some foreign JavaScript code in my browser to freely access my smart card ? The only real justification left for smart cards, token or secure elements is to manage cryptographic keys and to perform operations that require some kind of trusted execution environment (e.g. card based risk management in EMV, totalling VAT in a fiscal meter). Storing plain data on smart cards is a left-over from the early off-line days and is pretty much useless in an always on-line world. Given that, there are two problems to solve: a) Allow applications (on the desktop, on the web or as app) to access keys on the smart card, token and secure element. b) Manage (create, certify, import, export and delete) keys on the smart card, token and secure element. a) is pretty well solved using standards like PKCS#11, CSP Minidriver or JCE. However, controlling access to the keys needs to be carefully managed (using PIN-PAD readers or educating users to don't leave the key in the lock). b) is a little more tricky, as it requires a certain level of trust in the device where keys are to be stored. This trust level can be either based on the central model I - the CA - purchase the device and put the keys into it or the de-centralized model I trust the manufacturer or issuer of the device to create a genuine device. The central model is pretty much what PKI operators are doing today: They purchase a device and - in a trusted environment - put keys and certificates into it. The de-centralized model is little more complicated, as the issuer might be a national authority, a mobile network operator, a mobile device manufacturer, a bank or a private operation. Quite often these issuers have no interest to allow others to issue certificates for keys on the device they had to paid for - or they just don't see the benefit of the next big think. Here comes the user centric model: Let the user decide where to store the keys and allow the CA to determine how trustful that device is: Might be a software token, a hardware token or a hardware token with a trusted provisioning mechanism. If the CA knows, that the keys are stored on a genuine device and asserts that a validated identity is linked to that key, then we don't need any further identity management scheme. I pretty much like the StartSSL approach: Once you've proved your identity by submitting copies of two id documents, paying a fee and answering a phone call, they will issue certificates for things you own like domains and e-mail addresses. The next level could be keys you own, that can not be duplicated and only stolen physically. I guess the trusted provisioning mechanism is what we need to work on (and already do as far as we are concerned). Andreas Am 03.10.2012 13:23, schrieb Anders Rundgren: On 2012-10-03 12:08, Andreas Schwier (ML) wrote: So why do you think the smart card industry has never managed to get their stuff web compatible ? Isn't OpenSC the best example that Yes, you can access a protected website / webapplication / webservice using a smart card and standard based technology works ? The issue really is, that the topic at hand (PKI) is way to complex for the average Doe to manage. That's always the downside: Security often means complexity and comes with a price tag. And if it is complex, hard to understand and someone offers some cheaper snake-oil, I probably go for that. Rather than exposing the complexity of the matter with a zoo of options you can choose from, we need to focus on a single generic mechanism and a well designed user experience. It's all there (meaning S/MIME and TLS), it just needs to become a little simpler to manage. So rather than re-inventing the n-solution for Web-ID, SSO or One-Time-Passwords, we - as a community - should improve what is already existing. What do you decipher from the following? http://lists.w3.org/Archives/Public/public-sysapps/2012Jun/0058.html Anders Andreas Am 03.10.2012 11:09, schrieb Anders Rundgren: http://www.w3.org/2012/09/sysapps-wg-charter http://www.linkedin.com/redirect?url=http%3A%2F%2Fwww%2Ew3%2Eorg%2F2012%2F09%2Fsysapps-wg-charterurlhash=Tqzg_t=tracking_disc Since the smart card industry have never managed making their stuff web compatible before, I assume they will fail this time as well. Anders ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 571 56149 -http://www.cardcontact.de
Re: [opensc-devel] W3C takes on Web+SecurityElements
Hmmm, so why would I want an IDP if I could prove my identity (certificate) and authenticity (client signature in SSL) with the credentials I have on my card ? Is it because SAML is easier to integrate than SSL client authentication ? Or is it because I want my IDP (e.g. Google / Facebook) to know what I'm doing ? The IDP model is perfect for username / password, but IMHO it's of less use when you use keys and certificates. In the later case the CA is your IDP by providing you with a certificate you can use to authentication towards others (who trust that certificate issuer as they would trust the IDP). And just lets wait for the first Diginotar incident at an IDP - ops they've copied our SAML signing keys...) Andreas Am 03.10.2012 15:44, schrieb Douglas E. Engert: On 10/3/2012 5:08 AM, Andreas Schwier (ML) wrote: So why do you think the smart card industry has never managed to get their stuff web compatible ? Isn't OpenSC the best example that Yes, you can access a protected website / webapplication / webservice using a smart card and standard based technology works ? The issue really is, that the topic at hand (PKI) is way to complex for the average Doe to manage. That's always the downside: Security often means complexity and comes with a price tag. And if it is complex, hard to understand and someone offers some cheaper snake-oil, I probably go for that. Rather than exposing the complexity of the matter with a zoo of options you can choose from, we need to focus on a single generic mechanism and a well designed user experience. It's all there (meaning S/MIME and TLS), it just needs to become a little simpler to manage. So rather than re-inventing the n-solution for Web-ID, SSO or One-Time-Passwords, we - as a community - should improve what is already existing. The approach we are taking for SSO is Shibboleth. http://shibboleth.net/ Using the X509 login handler: https://wiki.shibboleth.net/confluence/display/SHIB2/X.509+Login+Handler OpenSC provides the client cert and key for TLS authentication to the IDP. Shibboleth is all SAML based, and can work with other SAML based services. Support for OTP or whatever then is only needed in the IDP. Andreas Am 03.10.2012 11:09, schrieb Anders Rundgren: http://www.w3.org/2012/09/sysapps-wg-charter http://www.linkedin.com/redirect?url=http%3A%2F%2Fwww%2Ew3%2Eorg%2F2012%2F09%2Fsysapps-wg-charterurlhash=Tqzg_t=tracking_disc Since the smart card industry have never managed making their stuff web compatible before, I assume they will fail this time as well. Anders ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 571 56149 -http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Testing
Hi Viktor, we've tested the nightly build (OpenSC-git20121002092635-win32.msi) that includes write support for the SmartCard-HSM and found no issues. We've tested with our own PKCS#11 test suite, integration with Firefox 15.0.1 and Thunderbird 15.0.1 on Windows XP SP3. Will there be a new release candidate ? Andreas -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 571 56149 -http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] SIGV when deleting certificate but not related public key
Hi all, there is apparently a nasty bug in framework-pkcs15.c that causes a SIGV when via PKCS#11 a certificate object is deleted, but not the related public key object. Occasionally this triggers a SIGV when the caller later accesses the CKA_ID attribute which tries to access the then deleted certificate object. Is there any expert on the list that has intimate knowledge of the framework code that could take a look at it ? Andreas -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 571 56149 -http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] SIGV when deleting certificate but not related public key
Hi Peter, I will first need to write a small test in C to reproduce the problem. Right now we test from Java, which makes debugging a real nightmare. Andreas Am 27.09.2012 11:25, schrieb Peter Stuge: Andreas Schwier (ML) wrote: there is apparently a nasty bug in framework-pkcs15.c that causes a SIGV when via PKCS#11 a certificate object is deleted, but not the related public key object. Occasionally this triggers a SIGV when the caller later accesses the CKA_ID attribute which tries to access the then deleted certificate object. Is there any expert on the list that has intimate knowledge of the framework code that could take a look at it ? Please send a backtrace. Build the program with debugging, run the program with gdb --args program, then type bt after the crash. Post output. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 571 56149 -http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] SIGV when deleting certificate but not related public key
Just tried the same.
There is also a SIGV if you try to delete the public key alone.
Apparently the public key object in the framework has no related object
in the pkcs15 layer.
Andreas
Am 27.09.2012 13:04, schrieb Viktor Tarasov:
On Thu, Sep 27, 2012 at 11:30 AM, Peter Stuge pe...@stuge.se
mailto:pe...@stuge.se wrote:
Andreas Schwier wrote:
I will first need to write a small test in C to reproduce the
problem.
Right now we test from Java, which makes debugging a real nightmare.
Maybe you can reproduce it using some of the existing command line
tools?
It can be reproduced, using command
# pkcs11-tool --module ./build/lib/opensc-pkcs11.so --slot-index 0 -l
--pin 1234 --delete-object --type cert --id object-id
and patched pkcs11-tool:
diff --git a/src/tools/pkcs11-tool.c b/src/tools/pkcs11-tool.c
index f23948b..30074d8 100644
--- a/src/tools/pkcs11-tool.c
+++ b/src/tools/pkcs11-tool.c
@@ -824,6 +824,9 @@ int main(int argc, char * argv[])
util_fatal(You should specify at least one
of the
object ID, object label,
application label or application ID\n);
delete_object(session);
+
+ printf(Now list public keys ...\n);
+ list_objects(session, CKO_PUBLIC_KEY);
}
if (do_set_id) {
I will look for the solution.
//Peter
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
mailto: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
--
-CardContact Software System Consulting
|.## ##.| Andreas Schwier
|# #| Schülerweg 38
|# #| 32429 Minden, Germany
|'## ##'| Phone +49 571 56149
-http://www.cardcontact.de
http://www.tscons.de
http://www.openscdp.org
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] new release?
Hi Viktor, we've completed the development of write support for the SmartCard-HSM and are in the middle of testing and bug-fixing. The code is based on the latest version in OpenSC/staging and changes mostly apply to our own code. Is there a chance to get write support into the upcomin release ? If yes, I would prepare a pull request against the CardContact/staging branch. Andreas Am 17.09.2012 22:00, schrieb Viktor Tarasov: Hello, Le 15/09/2012 16:52, Kalev Lember a écrit : On 09/06/2012 08:06 PM, Viktor Tarasov wrote: Hello, current github 'staging' is tagged as v0.13.0-pre1. If no objections, I will merge this branch into github 'master' -- it will be base version to test and to prepare the coming release candidate. Very good idea. I think it makes a lot of sense to have just one 'master' branch for development; this is what people coming over from other projects tend to expect. 'Master' and 'staging' are actually synchronized and for the new pull requests I propose to create them relative to the 'master' branch. Until the end of this release the pull requests to 'staging' are also accepted. The tag name 'v0.13.0-pre1' has been changed (sorry) to '0.13.0pre1' -- still cannot understand which common set of characters could be used for the release-version/tag-name to satisfy 'git', 'obs', 'dpkg-build', ... Commits to 'master' and new tags trigger the jenkins jobs of build, packaging and some rudimentary test of package and unit tests (for Suse). https://opensc.fr/jenkins/view/Open https://opensc.fr/jenkins/view/OpenSC-release/SC-release/ https://opensc.fr/jenkins/view/OpenSC-release/ The resulting packages are transfered to 'download' part of the opensc-project.org file server: - commits to http://www.opensc-project.org/downloads/projects/opensc/nightly/ - releases to http://www.opensc-project.org/downloads/projects/opensc/releases/ For a while there are only source tarballs, MSIs for x32 and x64 and rpm i586 for opensSuSE 12.1 . Hope that rapidly the building of releases packages for some debian/ubuntu distributions will be connected. It would be nice if you could look/test the tarball or packages of the release 0.13.0pre1. Your remarks, proposals, contributions are heartily welcome. Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 571 56149 -http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Strange issue in framework-pkcs15.c / pkcs15_gen_keypair
Dear all, we've come a across a strange issue in OpenSC. When we try to generate a key pair with parameters not supported by the card, then the framework code still tries to allocate private/public key objects rather than returning an error code. The questionable code is in line 2675 of framework-pkcs15.c / pkcs15_gen_keypair. Is that an intended behaviour or a plain bug ? Andreas -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 571 56149 -http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Strange issue in framework-pkcs15.c / pkcs15_gen_keypair
Hi Douglas, the same problem exists for RSA keys. If you specify an invalid key size, the code tries to generate invalid objects. Our fix ist at https://github.com/CardContact/OpenSC/commit/a9682fd704dca5abc028b32e5ec577aa1c12ee78 Andreas Am 25.09.2012 16:31, schrieb Douglas E. Engert: On 9/25/2012 5:01 AM, Andreas Schwier (ML) wrote: Dear all, we've come a across a strange issue in OpenSC. When we try to generate a key pair with parameters not supported by the card, then the framework code still tries to allocate private/public key objects rather than returning an error code. The questionable code is in line 2675 of framework-pkcs15.c / pkcs15_gen_keypair. Is that an intended behaviour or a plain bug ? Same problem as before. No one has had a PKCS#15 card that supports ECC. The original ECC code added to OpenSC was for client use only, and used the PIV card. For testing the piv-tool could tell the card to generate a key pair, but that was not via and PKCS standards. Andreas -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 571 56149 -http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] new release?
Hi Viktor, we are testing on Windows XP SP3, Debian Lenny and a current Ubuntu version. Our focus is on PKCS#11 and integration with Firefox, Thunderbird and XCA. We already tested minidriver with IE and Outlook, but we do short regression tests with each new build. We've set up automated tests using our Smart Card Shell, which interfaces with PKCS#11 using opensc-java. This way we test key generation of all kinds (RSA/EC), certificates issuance and storing as well as data element reading/writing. We also have a quick regression test using a script with various pkcs11-tool commands. We've also done tests using the IAIK PKCS#11 wrapper that worked well. So far we're quite confident that the current code base is stable. We have three things left on our list, but they are not pressing: 1. Adding support to have domain parameter at the PKCS#11 interface for EC public keys after on card generation (i.e. serialize/ deserialize public keys as spki) 2. Adding support for explicit domain parameter in EC_PARAMS 3. Fast-track C_Initialize and C_SetPIN into the card-driver (The SmartCard-HSM uses a PKCS#11 like token initialization) Given the fact, that these changes touch core code, we would schedule this topics for the .14 release. Andreas Am 25.09.2012 17:04, schrieb Viktor Tarasov: Hi Andreas, On Tue, Sep 25, 2012 at 9:14 AM, Andreas Schwier andreas.schw...@cardcontact.de mailto:andreas.schw...@cardcontact.de wrote: we've completed the development of write support for the SmartCard-HSM and are in the middle of testing and bug-fixing. Fine, what part of the common OpenSC libraries are involved into your tests (pkcs11, minidriver, pkcs15, ...) ? What are the OSs? The code is based on the latest version in OpenSC/staging and changes mostly apply to our own code. Is there a chance to get write support into the upcomin release ? If yes, I would prepare a pull request against the CardContact/staging branch. Ok, you can make pull request to 'staging' or 'master' of OpenSC/OpenSC -- two branches are kept syncronized. Andreas Kind wishes, Viktor. Am 17.09.2012 22:00, schrieb Viktor Tarasov: Hello, Le 15/09/2012 16:52, Kalev Lember a écrit : On 09/06/2012 08:06 PM, Viktor Tarasov wrote: Hello, current github 'staging' is tagged as v0.13.0-pre1. If no objections, I will merge this branch into github 'master' -- it will be base version to test and to prepare the coming release candidate. Very good idea. I think it makes a lot of sense to have just one 'master' branch for development; this is what people coming over from other projects tend to expect. 'Master' and 'staging' are actually synchronized and for the new pull requests I propose to create them relative to the 'master' branch. Until the end of this release the pull requests to 'staging' are also accepted. The tag name 'v0.13.0-pre1' has been changed (sorry) to '0.13.0pre1' -- still cannot understand which common set of characters could be used for the release-version/tag-name to satisfy 'git', 'obs', 'dpkg-build', ... Commits to 'master' and new tags trigger the jenkins jobs of build, packaging and some rudimentary test of package and unit tests (for Suse). https://opensc.fr/jenkins/view/Open https://opensc.fr/jenkins/view/OpenSC-release/SC-release/ https://opensc.fr/jenkins/view/OpenSC-release/ The resulting packages are transfered to 'download' part of the opensc-project.org http://opensc-project.org file server: - commits to http://www.opensc-project.org/downloads/projects/opensc/nightly/ - releases to http://www.opensc-project.org/downloads/projects/opensc/releases/ For a while there are only source tarballs, MSIs for x32 and x64 and rpm i586 for opensSuSE 12.1 . Hope that rapidly the building of releases packages for some debian/ubuntu distributions will be connected. It would be nice if you could look/test the tarball or packages of the release 0.13.0pre1. Your remarks, proposals, contributions are heartily welcome. Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org mailto:opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 571 56149 tel:%2B49%20571%2056149 -http://www.cardcontact.de http://www.tscons.de http
Re: [opensc-devel] Domain Parameter for ECC Keys
Hi Douglas, see below. Andreas Am 20.09.2012 17:12, schrieb Douglas E. Engert: On 9/19/2012 6:11 PM, Andreas Schwier (ML) wrote: Dear all, we've come across a strange behaviour of the pkcs15-lib in OpenSC when we generate an EC key pair: After generating an fresh EC key pair, our code returns a sc_pkcs15_pubkey containing the EC public key and DER encoded domain parameter. The public key is then encoded in sc_pkcs15init_generate_key and added to the DF in the framework when it's immediately decoded again. During this encode / decode step the domain parameter are lost. Looked at PKCS#15 v1.1 section 6.4.3 The value is a EC_PubKeyChoice, that can be a raw ECPoint or a spki SubjectPublicKeyInfo. It looks like the sc_pkcs15_encode_pubkey_ec is just returning the ECPoint. sc_pkcs15_decode_pubkey_ec is also assuming the ECPoint. It looks like that code has never been fully tested, and the above code should be modified to use the spki SubjectPublicKeyInfo if there are domain parameters. With the EC work I have done in OpenSC including writing the above two routines, I have not looked at the pkcs15init code at all, as the PIV card is not a PKCS#15 card but rather the PKCS#15 is emulated, and the emulation layer is base on the decoded entries. The PIV does not use the pkcs15init code at all, but rather a special pivtool can be used for test cards to generate a key. It also turns out that the PIV card does not store a pubkey object at all, but derives the pubkey from the certificate. I'm wondering why this encode / decode step is done ? No one has a PKCS#15 cards that support EC to test this part of the code. We do have a card that supports EC ;-) If it is required for some reason, then I would rather encode the public key in SubjectPublicKey structure that would also preserve the domain parameter in AlgorithmIdentifier. Can you come up with a patch? Yes, we can certainly do that. I just wanted to make sure that I understand the rational behind the current implementation. Andreas -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 571 56149 -http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Domain Parameter for ECC Keys
Dear all, we've come across a strange behaviour of the pkcs15-lib in OpenSC when we generate an EC key pair: After generating an fresh EC key pair, our code returns a sc_pkcs15_pubkey containing the EC public key and DER encoded domain parameter. The public key is then encoded in sc_pkcs15init_generate_key and added to the DF in the framework when it's immediately decoded again. During this encode / decode step the domain parameter are lost. I'm wondering why this encode / decode step is done ? If it is required for some reason, then I would rather encode the public key in SubjectPublicKey structure that would also preserve the domain parameter in AlgorithmIdentifier. Andreas -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 171 8334920 -http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Creating a new PKCS#15 profile
Dear Matthias, what does opensc-tool -n report for this card ? Did you check if the card OS is supported by OpenSC ? Andreas Am 18.09.2012 15:43, schrieb Mathias Tausig: Hy! I have a smartcard which is initialized with a signature application. Now I want to add a PKCS#15 application to the card, which references that data. I have started to add a new DF with some basic information according to the PKCS#15 specifications, so far I have an Object directory file and a certificate directory file. I tried to access the card with pkcs15-tool --dump, but I got th error message: PKCS#15 binding failed: Unsupported card I assume, that I somehow have to create a new profile for the card. Is this correct? Is there some guidance, how this is done? cheers Mathias ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 171 8334920 -http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] new server hoster and adminstrator for opensc-project.org required
Hi, wouldn't it be better to move the remaining parts of the project to github ? Is there anything else important left on the server than the wiki ? What about the old svn repos ? We're still maintaining the opensc-java code here in our repository but have no way to bring the code back into opensc. We already thought about migrating this part into our repo at github. Andreas Am 12.09.2012 22:03, schrieb Andreas Jellinghaus: Hi, opensc-project.org http://opensc-project.org needs a new home: someone with a (real or virtual) server and the interest in setting it up from scratch and keeping it running and maintaining that server, installation and service for the project. someone who is able to win the trust of the community as new server administrator. The current installation is terribly old. It is based on ubuntu hardy and I think that is nearing the end of its supported livetime or even is unsupported now, thus it is urgently required to rebuild the server. Over the years we had several approaches and various people offered to take over running the server, but so far none of those worked out in the end, noone followed up after the initial discussion. To give this new efford more motivation here is some presure: running a server without maintenance and security updates is not a good idea. Thus I will shut down the current installation at the last end of this year. Any motivated linux administrator can setup a simple server with apache and a few copies of trac, plus postfix and a few mailing lists in a few hours or a day, with maybe a bit more time for fine tuning and migration of the content. This shouldn't be a big deal, thus there should be enough time to find someone interested in doing so and migrating opensc and related projects of the outdated installation. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 171 8334920 -http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] new release?
Hi Victor, I'm fine with that. We still need more time for testing write support in the SmartCard-HSM driver. So we rather take our time and put that functionality into a later release. Andreas Am 06.09.2012 20:06, schrieb Viktor Tarasov: Hello, current github 'staging' is tagged as v0.13.0-pre1. If no objections, I will merge this branch into github 'master' -- it will be base version to test and to prepare the coming release candidate. For the future (after this release), I think (and it was already suggested here) that we don't really need two branches in github. We could use the unique 'master' branch, tag it as needed by release process, and to manage all proposals as pull requests to 'master'. For a while there is no packages (tarbals, MSIs, ...) labeled by tag name, only the packages automatically built on 'staging' branch and labeled by git version. I will create the release dedicated jenkins jobs and will put thus prepared packages onto the 'usual' places. Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 171 8334920 -http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Patch for pkcs15init/pkcs15-lib
Dear all, while we are working on write support for the SmartCard-HSM we've come across some issues in pkcs15-lib. The issues are mostly related to the isolation between the pkcs15 framework and the emulation layer. We've authored a patch for the issues. Because we can not oversee the impact of our patch for other cards, we would like to ask card driver writers for a review. The patch can be found at [1]. Thanks, Andreas [1] https://github.com/CardContact/OpenSC/commit/b3b9bde068c6ebd96469b71235a76ce4c719a490 -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 171 8334920 -http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Minidriver assume hexstring encoding for card serial number
Hi everyone, we've come across an issue with the minidriver which assumes the card serial number to be a hex string. In our card the serial number is a string composed of ASCII characters. This works well with pkcs15-tool and the PKCS#11 library, however it fails with the current minidriver when it tries to convert the hex string into binary data for the cardid file. Neither in PKCS#11 spec nor in ISO 7816-15 I can find a definition for encoding the serial number as hex string. I therefore propose to change the code in minidriver.c to do the following: 1. try parsing tokeninfo-serial_number as hex string 2. if that fails copy serial_number as is with the length being the length of the ASCII encoded string This should not interfere with current card drivers which all use a hex string as serial number. Any objections ? Andreas -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 171 8334920 -http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Minidriver assume hexstring encoding for card serial number
Hi Douglas,
thanks for your infos.
The minidriver.c already ensures that the cardid file is always 16 byte.
It does this by repeating the token serial number until 16 bytes are filled.
We can ensure uniqueness of the serial number for our cards, but no
uniqueness among all other card vendors. There remains a (very) little
probability that a hexadecimal encoded serial number of another vendor's
card resembles one of our ASCII serial numbers.
Our serial numbers are based on the numbering scheme for machine
readable travel documents, a 2 digit country code followed by up to 9
ASCII digits (e.g. UTTM1234567 equals 5554544D313233343536375554544D31
in cardid).
Our proposed change (see [1]) will not alter the current behaviour with
existing cards. It will just allow a card that uses a ASCII serial
number to work as well.
An alternative approach - and probably more invasive - would be to use
the result of SC_CARDCTL_GET_SERIALNR in minidriver.c as input for the
cardid file. This way we could still have our human readable serial
number at the PKCS#11 und PKCS#15 level and a little more uniqueness in
the cardid file. This will however break existing installations, as the
content of the cardid file might change with the driver update.
Andreas
[1]
https://github.com/CardContact/OpenSC/commit/724cdd06e23ecd2e822bd1f138d9c3fbdafe9324
Am 22.08.2012 16:29, schrieb Douglas E. Engert:
On 8/22/2012 5:28 AM, Andreas Schwier (ML) wrote:
Hi everyone,
we've come across an issue with the minidriver which assumes the card
serial number to be a hex string.
In our card the serial number is a string composed of ASCII characters.
This works well with pkcs15-tool and the PKCS#11 library, however it
fails with the current minidriver when it tries to convert the hex
string into binary data for the cardid file.
Neither in PKCS#11 spec nor in ISO 7816-15 I can find a definition for
encoding the serial number as hex string.
The minidriver does not use the PKCS#11 standards, it is the Microsoft
definition of what it expects in the cardid file that counts.
http://www.microsoft.com/whdc/device/input/smartcard/sc-minidriver.mspx
Section 5.4.1 says:
The logical name for this file is “CardId”. It is in the root directory.
The file is organized as a 16-byte array. It should be treated as opaque
binary data.
This value is assigned by Microsoft software to assure that a unique value
is
generated for the card. It is unrelated to the serial number that may or
may not
be assigned to the card during manufacture.
In other places it calls it as a GUID.
This also means that when displayed, it maybe displayed as a GUID as hex
digits
with {, } , and - added for readability, and some bytes reversed in
little
endian machines. So it may not be recognizable as your serial number.
That said, since the minidriver is emulating a card that should have a cardid
file,
the data to populate the emulated cardid file has to come from the card and
be the same
at every use, and unique across all cards not just one site or one card
vendor.
The value or its derivatives are stored in the certificate store and used
to associate cards with data previously cached.
I therefore propose to change the code in minidriver.c to do the following:
1. try parsing tokeninfo-serial_number as hex string
2. if that fails copy serial_number as is with the length being the
length of the ASCII encoded string
It must be 16 bytes.
This should not interfere with current card drivers which all use a hex
string as serial number.
Any objections ?
If you can show that your method has enough uniqueness, to not cause problems
with other cards, then no.
Andreas
--
-CardContact Software System Consulting
|.## ##.| Andreas Schwier
|# #| Schülerweg 38
|# #| 32429 Minden, Germany
|'## ##'| Phone +49 171 8334920
-http://www.cardcontact.de
http://www.tscons.de
http://www.openscdp.org
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Minidriver assume hexstring encoding for card serial number
Hi Douglas, see below. Am 22.08.2012 18:00, schrieb Douglas E. Engert: On 8/22/2012 10:09 AM, Andreas Schwier wrote: Hi Douglas, thanks for your infos. The minidriver.c already ensures that the cardid file is always 16 byte. It does this by repeating the token serial number until 16 bytes are filled. Unfortunately that gives OpenbSC 16 bytes but does not improve the uniqunness. Fortunately the uniqueness today only needs to extend over all the cards as seen on a single machine which may be only a hand full. the cardid is not sent to AD for example. But it also means that if the certificates or keys on a card are changed, the cardid should also change. We can ensure uniqueness of the serial number for our cards, but no uniqueness among all other card vendors. There remains a (very) little probability that a hexadecimal encoded serial number of another vendor's card resembles one of our ASCII serial numbers. Our serial numbers are based on the numbering scheme for machine readable travel documents, a 2 digit country code followed by up to 9 ASCII digits (e.g. UTTM1234567 equals 5554544D313233343536375554544D31 in cardid). You did not say what was the minimum number of digits are, and in you example the first 4 ACSII digits are letters not numbers that introduce more uniqueness then numbers. Also for a single machine would it always see the same country code? The serial number is always 11 characters (0-9, A-Z). The country code is the country of the card issuer, within a country the card issuer gets a 2-character prefix and will define the remaining 7 character. If you have 9 ASCII characters that should introduce enough uniqueness to avoid conflicts with your other cards and other vendors cards. One point I am trying to make is the cardid value is not really seen by the user, thus it does not have to be printable, and it could hold more uniqueness then a printable string. But if there is not enough unique data on the card to populate the cardid you have to use whatever you have. Yes, I understand. I'm just concerned about the serial number visible to the user at the PKCS#15 and PKCS#11 level. There it would be nice to see the same serial number as the one printed on the card. My point is, that currently the minidriver silently assumes that the tokeninfo-serial_number contains a string with hexadecimal characters. Our proposed change (see [1]) will not alter the current behaviour with existing cards. It will just allow a card that uses a ASCII serial number to work as well. An alternative approach - and probably more invasive - would be to use the result of SC_CARDCTL_GET_SERIALNR in minidriver.c as input for the cardid file. This way we could still have our human readable serial number at the PKCS#11 und PKCS#15 level and a little more uniqueness in the cardid file. On some cards whewre there is no serial readable form the card the SC_CARDCTL_GET_SERIALNR does similar tricts to come up with a serial number from what ever data it can use on the card. This will however break existing installations, as the content of the cardid file might change with the driver update. Yes it might break existing installations, as it would look like a new card to the application, but with the same certificate on two cards. This could be an issue if Windows searches the cert store for a certificate, then asks the user to insert the matching card. i.e. the old card, not the new one. As long as you have 6 digits or characters in your printable string that should be fine. Andreas [1] https://github.com/CardContact/OpenSC/commit/724cdd06e23ecd2e822bd1f138d9c3fbdafe9324 Am 22.08.2012 16:29, schrieb Douglas E. Engert: On 8/22/2012 5:28 AM, Andreas Schwier (ML) wrote: Hi everyone, we've come across an issue with the minidriver which assumes the card serial number to be a hex string. In our card the serial number is a string composed of ASCII characters. This works well with pkcs15-tool and the PKCS#11 library, however it fails with the current minidriver when it tries to convert the hex string into binary data for the cardid file. Neither in PKCS#11 spec nor in ISO 7816-15 I can find a definition for encoding the serial number as hex string. The minidriver does not use the PKCS#11 standards, it is the Microsoft definition of what it expects in the cardid file that counts. http://www.microsoft.com/whdc/device/input/smartcard/sc-minidriver.mspx Section 5.4.1 says: The logical name for this file is “CardId”. It is in the root directory. The file is organized as a 16-byte array. It should be treated as opaque binary data. This value is assigned by Microsoft software to assure that a unique value is generated for the card. It is unrelated to the serial number that may or may not be assigned to the card during manufacture. In other places it calls it as a GUID. This also means that when displayed, it maybe
Re: [opensc-devel] Minidriver assume hexstring encoding for card serial number
Yes, that's basically what our patch is all about. There are actually
two places in minidriver.c where the tokeninfo-serial_number value is
copied. We propose to change both as you can see in [1].
Andreas
[1]
https://github.com/CardContact/OpenSC/commit/724cdd06e23ecd2e822bd1f138d9c3fbdafe9324
Am 22.08.2012 20:30, schrieb Douglas E. Engert:
On 8/22/2012 11:24 AM, Andreas Schwier (ML) wrote:
Hi Douglas,
see below.
Am 22.08.2012 18:00, schrieb Douglas E. Engert:
On 8/22/2012 10:09 AM, Andreas Schwier wrote:
Hi Douglas,
thanks for your infos.
The minidriver.c already ensures that the cardid file is always 16 byte.
It does this by repeating the token serial number until 16 bytes are
filled.
Unfortunately that gives OpenbSC 16 bytes but does not improve the
uniqunness.
Fortunately the uniqueness today only needs to extend over all the cards
as seen on a single machine which may be only a hand full. the cardid
is not sent to AD for example. But it also means that if the certificates
or keys on a card are changed, the cardid should also change.
We can ensure uniqueness of the serial number for our cards, but no
uniqueness among all other card vendors. There remains a (very) little
probability that a hexadecimal encoded serial number of another vendor's
card resembles one of our ASCII serial numbers.
Our serial numbers are based on the numbering scheme for machine
readable travel documents, a 2 digit country code followed by up to 9
ASCII digits (e.g. UTTM1234567 equals 5554544D313233343536375554544D31
in cardid).
You did not say what was the minimum number of digits are, and
in you example the first 4 ACSII digits are letters not numbers that
introduce more uniqueness then numbers. Also for a single machine would
it always see the same country code?
The serial number is always 11 characters (0-9, A-Z). The country code
is the country of the card issuer, within a country the card issuer gets
a 2-character prefix and will define the remaining 7 character.
OK, so you are looking at how to handle the failure
in minidriver.c at line 1071, not on getting a printable string to show up.
1069 rv =
sc_hex_to_bin(vs-p15card-tokeninfo-serial_number, sn_bin, sn_len);
1070 if (rv)
1071 return SCARD_E_INVALID_VALUE;
by change to something like:
rv = sc_hex_to_bin(vs-p15card-tokeninfo-serial_number, sn_bin,
sn_len);
if (rv) {
strncpy(s_bin, vs-p15card-tokeninfo-serial_number,
sizeof(sn_bin));
sn_len = strlen(vs-p15card-tokeninfo-serial_number);
if (sn_len 2) /* really too short to use as a cardid */
return SCARD_E_INVALID_VALUE;
if (sn_len sizeof(sn_bin)) sn_len = sizeof(sn_bin);
}
I have not tried this.
Since this fails, in your case, I don't have any objection to adding something
like the above.
If you have 9 ASCII characters that should introduce enough uniqueness
to avoid conflicts with your other cards and other vendors cards.
One point I am trying to make is the cardid value is not really seen
by the user, thus it does not have to be printable, and it could
hold more uniqueness then a printable string. But if there is not
enough unique data on the card to populate the cardid you have to use
whatever you have.
Yes, I understand. I'm just concerned about the serial number visible to
the user at the PKCS#15 and PKCS#11 level. There it would be nice to see
the same serial number as the one printed on the card. My point is, that
currently the minidriver silently assumes that the
tokeninfo-serial_number contains a string with hexadecimal characters.
Our proposed change (see [1]) will not alter the current behaviour with
existing cards. It will just allow a card that uses a ASCII serial
number to work as well.
An alternative approach - and probably more invasive - would be to use
the result of SC_CARDCTL_GET_SERIALNR in minidriver.c as input for the
cardid file. This way we could still have our human readable serial
number at the PKCS#11 und PKCS#15 level and a little more uniqueness in
the cardid file.
On some cards whewre there is no serial readable form the card the
SC_CARDCTL_GET_SERIALNR does similar tricts to come up with a serial
number
from what ever data it can use on the card.
This will however break existing installations, as the
content of the cardid file might change with the driver update.
Yes it might break existing installations, as it would look like a new card
to the application, but with the same certificate on two cards. This could
be
an issue if Windows searches the cert store for a certificate, then asks the
user to insert the matching card. i.e. the old card, not the new one.
As long as you have 6 digits or characters in your printable string that
should
be fine.
Andreas
[1]
https://github.com/CardContact/OpenSC/commit
Re: [opensc-devel] OpenSC Bugs and releases
Dear Viktor, we're doing quite a lot of testing currently. So when you have a release candidate, just let me know. Andreas Am 18.08.2012 18:45, schrieb Viktor Tarasov: Hello Douglas. Le 16/08/2012 20:01, Douglas E. Engert a écrit : Viktor, Thanks for going through all OpenSC bug reports the last few days. Its been a long time since that has been done. Do you have a time estimate when you will be done, and when we can have a 0.13.0 release candidate? Vaguely it could be the weekend -- one more week to look over the current tickets and for the tests. I have no experience in the release preparation and do not clearly imagine the criterion that can be used to declare the release candidate ready. Would be nice to hear your point of view on this and other release related questions. Thanks. Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 171 8334920 -http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] PIV: signature output format
Hi Douglas,
I'm fine with that. I already changed our card driver to provide the
r||s format anyway.
After 0.13.0 we should work on the issue.
Did anyone already considered implementing support for PKCS#1 PSS format ?
We have support for it in the SmartCard-HSM and want to add it to OpenSC.
Andreas
Am 13.08.2012 00:45, schrieb Douglas E. Engert:
On 8/11/2012 1:26 PM, Andreas Schwier (ML) wrote:
Hi Viktor and Douglas,
I do also favour to keep the DER signature format at the interface
between the card driver and the pkcs15 framework.
OK, we could do that. I would like to wait till after 0.13.0 is released,
as the current code is working.
What is your scheduling requirements?
At the card driver level we don't know the field size, but we do at the
pkcs15 framework level. And all cards I know use the DER encoded
signature format anyway.
Maybe we can reuse Douglas code and do a conditional conversion in
sc_pkcs11_signature_final.
Andreas
Am 26.06.2012 08:06, schrieb Viktor Tarasov:
On Mon, Jun 25, 2012 at 9:22 PM, Douglas E. Engert deeng...@anl.gov
mailto:deeng...@anl.gov wrote:
Just back from vacation...
On 6/21/2012 9:50 AM, Viktor TARASOV wrote:
Hi Douglas,
I'm trying to get signature with the PIV card and verify it
with the 'openssl pkeyutl'.
I use EC key #04 CARD AUTH Key.
It fails because of the 'raw' output format of the signature
produced by OpenSC.
OpenSSL expects the signature as a ASN1 sequence of two integers.
I've seen in card-piv.c your comments:
https://github.com/OpenSC/OpenSC/blob/staging/src/libopensc/card-piv.c#L2023
/* The PIV returns a DER SEQUENCE{INTEGER, INTEGER}
* Which may have leading 00 to force positive
* TODO: -DEE should check if PKCS15 want the same
It seems that PKCS#15 really wants it.
* But PKCS11 just wants 2* filed_length in bytes
Can you explain more? Why it wants 'raw' data?
PKCS#11 v2.30: says:
6.3.1 EC Signatures
For the purposes of these mechanisms, an ECDSA signature is an
octet string of even
length which is at most two times nLen octets, where nLen is the
length in octets of the
base point order n. The signature octets correspond to the
concatenation of the ECDSA
values r and s, both represented as an octet string of equal
length of at most nLen with the
most significant byte first. If r and s have different octet
length, the shorter of both must
be padded with leading zero octets such that both have the same
octet length.
PKCS#11 2.20 in Section 12.3.1 says the same as above.
PKCS#11 2.01 11.4.3 says basically the same thing, but assumes a
fixed size of nLen=20.
So PKCS#11 is not returning ASN1 but just the concatenation of r
and s.
Ok, thanks.
* So we have to strip out the integers
* if present and pad on left if too short.
*/
I would propose to keep the ASN1 encoded data at the PKCS#15
level,
and, if needed, to convert it to the 'raw' format by dedicated
procedure in the pkcs15 framework of pkcs11.
Where do you see in PKCS#15 that a ECDSA signature is in ANS1?
If it needs to be ASN1, then yes the conversion could be done in
the framework.
Ok, there is no signature in ASN.1 in pkcs#15, but there some
practical reasons.
The card itself (Oberthur's PIV) returns the signature encoded in ASN.1;
OpenSSL, for which the pkcs15-tool have to provide data in a suitable
format, needs also the ASN.1 encoding.
So, my suggestion is to keep the encoding returned by the card at the
pkcs#15 level,
and change it to the 'raw' mode on the pkcs#11 side.
Finally, I have no preference, if you prefer to keep it like it is
now, we'll be living with.
Kind regards,
Viktor.
--
Douglas E. Engert deeng...@anl.gov mailto:deeng...@anl.gov
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444 tel:%28630%29%20252-5444
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
--
-CardContact Software System Consulting
|.## ##.| Andreas Schwier
|# #| Schülerweg 38
|# #| 32429 Minden, Germany
|'## ##'| Phone +49 171 8334920
-http://www.cardcontact.de
http://www.tscons.de
http://www.openscdp.org
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc
Re: [opensc-devel] PIV: signature output format
Hi Viktor and Douglas,
I do also favour to keep the DER signature format at the interface
between the card driver and the pkcs15 framework.
At the card driver level we don't know the field size, but we do at the
pkcs15 framework level. And all cards I know use the DER encoded
signature format anyway.
Maybe we can reuse Douglas code and do a conditional conversion in
sc_pkcs11_signature_final.
Andreas
Am 26.06.2012 08:06, schrieb Viktor Tarasov:
On Mon, Jun 25, 2012 at 9:22 PM, Douglas E. Engert deeng...@anl.gov
mailto:deeng...@anl.gov wrote:
Just back from vacation...
On 6/21/2012 9:50 AM, Viktor TARASOV wrote:
Hi Douglas,
I'm trying to get signature with the PIV card and verify it
with the 'openssl pkeyutl'.
I use EC key #04 CARD AUTH Key.
It fails because of the 'raw' output format of the signature
produced by OpenSC.
OpenSSL expects the signature as a ASN1 sequence of two integers.
I've seen in card-piv.c your comments:
https://github.com/OpenSC/OpenSC/blob/staging/src/libopensc/card-piv.c#L2023
/* The PIV returns a DER SEQUENCE{INTEGER, INTEGER}
* Which may have leading 00 to force positive
* TODO: -DEE should check if PKCS15 want the same
It seems that PKCS#15 really wants it.
* But PKCS11 just wants 2* filed_length in bytes
Can you explain more? Why it wants 'raw' data?
PKCS#11 v2.30: says:
6.3.1 EC Signatures
For the purposes of these mechanisms, an ECDSA signature is an
octet string of even
length which is at most two times nLen octets, where nLen is the
length in octets of the
base point order n. The signature octets correspond to the
concatenation of the ECDSA
values r and s, both represented as an octet string of equal
length of at most nLen with the
most significant byte first. If r and s have different octet
length, the shorter of both must
be padded with leading zero octets such that both have the same
octet length.
PKCS#11 2.20 in Section 12.3.1 says the same as above.
PKCS#11 2.01 11.4.3 says basically the same thing, but assumes a
fixed size of nLen=20.
So PKCS#11 is not returning ASN1 but just the concatenation of r
and s.
Ok, thanks.
* So we have to strip out the integers
* if present and pad on left if too short.
*/
I would propose to keep the ASN1 encoded data at the PKCS#15
level,
and, if needed, to convert it to the 'raw' format by dedicated
procedure in the pkcs15 framework of pkcs11.
Where do you see in PKCS#15 that a ECDSA signature is in ANS1?
If it needs to be ASN1, then yes the conversion could be done in
the framework.
Ok, there is no signature in ASN.1 in pkcs#15, but there some
practical reasons.
The card itself (Oberthur's PIV) returns the signature encoded in ASN.1;
OpenSSL, for which the pkcs15-tool have to provide data in a suitable
format, needs also the ASN.1 encoding.
So, my suggestion is to keep the encoding returned by the card at the
pkcs#15 level,
and change it to the 'raw' mode on the pkcs#11 side.
Finally, I have no preference, if you prefer to keep it like it is
now, we'll be living with.
Kind regards,
Viktor.
--
Douglas E. Engert deeng...@anl.gov mailto:deeng...@anl.gov
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444 tel:%28630%29%20252-5444
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
--
-CardContact Software System Consulting
|.## ##.| Andreas Schwier
|# #| Schülerweg 38
|# #| 32429 Minden, Germany
|'## ##'| Phone +49 171 8334920
-http://www.cardcontact.de
http://www.tscons.de
http://www.openscdp.org
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Initial support for SmartCard-HSM
Dear Jean-Michel, the name's just a name ;-) Right now it provides support for RSA and ECC keys with a special remote provisioning scheme, but later we will add support for DES and AES keys and more advanced key management functions. Andreas Am 04.08.2012 18:15, schrieb Jean-Michel Pouré - GOOZE: Le vendredi 03 août 2012 à 15:54 +0200, Andreas Schwier (ML) a écrit : we've put in a pull request in github/opensc/staging to include a card driver and PKCS#15 emulation module for our SmartCard-HSM [1]. Nice. Out of question, why is it called HSM? What does it provide more than a crypto card? Kind regards, ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 171 8334920 -http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Initial support for SmartCard-HSM
I would assume, that checking constraints is the job of the RA, not the CA. Anyway, our design works the other way around: The card generates the CSR internally, so the RA/CA can prove the key was generated in a legitimate device. The device can be anywhere out in the wild. Andreas Am 06.08.2012 11:04, schrieb NdK: Il 06/08/2012 10:15, Andreas Schwier ha scritto: the name's just a name ;-) Probably he (like me) hoped it was something more like (would-be) MicroCA: a card taking a CSR and outputting a cert if constraints are satisfied... BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 171 8334920 -http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Initial support for SmartCard-HSM
Dear Peter, there is no technical reason, it's just because it's an easier first milestone. We plan to add full support in the next steps, including secure messaging. Andreas Am 04.08.2012 13:59, schrieb Peter Stuge: Andreas Schwier (ML) wrote: we've put in a pull request in github/opensc/staging to include a card driver and PKCS#15 emulation module for our SmartCard-HSM [1]. That sounds nice. I haven't yet looked at the code. This driver is a read-only driver that works with SmartCard-HSMs that already contain keys and certificates. Is there a technical reason for the driver to be read-only? I mean, it would be nice if OpenSC could also be used to initialize tokens. Perhaps write support would be optional at build time. Kind regards //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 171 8334920 -http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Initial support for SmartCard-HSM
Hi everyone, we've put in a pull request in github/opensc/staging to include a card driver and PKCS#15 emulation module for our SmartCard-HSM [1]. This driver is a read-only driver that works with SmartCard-HSMs that already contain keys and certificates. In order to work correctly with our card profile, we had to add support for EC private keys in pkcs15-prkey.c. If someone would like to receive a free sample card and specifications, please write me a personal e-mail. Kind regards Andreas [1] http://www.cardcontact.de/products/SmartCard-HSM_V1.0.pdf -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 171 8334920 -http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] questions on {ERASE, WRITE, UPDATE} BINARY commands
Hi Peter, ERASE and WRITE are left-overs from the old smart card days. Most - if not all - cards and applications today only implement UPDATE BINARY. There is also no common understanding that UPDATE BINARY must not extend the length of an EF. Some implementations maintain a maximum EF and a current EF size. The maximum size is typically set in CREATE FILE, whereas the current EF size depends on the amount of data written to the EF. An EF may start with no data contained and and UPDATE BINARY command with P1|P2 = Length of EF (or zero based offset after last byte ;-) appends the amount of data provided in the C-Data of the APDU. Usually gaps are not allowed, so an offset beyond end-of-file + 1 gives SW1/SW2=6B00. Other implementations allocate the full EF size at creation, so you can immediately read from the EF, even though no data has been written yet. Hope this helps, Andreas Am 07.06.2012 22:01, schrieb Peter Marschall: Hi, thanks for the quick reply/correction. On Thursday, 7. June 2012, Martin Paljak wrote: On Thu, Jun 7, 2012 at 10:35 PM, Martin Paljak mar...@martinpaljak.net wrote: Hello, On Thu, Jun 7, 2012 at 10:24 PM, Peter Marschall pe...@adpm.de wrote: Here they are: * What's the exact difference between WRITE BINARY UPDATE BINARY? My understanding of the spec is that WRITE BINARY can extend a file's size, while UPDATE BINARY can only update data elements that are already within the file (i.e. in the range [0 .. file_size-1]). Is my understanding correct or did I misunderstand the specscompletely? AFAIU either can change file size (which can be done though 7816-9). Correction, can NOT change file size. Does that mean that none of them can change the number of data elements that are in the file ? This seems to contradict the sentence in ISO 7816-4 7.2.4 WRITE BINARY which states: - the write-once of the bits given in the command data field (the command shall be aborted if thestring of data units is not in the logical erased state) To me that sentence sounds like WRITE BINARY is an operation that A) can only be used on data that is logically reset, (i.e. once WRITE_BINARY was performed, it cannot be used on the same data any more without a preceding ERASE BINARY of that region) B) can extend the number of data units in the file (this is what I sloppily called existing_file_size in my previous mail) In the other hand, ISO 7816-4 7.2.4 UPDATE BINARY says: the command initialtes the update of the bits already present in an EF ... This is what I interpret as can only update existing data units in the file, but not create more. Am I completely wrong? Are there interpretation helpers for the spec available somewhere? While I am at it: Would you mind to pull Pull Request #53 https://github.com/OpenSC/OpenSC/pull/53 into the staging branch of github's open/opensc? (It is a little bit frustrating to not get any feedback at all for a PullReq ;-) Thanks PEter -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 171 8334920 -http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] proving a key is on a smart card
Hi Frank, you are right with the German identity card, however our approach is different: Our card (which is no nPA) stores the key required for terminal authentication, not for chip authentication. The key for terminal authentication must be certified by a DVCA, which in turn is certified by a national CVCA. So the challenge is to prove, that the key pair for terminal authentication was actually generated at the secure token in the terminal. We are just reusing the established authenticated CSR format from TR-03110 and build that into the card. The key for signing the authenticated request can only be used for this specific purpose - this is enforced internally in the card. There is no secure messaging involved, because we only need to provide integrity and authenticity of the CSR. The scheme has no need for confidentiality, as all information is public anyway (CSR and certificate written to the card). Andreas Am 20.01.2012 11:49, schrieb Frank Morgner: Hi! I don't think that's enough? It doesn't matter if the card trusts the CA, it's that the CA has to trust the card. Difficult to do more with the common cards. As Andreas said, the German identity card (nPA) has this functionality (BSI TR-03110). A whole bunch of technical guidelines (TRs) describe every entity and process needed. Services that use the ID card for online authentication and identification are already available. What Andreas did not mention is that a card's key is actually shared among multiple cards for privacy reasons. This makes revocation a bit difficult. So for the nPA we will soon see chip individual keys and/or group signature schemes. Cheers, Frank. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 171 8334920 -http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] proving a key is on a smart card
Dear Frank, we have such a card. Take a look at [1]. The card internally generates a key pair and a CSR as defined in TR-03110 (that is the standard for biometric passports, in particular Extended Access Control). Such an authenticated request contains two signatures: the inner signature is the proof-of-correspondence (I own the private and public key) and the outer signature provides proof-of-origin (the key was generated in an authentic device). Each card contains a device authentication key that gets certified during production. A CA receiving a certificate request must 1. first verify the device authentication certificate read from the card, 2. then verify the outer signature with the public key obtained from the device authentication certificate, 3. then verify the inner signature to prove that the sender actually owns the private key and 4. finally issue a certificate for the public key contained. The scheme is specifically used for remote certificate issuance, where you can not rely on a secure communication channel between the CA and the token. Andreas [1] http://www.cardcontact.de/products/SmartCard-HSM_V1.0.pdf Am 19.01.2012 01:20, schrieb Frank Cusack: In a CSR, how is it proven that the key resides on a smart card (and is not exportable)? In my understanding, the CSR is signed by the private key of the (to be) cert itself. Thus that signature only proves that the requester actually possesses the private half, not that the private key resides on a smart card. Looking at the cryptoflex command set, I don't see anything there that would add something to the CSR asserting that the key was generated on-card. Same for ISO 7816-8, but I could easily be missing something. Are there card specific APDUs that add some proof? If so, any pointers to what cards can do this? Or is the typical method basically to require use of a secure enrollment station? ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 171 8334920 -http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Experiences with Java smartcardio
Hi Frank, thanks for the flowers. I owe you a drink. We've been accessing smart cards from Java for quite a while. It works well on Windows, Linux and Mac OS. You just need to know what you are doing. Andreas Maintainer of OpenSCDP Am 24.11.2011 10:04, schrieb Frank Morgner: On Wednesday, November 23 at 10:07PM, Anders Rundgren wrote: Hi, I just wonder what your opinion is about Java smart card io which is a part of JDK 1.6 and forward. I did a minute test and it wasn't overly convincing :-( OTOH, as we all know that smart card middle ware is hell on earth I may simple haven't given it enough time. AFAIK, smartcardio is only a wrapper to PC/SC. Have a look at http://www.openscdp.org/ It is a fork of the OpenCard-Framework, which is more what you would expect from a smart card middleware. GPL licensed, a lot of cards supported, nice tools, actively developed, can use smartcardio as backend. Cheers, Frank. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 171 8334920 -http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Java and pkcs11
The latest OCF package at [1] has support for smartcardio - so if you need more than just the APDU interface. Andreas [1] http://www.openscdp.org/ocf/download.html Am 12.08.2011 12:11, schrieb resoli - libero: Il giorno mer, 10/08/2011 alle 08.36 +0200, NdK ha scritto: On 09/08/2011 20:48, Vlastimil Pavicek wrote: I haven't read the whole thread, but you might find this library useful (it is easier to use than JNI/JNA): http://jce.iaik.tugraz.at/sic/Products/Core-Crypto-Toolkits/PKCS-11-Wrapper Tks. Found last night. It's used by j4sign[1] that targets multiple platforms. By its own it seems it's not enough, but it have to be used in parallel with the OCF wrapper (for card detection). I'm the main developer of j4sign; as someone already suggested, smartcardio is better suited at the moment for interfacing pcsc directly. j4sign will switch soon to smartcardio . bye, Roberto Resoli I'll have to dig better... [1] http://j4sign.sourceforge.net/index.html BYtE, Diego. ___ 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] AccessMode in ISO7816-15
Hi Viktor, ISO 7816-15:2004 defines read(0), update(1), execute(2) and delete(3). Andreas Viktor TARASOV schrieb: Hi, The 'accessMode' bit string, encoded by the native Oberthur middleware for the IAS/ECC cards, can be up to 10 bits length. In PKCS#15 (v1.1) for the 'accessMode' only three bits defined: 'read', 'update', 'execute'. In ECC specification (CEN/TS 15480-2:2007) one more: 'delete'. Have you an access to 7816-15, please? Does it's 'accessMode' definition identical to the one defined in PKCS#15? Do you know other specifications that define more of the AccessMode operations? Kind wishes, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC-java: Web application
Hello Martin, we also maintain a current version of the OpenCard Framework as part of the OpenSCDP Project at [1]. This has build in support for javax.smartcardio, secure messaging, generic ISO 7816 file services and much more. We use OCF as part of the Smart Card Shell scripting environment. Andreas [1] http://www.openscdp.org/ocf Martin Paljak schrieb: Hello, On Apr 7, 2010, at 17:28 , Harry Anuszewski wrote I currently have a java application that allows the user to login to a website using a smart card. I use openSC-java to select a card reader, create a session and pull out certificate information, etc. I would like to make this a web application but I know that openSC-java depends on a few .dll files for windows and a few .so files for linux. Right now I am just working with the windows half. The way my app works now is it checks for openSC in the system path if it doesn’t find it then it prompts to run an installer that I created that puts openSC in C:\program files\opensc and then adds that to the system path and reboots the computer. The next time the user goes to run the program they will be able to use opensc. What I am basically wondering is, is their a way to create a jar that has the opensc dependencies (.dll) so that the user never has to download and run my installer? Everything will be handled online. There are three aspects of Java and smart cards that matter in the context of web applications: - TLS/SSL client authentication (means configuration of the web container, so not really related to OpenSC) - access to cryptographic smart cards in applets via a JNI bridge to PKCS#11 (possible via Sun PKCS#11 provider available since Java 1.5+ or OpenSC-Java one, the problem you're facing) - access to smart cards via javax.smartcardio in Java 1.6+ IMO, the preferred way would be to use javax.smartcardio and bypass the JNI problem, if you have a specific smart card to talk to and don't need to rely on the PKCS#11 provider availability on the client machine. There is preliminary support for reading PKCS#15 structures a la OpenSC does, in Java, as pointed out in [1] There are some *very* preliminary pointers to Java resources on OpenSC wiki [1] which will be improved ASAP [1] http://www.opensc-project.org/opensc/wiki/Java ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC-Java required Dll and exe
Hi Harry, to access a PKCS#11 DLL you will just need the opensc-java.jar included in your classpath and opensc-PKCS11-0.3.dll file in a directory contained in the PATH environment variable or defined in java.library.path. The location and name of the PKCS#11 DLL is passed to the PKCS11Provider constructor. Andreas Harry Anuszewski schrieb: Hello, I am just wondering what the minimally required dlls / exe to use opensc-java on a Windows 32 bit machine. Without using the Smart Card Bundle and just compiling a fresh copy of OpenSC what is needed to be copied to the System32 directory to make openSC-java load the provider and work. Thank you, Harry ___ 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
[opensc-devel] Scripts for MuscleCard Applet
For those of you using the MuscleCard applet we've released a set of Smart Card Shell scripts and documentation [1] to get things going. The scripts have been tested with JCOP and Cyberflex 64K card, but maybe you want to give it a try with other JavaCards. Please let me know, if it works for you. Andreas [1] http://www.openscdp.org/scsh3/musclecard/index.html ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] GET CHALLENGE / EXTERNAL AUTHENTICATE Problem
Hi Peter, that depends on the algorithm used for EXTERNAL AUTHENTICATE. Quite typically CardOS uses a Retail-MAC, which is a single DES CBC with IV='00.00.00.00.00.00.00.00' using the left key half applied to all blocks, a decrypt with the right key half and a final encrypt with the left key half applied on the final block (In short: single DES for n-1 blocks, triple DES for last block). For the Smart Card Shell you could write ---8--8--8--8--8--8--8--8--8--- // // Authenticate against CardOS card // var card = new Card(_scsh3.reader); var crypto = new Crypto(); var key = new Key(); key.setComponent(Key.DES, new ByteString(01010101010101010101010101010101, HEX)); // Get challenge var challenge = card.sendApdu(0x00, 0x84, 0x00, 0x00, 8, [0x9000]); // Crypto.DES_MAC_EMV is a CBC generated Retail-MAC var cipher = crypto.sign(key, Crypto.DES_MAC_EMV, challenge); card.sendApdu(0x00, 0x82, 0x00, 0x81, cipher); print(Card returns + card.SW.toString(16) + - + card.SWMSG); ---8--8--8--8--8--8--8--8--8--- However you will need to know the key value for the authentication key, unless your system uses some way to derive the key from the PIN code (Using SHA-1 for example). This is quite uncommon, so I would assume that the PIN verification is done sometime before authentication takes place (using VERIFY INS=20 APDU). Andreas Peter Koch schrieb: Hi all! I'm trying to do an EXTERNAL AUTHENTICATE against a CardOS 4.01 card. Requesting the challenge is easy. But how do I calculate the response? Here's an example that I captured with an USB-sniffer: APDU 1: 0084 08, Response 584eb56f6d9f13c5 9000 APDU 2: 00820081 08 cdddb92642a38d3b, Response 9000 Does anybody know how response cdddb92642a38d3b was calculated from challenge 584eb56f6d9f13c5 using PIN 123456. I have already tried stuff like echo -en '\x58\x4e\xb5\x6f\x6d\x9f\x13\xc5' |\ openssl enc -des-ede3-ofb -K 313233343536 -iv 0 |\ od -tx1 with different cyphers. Unfortunately I don't know what IV-value must be used. Any ideas? Peter ___ SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 171 8334920 -http://www.cardcontact.de ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Secure Messaging
Hello Markus, Markus Schatzl schrieb: Hello, I'd be interested if somebody here has practical experience with Secure Messaging modes in general and would be so kind to answer a few questions: Yes, we have. See [1] / IsoSecureChannel class for how that works. In authentic as well as in combined mode, the use of symmetric ciphers seems to be the standard approach. To migitate simple MITM techniques, at least one keypair must be already integrated into ROM/EEPROM at the production/personalization stage and kept secret. I assume you mean protection of integrity and confidentiality. As a result, SM can only be used with designated terminals from a single emitting instance (or partner organizations) that have knowledge about this secret key. This defeats interoperability as a whole and reminds me to the infamous security by obscurity solutions popular in former decades. Are there any practical attempts to negotiate keys for SM by use of public keys? Yes, there is. Google for the e-SignK / CWA 14890 draft CEN standard. This describes secure messaging based on a shared secret key or using a hybrid scheme with card verifiable certificates (CVCs) (all based on ISO 7816-4). That is the procedure used by several smart card applications (eGK, ECC). What is the impact in terms of computation time for encrypted transfer at the moment, compared to a plain transmission? (Last info: x4) Depends on the card, but x4 seems realistic. Plain signature functionality is neither time-critical and generally uses basic facilities available on nearly every token. As digital signatures slowly gain acceptance outside specialized applications, are there any ambitions to secure the card-to-terminal communication by default? This is what is called trusted-channel and can be found in CWA 14890 for electronic signature applications in an untrusted environment. Isn't it urgently necessary to use ad-hoc interoperable security routines in the light of the legal status of digital signatures within the EU? That is what standards are for ;-) Andreas [1] www.openscdp.org/scsh3/index.html -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 171 8334920 -http://www.cardcontact.de ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] lsm pkcs#11 ?
The project is actually implementing a software security module (rather than a hardware security module / HSM) that uses a client/server approach with a PKCS#11 library on the client side. You run the deamon on one machine and use the PKCS#11 library on the client to access the cryptographic token. Cryptographic material is stored in a file on the server which is protected by some crypto-scheme. In a simplistic scenario that does not require any FIPS or ITSEC evaluated key store, you could put the server into a vault and have a cheap and minimalistic HSM (no tamper resistance however). The project can replace a HSM with a software implementation, but it does not allow to use PKCS#11 modules on the server (which is guess is what Andreas is looking for). Kind regards, Andreas Alon Bar-Lev schrieb: Hello Andreas, Why a daemon is required? Can't the card transaction be used to sync between instances? And if caching is required you can cache certificates by thumbprint at user home... Best Regards, Alon Bar-Lev. On 3/6/07, Andreas Jellinghaus [EMAIL PROTECTED] wrote: http://www.clizio.com/lsmpkcs11.html did anyone have a look at this software and try it? if it does what I think and if we could attach opensc to the daemon side of it, then we might be able to to real locking etc, and still have multi applications access a card - if the daemon caches the certs etc. not sure if that idea works out, but might be worth a look. Regards, Andreas ___ 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 -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 171 8334920 -http://www.cardcontact.de ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Do not hardcode 3F005015
Dear Andreas, it is not uncommon to place two application DF on the card, one for electronic signatures based on a qualified certificate and one for signatures, authentication and encryption using a non-qualified certificate. The main reason for doing this in separate applications is, that the application for secure signatures based on a qualified certificate usually needs a security evaluation according to some national law or the European signature directive, while the other does not. Most card suppliers have such an evaluated standard signature application (mostly based on DIN 66291 or CWA14890/eSignK), making it easy for certification authorities to integrate their card. However, most users also want to use the same card for electronic signatures based on a non-qualified certificate. These applications are then commonly used for client/server authentication, message integrity and encryption. I guess a good example is the upcoming German health insurance card and the health professional card. Both have separate applications, one for electronic signatures based on a qualified certificate (DF_QES) and one for simple signatures, client/server authentication and encryption (EF_ESIGN). The Austrian e-card is build in a similar way. In an ideal world, all applications on a card would be listed in the EF_DIR and each application would have it's own PKCS#15/ISO 7816-15 meta-data to describe it's keys, pins and data objects. A generic middleware like OpenSC could then use this meta-data and offer objects on the card to higher application layers (e.g. though PKCS#11) - Unfortunately we are not living in an ideal world and card application designers still tend to ignore ISO 7816-15. Andreas Andreas Jellinghaus schrieb: Does anyone have a card with two confliciting applications? How common are cards with two applications? Why would anyone put two applications on one card? I'm scared we might fall for an overengineering trap here, so lets first see if there is a real world problem, and what the easiest solution to this is. I can understand that people might put a wallet and signature keys on the same card - even if I think that is not wise - but that shouldn't harm opensc - it could simply ignore the wallet which it can't use anyway. But why would someone put two application on a card both with keys for signing/encryption? ok, german qualified signature cards (at least mine) have three keys with different pin numbers, but it still is one application as far as I understand. why would anyone have two? and if so, why can't this be handled with a config file entry? sure, you wouldn't see the other app unless you knew about it and changed the config file. I don't know this whole topic well. if you tell me it is a real world problem for lots of people with cards in their hand, then lets fix it right away as good as possible. but if it is only a theoretical problem: please don't invest any work in it. for example in theory it might be possible to get a qualified signature card with official signed and blessed keys and certs and then also put your own private pkcs#15 structure on it side by side. in practice that is a scenario we do not need to support at all. my experience talking to users so far is already this: smart cards are already far to complex, and thats one of the reasons why people don't use them as much as they could (IMO should). lets not add complexity unless we are sure it is needed. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 171 8334920 -http://www.cardcontact.de ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
