Re: [opensc-devel] Segmentation fault in pkcs11-tool

[Anthony Foiani]

Anna, greetings --

On Mon, Dec 17, 2012 at 10:37 AM, Anna Pavlova
 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

[Anthony Foiani]

Frank, greetings --

On Mon, Dec 10, 2012 at 12:23 AM, Frank Morgner
 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

[Anthony Foiani]

Ludovic, greetings --

On Sun, Dec 9, 2012 at 7:19 AM, Ludovic Rousseau
 wrote:
>
> 2012/12/8 Anthony Foiani :
> > 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] how to obtain an sc_profile pointer (in pkcs15-tool)?

[Anthony Foiani]

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

[opensc-devel] Fwd: inconsistency between pkcs11-tool and pkcs15-tool

[Anthony Foiani]

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 
Date: Sat, Dec 8, 2012 at 1:34 PM
Subject: Re: inconsistency between pkcs11-tool and pkcs15-tool
To: Andreas Schwier 


Andreas --

I must say, your customer support hours are impressive.  :)

On Sat, Dec 8, 2012 at 7:31 AM, Andreas Schwier
 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] a few more trivial patches

[Anthony Foiani]

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] inconsistency between pkcs11-tool and pkcs15-tool

[Anthony Foiani]

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

Re: [opensc-devel] minimal requirements for working with crypto tokens?

[Anthony Foiani]

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
 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?

[Anthony Foiani]

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

[Anthony Foiani]

Andreas --

On Sun, Nov 11, 2012 at 6:31 AM, Andreas Schwier
 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] two trivial patches for opensc

[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

Re: [opensc-devel] obtaining a CSR for a token-generated (and locked-on-token) keypair

[Anthony Foiani]

Nikos --

Thanks for the quick reply!

On Sun, Nov 11, 2012 at 12:42 PM, Nikos Mavrogiannopoulos
 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

Re: [opensc-devel] obtaining a CSR for a token-generated (and locked-on-token) keypair

[Anthony Foiani]

Andreas --

Many thanks for the very quick response!

On Sun, Nov 11, 2012 at 6:31 AM, Andreas Schwier
 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

[opensc-devel] obtaining a CSR for a token-generated (and locked-on-token) keypair

[Anthony Foiani]

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?

[Anthony Foiani]

Andreas, greetings --

On Mon, Feb 27, 2012 at 12:54 PM, Andreas Kroehnert
 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

Re: [opensc-devel] OpenSC support for iKey4000?

[Anthony Foiani]

Andy, Ludovic --

On Mon, Feb 27, 2012 at 11:15 AM, Ludovic Rousseau
 wrote:
> Le 27 février 2012 18:46, Anthony Foiani  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?

[Anthony Foiani]

Ludovic --

On Mon, Feb 27, 2012 at 12:49 AM, Ludovic Rousseau
 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?

[Anthony Foiani]

Andy --

On Sun, Feb 26, 2012 at 5:15 PM, Andy Walls  wrote:
>
> I added basic support for the embedded "card reader" but did nothing for the 
> actual embedded "smart card".  I got very busy and didn't have time to pursue 
> it.

Understood.  Thanks for the update!

> I will post a patch to the list in a day or so.

Great, thank you!

I did find someone else who seems to have made some progress:

http://blog.go-lan.net/openct-ikey-4000-driver/

Although it looks like the iKey4000 comes in two flavors, one that is
CCID-compliant, and one that isn't?

04B9:1206 - no CCID, not supported
04B9:1400 - CCID, supported by libccid?

(This is from http://wiki.debian.org/Smartcards )

There also seems to be one commercial outfit that offers such a
driver, but I wasn't able to read their web page very well (I don't
speak Czech, and the Google translate version is only somewhat
helpful):

http://www.dignita.cz/produkty/linux-driver-pro-ikey4000

Anyway.  Thanks again for any help you can offer.

Best regards,
Anthony Foiani
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel