Re: [opensc-devel] Segmentation fault in pkcs11-tool
Anna, greetings -- On Mon, Dec 17, 2012 at 10:37 AM, Anna Pavlova funny.sweet.naug...@gmail.com wrote: Unfortunately I'm not very good in gdb :-( anna@anna:~/OpenSC/src/tools$ export LD_LIBRARY_PATH=`ls ../*/.libs -d | tr '\012' :` anna@anna:~/OpenSC/src/tools$ cd .libs/ anna@anna:~/OpenSC/src/tools/. libs$ gdb 'pkcs11-tool --module /home/anna/PKCS11_Project/libPkcs11.so' the last command returns: pkcs11-tool --module /home/anna/PKCS11_Project/libPkcs11.so: No such file or directory. Of course, when I run only: anna@anna:~/OpenSC/src/tools/.libs$ gdb pkcs11-tool that one runs and I can run in debug mode, but I'm afraid that then I'm not loading my module. Do you know how can I run gdb and also use my own library? Sorry, I'm not really used to work with gdb :-( What should work is: 1. start gdb with just the executable name: $ gdb pkcs11-tool 2. Use the run command to start your program with the desired arguments. (gdb) run --module /home/anna/PKCS11_Project/libPkcs11.so More info: http://sourceware.org/gdb/current/onlinedocs/gdb/Starting.html#Starting Example: $ gdb /bin/echo GNU gdb (GDB) Fedora (7.4.50.20120120-52.fc17) Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-redhat-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /usr/bin/echo...(no debugging symbols found)...done. Missing separate debuginfos, use: debuginfo-install coreutils-8.15-8.fc17.x86_64 (gdb) run foo bar baz Starting program: /usr/bin/echo foo bar baz foo bar baz [Inferior 1 (process 9980) exited normally] (gdb) Hope this helps. Best regards, Anthony Foiani ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] a few more trivial patches
Frank, greetings -- On Mon, Dec 10, 2012 at 12:23 AM, Frank Morgner morg...@informatik.hu-berlin.de wrote: Your editor should be intelligent enough to guess the right settings. Why have the editor guess, when it could know the right answer? For vim I recently found this plugin http://www.vim.org/scripts/script.php?script_id=4251 There is a similar feature for emacs (c-guess and friends). I am impressed by their cleverness, but it seems better to specify than to guess (with the chance of guessing wrongly). And it's not just tabs-vs-spaces, but also a human judgement as to whether those tabs are intended to represent 4 spaces or 8. No good answers. I just offered the directory-wide settings for emacs as a way to reduce my pain, and possibly to avoid patch submissions with incorrect indentation. Anyway. If Ludovic doesn't want it around, then that's fine by me; I'll find another way to make sure that I use the correct style. :) Best regards, Anthony Foiani ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] a few more trivial patches
Ludovic, greetings -- On Sun, Dec 9, 2012 at 7:19 AM, Ludovic Rousseau ludovic.rouss...@gmail.com wrote: 2012/12/8 Anthony Foiani anthony.foi...@gmail.com: Greetings -- I have two small patches which you might want to consider integrating. (And given that I can't get git to do what I want, you probably want to just cherry-pick these, as I suspect I've completely destroyed my repo history...) You should rebase your patches above OpenSC/OpenSC master. Ok, but pardon my git ignorance: I thought that one should never rebase a tree that will be published and pulled from? Or only if it's published and someone tries to *base a new tree* off of it? https://github.com/tkil/OpenSC/commit/0c4a2e0c4063f31bc41c34e45869b9a9e7ca41d7 This uses dir local settings to configure Emacs indentation correctly. I don't think that an Emacs configuration file should be added to the OpenSC source code. Hm. Why not? It would ensure that emacs users have their style set appropriately for this project, and shouldn't affect anyone else in any way. In my own use case, I work on 3-4 projects in the same emacs session, and each one has different indentation settings. dir-local settings seem the easiest way to assign a style per directory (tree). You should keep this change in your own branch. And for my second question of git ignorance: how can I maintain my own branch, when merging upstream into a branch is discouraged? Or do I misunderstand the tone of the log comments when trying to check in such a merge? https://github.com/tkil/OpenSC/commit/599bd1e6c906af63eb379c866076f98a91654cb2 I spotted an inconsistency in how the option argument pointers were initialized; this fixes it (to make it more consistent). Not a bug but the code would be nicer. For whatever it's worth, my understanding is that uninitialized global variables are actually allocated as a part of program runtime, and are initialized to zero at that point. *Initialized* global variables, however, are stored in the binary itself, even if the initializer is zero. So as a matter of style, it might be better to leave all those pointers uninitialized. (This was a big stink on the linux-kernel mailing list a few years back.) On the other hand, I don't know if this behavior is true across all platforms, and the space/time cost in this case is trivial. Can you create a branch from OpenSC/OpenSC master with only this patch and ask for a Pull Request? I'll try. :) Every time I try to use git for anything fancier than an svn-replacement, I seem to get burned... In this case, it looks like I'll have to fork the OpenSC version (instead of the CardContact version), then branch in my new fork, commit this change, and then request a pull of my new branch on the new fork? (Not complaining about amount of work, just trying to make sure I have the flow correct.) Many thanks, Anthony Foiani ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] inconsistency between pkcs11-tool and pkcs15-tool
Greetings!
I'm experimenting with a CardContact HSM, and I'm finding some
peculiar results when trying to install multiple certificates on the
token. Loading three certificates onto the token seemed to work, but
when I went to remove them, things fell apart.
I think that the crux of the problem is that pkcs11-tool shows only one object:
$ tool=pkcs11-tool --module opensc-pkcs11.so --login --pin 648219
$ $tool -O
Using slot 1 with a present token (0x1)
Private Key Object; RSA
label: Foo2A
ID: 0f48886a19793c9e
Usage: decrypt, sign, unwrap
But the pkcs15-tool shows quite a few more:
$ pkcs15-tool -D
[...]
Private RSA Key [Foo2A]
Object Flags : [0x3], private, modifiable
Usage : [0x2E], decrypt, sign, signRecover, unwrap
Access Flags : [0x1D], sensitive, alwaysSensitive,
neverExtract, local
ModLength : 2048
Key ref: 1 (0x1)
Native : yes
Path : e82b0601040181c31f0201::
Auth ID: 01
ID : 0f48886a19793c9e
GUID : {be6fda39-699a-d073-68e5-9629a54eafff}
X.509 Certificate [Bar Intermediate Certificate (2013)]
Object Flags : [0x2], modifiable
Authority : no
Path : e82b0601040181c31f0201::ca01
ID : 02
GUID : {55f338e7-137c-67e9-a6db-9135ca0aa884}
X.509 Certificate [Certificate]
Object Flags : [0x2], modifiable
Authority : no
Path : e82b0601040181c31f0201::ca02
ID : 03
GUID : {f89468b8-6674-1c8a-b01e-1a244eaaaf54}
X.509 Certificate [Foo2A (2013)]
Object Flags : [0x2], modifiable
Authority : no
Path : e82b0601040181c31f0201::ca03
ID : 03
GUID : {f89468b8-6674-1c8a-b01e-1a244eaaaf54}
Encoded serial : 02 01 01
I tried modifying the tools, but I found myself in pkcs15-tool without
a way to discover the correct sc_profile object,...
Thanks
Tony
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] a few more trivial patches
Greetings -- I have two small patches which you might want to consider integrating. (And given that I can't get git to do what I want, you probably want to just cherry-pick these, as I suspect I've completely destroyed my repo history...) https://github.com/tkil/OpenSC/commit/0c4a2e0c4063f31bc41c34e45869b9a9e7ca41d7 This uses dir local settings to configure Emacs indentation correctly. https://github.com/tkil/OpenSC/commit/599bd1e6c906af63eb379c866076f98a91654cb2 I spotted an inconsistency in how the option argument pointers were initialized; this fixes it (to make it more consistent). Best Regards, Anthony Foiani ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Fwd: inconsistency between pkcs11-tool and pkcs15-tool
Greetings. Andreas is (obviously) helping me with this, but if anyone else has ideas about what's going on here, I would love to hear them. Many thanks, Tony -- Forwarded message -- From: Anthony Foiani anthony.foi...@gmail.com Date: Sat, Dec 8, 2012 at 1:34 PM Subject: Re: inconsistency between pkcs11-tool and pkcs15-tool To: Andreas Schwier andreas.schw...@cardcontact.de Andreas -- I must say, your customer support hours are impressive. :) On Sat, Dec 8, 2012 at 7:31 AM, Andreas Schwier andreas.schw...@cardcontact.de wrote: can you create a log using export OPENSC_DEBUG=9 ? Of which steps? Seems that the last two certificates are the same, at the least GUID is the same. Did you import certificates in DER encoding or PEM encoding ? They were in DER. Actual sequence of operations: 1. Use XCA to create key and certificate signing request. This had some issues as well: it would wait long enough for the creation to take place, but on the first try, it would give me an error. Second try gave me another error (because I used the same name as first key, and even though it wasn't shown in the XCA window, it was indeed on the key, so the error came when XCA tried to label the second key). Third try, with a different name, worked. 2. Use OpenSSL and my in-house CA to sign the CSR and create a cert. These were all in PEM format, so I transformed them using: for i in ca-2013 ca-root foo2a-2013 do openssl x509 -inform pem -in $i-cert.pem \ -outform der -out $i-cert.der done 3. Use pkcs11-tool to load them onto the token: tool=pkcs11-tool --module opensc-pkcs11.so --login --pin 648219 $tool --write-object ca-root-cert.der --id 1 --type cert \ --label 'Foiani CA Root Certificate' $tool --write-object ca-2013-cert.der --id 2 --type cert \ --label 'Foiani CA Intermediate Certificate (2013)' $tool --write-object foo2a-2013-cert.der --id 3 --type cert \ --label 'Foo2A (2013)' At that point, the list of objects on the token was: $tool -O Using slot 1 with a present token (0x1) Private Key Object; RSA label: Foo2A ID: 0f48886a19793c9e Usage: decrypt, sign, unwrap Certificate Object, type = X.509 cert label: Foiani CA Intermediate Certificate (2013) ID: 02 Public Key Object; RSA 2048 bits label: Foiani CA Intermediate Certificate (2013) ID: 02 Usage: encrypt, verify Certificate Object, type = X.509 cert label: Foiani CA Root Certificate ID: 01 Public Key Object; RSA 8192 bits label: Foiani CA Root Certificate ID: 01 Usage: encrypt, verify Certificate Object, type = X.509 cert label: Certificate ID: 03 Public Key Object; RSA 2048 bits label: Certificate ID: 03 Usage: encrypt, verify Certificate Object, type = X.509 cert label: Foo2A (2013) ID: 03 Public Key Object; RSA 2048 bits label: Foo2A (2013) ID: 03 Usage: encrypt, verify So there's already one problem, with multiple entries at id 03. I suspect that I want to start over with a fresh pkcs15-tool init, and see if I can get a working setup from there. Thanks to your help, though, I feel I'm getting very close. Best regards, Anthony Foiani ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] how to obtain an sc_profile pointer (in pkcs15-tool)?
Greetings. As a part of debugging my current issue, I was looking for a way to delete objects from a token. I didn't find one, so I thought I'd try to add it. I think that I got very close, but I was unable to determine how to retrieve the profile pointer. My efforts so far are here: https://github.com/tkil/OpenSC/tree/pkcs15-tool-add-del-path More specifically, I am trying to find the correct sc_profile * in function delete_path: https://github.com/tkil/OpenSC/blob/pkcs15-tool-add-del-path/src/tools/pkcs15-tool.c#L1385 Hopefully this will be unnecessary after we figure out how I'm abusing the tools to corrupt my token, but I thought that others might find it useful (if they can figure out the profile pointer business). Thanks again for the great library; hopefully this little contribution is helpful, and not creating more work for you all... Best regards, Anthony Foiani ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] minimal requirements for working with crypto tokens?
Ludovic -- Thank you for the quick and thorough response. My apologies that I wasn't able to reply sooner. On Thu, Dec 6, 2012 at 5:23 AM, Ludovic Rousseau ludovic.rouss...@gmail.com wrote: libusb (or udev but you do not use it) is used by pcscd to discover USB readers. libusb is used by libccid to access the USB readers. That makes sense. Thank you for making it clear. You can write your own simpler pcscd if you want. ... The question is: why would you change existing and working code? What I actually want to do is to limit the capabilities of the existing code; the question in my head is whether it's easier to rewrite, or if it's possible to configure (either compile or run time) the specific and limited behaviors I want. In particular: 1. Limit crypto tokens to exactly one USB port, instead of scanning all of them. The selection of USB port can change at runtime, though. 2. Get insertion / removal notifications fairly quickly, and in a fairly lightweight manner. the pkcs11- and pcks15-tool programs seem to be able to get status, so that's obviously doable with pcscd, so I'll have to investigate that. What is the problem with the existing programs? Deployment complexity, primarily. Having another program running is another program that I have to run a watchdog for, and restart upon failure, etc. This instrument has only one userspace process running; adding another one will actually increase the complexity quite a bit. Additionally, we're building the root image from scratch, so we also have to configure and cross-compile all necessary libraries and executables. The fewer of those we need, the better off we'll be. Regardless, thank you very much for the tips, and I'll investigate from here. Best regards, Anthony Foiani ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] minimal requirements for working with crypto tokens?
Greetings, all. As with a similar posted in the last day or two, I'm working deploying an embedded linux system, and I'm trying to figure out the smallest set of libraries that I need to do this. The desired use for tokens in the field is: 1. Sign binary blobs, generating a detached RFC5652 signature file from each data file. 2. (Eventually) for both client and server-side SSL handshaking. On a typical Linux workstation, I can do all this already, thanks to the developers here and on libusb, ccid, and pcsc-lite. Barring late-breaking changes, this functionality is already available in packages for the distribution I'm using here (Fedora 17). To test the latest and greatest, I had to build: libusb-1.0.9 pcsc-lite-1.8.6 ccid-1.4.8 openssl-1.0.1c libp11-0.2.8 opensc-0.13.0rc1-g2895729 (from CardContact) engine_pkcs11-0.1.8 Other than having to adjust the interprocess expectations of pcscd and its users, that also works fine. However, the embedded box is not running the typical workstation daemons. There's no udev at all; I'm handling the event stream directly within my application. (E.g., I'm receiving and handling USB mass storage device insertions / removals.) What I'm looking for is guidance on which libraries are required to do the work, if I can tell those libraries exactly which USB device to use, and only when there is something there to be used. Is libusb used only for discovery, or for access as well? Likewise, if there is only ever one process accessing the token (and I can guarantee that it's single-threaded access), then is pcscd necessary? Even further, if I know exactly which token will be used, is it possible and/or advisable to short-circuit the generic aspects of libpkcs11 and somehow use that token's driver directly? Either way, it seems that I'll still want to use OpenSSL libraries (or equiv, e.g., NSS) to do the ASN.1 streaming and on-cpu crypto ops. (This is the easiest part, as I already have OpenSSL in my build.) Are all these questions stupid, and do I need to be hit over the head with a heavy book? :) I'm still investigating, but if anyone has experience with this sort of setup, I would very much appreciate any advice they could share with me. Thanks for your time. Best regards, Anthony Foiani ___ 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
Andreas -- Many thanks for the very quick response! On Sun, Nov 11, 2012 at 6:31 AM, Andreas Schwier andreas.schw...@cardcontact.de wrote: In the current version of OpenSC, the CSR is not exposed at the interface, as PKCS#11 does not provide a mechanism to handle device generated certificate signing requests. In a later version we will try to make the CSR available as a session based data object. Ok, good to know I'm not going crazy. 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. That's where I was going next, although I'm having issues with openssl. I'll give it another shot later today. If you happen to have an example session that shows that sequence of activities, it would be very helpful. Thanks again! Best regards, Anthony Foiani ___ 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
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
[opensc-devel] two trivial patches for opensc
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
Re: [opensc-devel] obtaining a CSR for a token-generated (and locked-on-token) keypair
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 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] obtaining a CSR for a token-generated (and locked-on-token) keypair
Greetings.
I'm working with a CardContact HSM, and would like to generate a
keypair on the token, then get a certificate based on that key.
I'm using CardContact's branch of OpenSC
(https://github.com/CardContact/OpenSC rev a4c3d4ec2436) and openssl
1.0.1c; I'm currently experimenting on an up-to-date Fedora 17 x86-64
box, but am hoping to deploy portions of this toolchain onto an
embedded platform (linux ppc32).
Just in case, I updated to the latest releases of libp11 (0.2.8) and
engine_pkcs11 (0.1.8).
I can successfully generate the keypair and extract the public key at
the same time:
$ d=/usr/local/opensc
$ tool=$d/bin/pkcs11-tool --module $d/lib/opensc-pkcs11.so
$ $tool --login --pin 648219 \
--keypairgen --key-type rsa:2048 --id 10 \
--read-object --id 10 --type pubkey --output-file pub.spki
Using slot 1 with a present token (0x1)
Key pair generated:
Private Key Object; RSA
label: Private Key
ID: 10
Usage: decrypt, sign, unwrap
Public Key Object; RSA 2048 bits
label: Private Key
ID: 10
Usage: encrypt, verify, wrap
$ ls -al pub.spki
-rw-rw-r--. 1 tony tony 270 Nov 9 22:20 pub.spki
$ hexdump -C pub.spki
30 82 01 0a 02 82 01 01 00 95 42 87 7a 04 82 ab |0.B.z...|
0010 89 7f b2 07 9f 25 e3 c2 47 e7 0a 53 2e 8c a9 0b |.%..G..S|
...
00f0 71 a7 17 18 f6 69 99 eb 5d d1 cb 18 33 60 29 c0 |qi..]...3`).|
0100 c5 22 28 5b 31 7d 3e 6d 99 02 03 01 00 01|.([1}m..|
However, I haven't managed to find the right incantation to force
openssl to use the (available) public key, but to sign with the
private key on the token. I think I finally got the engine configured
correctly:
openssl_conf = openssl_def
[openssl_def]
engines = engine_section
[engine_section]
pkcs11 = pkcs11_section
[pkcs11_section]
engine_id = pkcs11
dynamic_path = /usr/local/lib/engines/engine_pkcs11.so
MODULE_PATH = /usr/local/lib/opensc-pkcs11.so
init = 0
But when I try to do the signing operation, it looks like openssl is
trying to read the private key off the token, instead of asking the
token to sign on the token:
LD_LIBRARY_PATH=/usr/local/lib:/usr/local/lib/engines \
/usr/local/bin/openssl req -verbose \
-config ./token.conf -engine pkcs11 \
-key slot_1-id_10 -keyform engine -out foo.req
Using configuration from ./token.conf
engine pkcs11 set.
PKCS#11 token PIN: 648219
PKCS11_get_private_key returned NULL
cannot load Private Key from engine
140416681797312:error:80028012:PKCS11
library:PKCS11_get_attribute:Attribute type invalid:p11_attr.c:53:
140416681797312:error:26096080:engine
routines:ENGINE_load_private_key:failed loading private
key:eng_pkey.c:126:
unable to load Private Key
On the wiki for the HSM
(http://www.opensc-project.org/opensc/wiki/SmartCardHsm#Generatekeypair),
there is a curious phrase:
The SmartCard-HSM does not permanently store public keys, but
generates the required PKCS#11 public key object from
certificates stored on the device. As newly generated key pairs
don't have a certificate initially, the public key is extracted
from the card generated certificate signing request instead and
made available for the duration of the session. To save the
generated public key in Subject Public Key Information format
as per RF3280 use the following command
If I'm reading that correctly, then it seems that the HSM is creating
a CSR internally -- but I don't see any way to retrieve that CSR (let
alone specify the typical certificate properties like email address,
DN, CN, etc.)
There's the moz-test flag to the pkcs11-tool, which invokes
test_kpgen_certwrite; this seems very close to what I'm trying to do
-- but it's not exposed 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
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC support for iKey4000?
Ludovic -- On Mon, Feb 27, 2012 at 12:49 AM, Ludovic Rousseau ludovic.rouss...@gmail.com wrote: The second one [04B9:1400] is listed in the Should work but untested by me CCID list http://pcsclite.alioth.debian.org/ccid/shouldwork.html#0x04B90x1400 So it should work out of the box with my CCID driver. That's fantastic. Now to see if there's an easy way to tell the difference between these two types of iKey4000... Thanks again! Best regards, Anthony Foiani ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC support for iKey4000?
Andy, Ludovic -- On Mon, Feb 27, 2012 at 11:15 AM, Ludovic Rousseau ludovic.rouss...@gmail.com wrote: Le 27 février 2012 18:46, Anthony Foiani anthony.foi...@gmail.com a écrit : Now to see if there's an easy way to tell the difference between these two types of iKey4000... You can use the lsusb command on GNU/Linux to display the USB Vendor ID and Product ID. But you need to _have_ the device first. So not really helpful if you want to by one, unless you are allowed to bring it back and get your money. The situation is actually a bit worse. I'm working with an organization that has already standardized on the iKey4000 and has already issued them and integrated them into other parts of their infrastructure. I do have a handful of samples, but if both types are already out in the field, then I need a solution that can accomodate both. :( I read that SafeNet was open to providing the necessary documentation under NDA; that might be one route. Someone else also mentioned that they have been able to communicate with an iKey4000, but it's not clear which variety they are using. Thanks very much for the help so far; I'll see what else I can find out. Best regards, Anthony Foiani ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC support for iKey4000?
Andreas, greetings -- On Mon, Feb 27, 2012 at 12:54 PM, Andreas Kroehnert akroehn...@go-lan.net wrote: Hi Anthony, I think its more beneficial to respond to this list, rather than just your comment you left on the blog. Of course. Thank you for replying so quickly and so thoroughly! The little OpenCT patch I've done was originally done for the standard ikey 4000 (04b9:1206). But should also work for the non-standard one (04b9:1400). I am not sure what to order at SafeNet to get the 1400 one, could be the old CIP initialised, kinda old-school version, but I am not sure. However all 4k tokens I've collected over the years, even the latest, come with a PID of 1206. (Which actually should be an ikey 2k series PID. To mess it up even more SafeNet now renamed/rebranded the ikey 4000 to eToken 5000) Yes, it's a mess. It seems that SafeNet has sold a few different combinations of reader+smartcard all under the iKey4000 name. Their NDA requirements might even be driven by the variety of suppliers... I just went through and checked my 6 samples: they're all 0x1206 variants. Back to topic: In general its claimed that regardless of the PID, the ikey4000 / SC400 is a CCID compliant device, but I never got it to work using libccid. While developing the first attempt of the patch I was confused why the ATR from the card contains a trailing byte before it continues with 0x3B... Might be that this is messing up the CCID compatibility. For the moment I've just chopped that first byte off and the card mostly responds as expected. It's also said that once the ATR has been sent the card shall behave according to PIV for most commands. I wasn't able to confirm that either as of now. Hm. Maybe these are enough hints for me to do some digging on my own. I won't be able to look at it in detail for a few weeks yet; I was sending out emails to try to get a sense of where the community stands regarding support for this token. So far I got some new commercial assignments, so I didn't have a chance to continue with the development. The next stage (as said in the blog) is to get OpenSC patched to support the card. Right. I'm looking forward to seeing your code, when you get the opportunity to rebuild that RAID... I am happy to provide the code I've done so far, unfortunately I've done it on a VM that is now on a crashed RAID, which I switched off to wait for replacement disks before I make any recovery attempts. Which should hopefully in the next few days. Ouch, sorry to hear about that. That never happens at a convenient time, does it... Thanks once again for your help! Best regards, Anthony Foiani ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
