[opensc-devel] serialnumber

2011-09-08 Thread J.Witvliet
Hi all,

I'm realizing that I'm probably at the wrong list, but I guess I'll find here 
the largest population of smartcard users ;-)

We are using smartcards for setting up OpenVPN tunnels, which works quite nice.
However, I detect some strange behavior.

According to the openvpn-docu, (at the server-side) one of their environment 
variables, tls_id_0 should contain the hexadecimal value of the certificate.
In reality in contains completely other fields, like CN=, OU=, O= and C=.

First I check this with some of the developers of openVPN (JJK), and he said 
that it works with him correctly and could demonstrate it if needed.


Other possibility could be that I found another feature of our middleware.
Is there any tool to lookup the serialnumber of a certificate stored on a 
smartcard directly?
I know I can export the certificate manually and use openssl to analyse it, but 
can it be done with one of the pkcs* open opensc* tools?


Kind regards, Hans

__
Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet 
de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u 
verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat 
aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband 
houdt met risico's verbonden aan het elektronisch verzenden van berichten.

This message may contain information that is not intended for you. If you are 
not the addressee or if this message was sent to you by mistake, you are 
requested to inform the sender and delete the message. The State accepts no 
liability for damage of any kind resulting from the risks inherent in the 
electronic transmission of messages.
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel


Re: [opensc-devel] serialnumber

2011-09-08 Thread J.Witvliet
Typo, I meant tls_serial_0 instead of tls_id_0


-Original Message-
From: opensc-devel-boun...@lists.opensc-project.org 
[mailto:opensc-devel-boun...@lists.opensc-project.org] On Behalf Of 
j.witvl...@mindef.nl
Sent: Thursday, September 08, 2011 12:27 PM
To: opensc-devel@lists.opensc-project.org
Subject: [opensc-devel] serialnumber

Hi all,

I'm realizing that I'm probably at the wrong list, but I guess I'll find here 
the largest population of smartcard users ;-)

We are using smartcards for setting up OpenVPN tunnels, which works quite nice.
However, I detect some strange behavior.

According to the openvpn-docu, (at the server-side) one of their environment 
variables, tls_id_0 should contain the hexadecimal value of the certificate.
In reality in contains completely other fields, like CN=, OU=, O= and C=.

First I check this with some of the developers of openVPN (JJK), and he said 
that it works with him correctly and could demonstrate it if needed.


Other possibility could be that I found another feature of our middleware.
Is there any tool to lookup the serialnumber of a certificate stored on a 
smartcard directly?
I know I can export the certificate manually and use openssl to analyse it, but 
can it be done with one of the pkcs* open opensc* tools?


Kind regards, Hans

__
Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet 
de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u 
verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat 
aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband 
houdt met risico's verbonden aan het elektronisch verzenden van berichten.

This message may contain information that is not intended for you. If you are 
not the addressee or if this message was sent to you by mistake, you are 
requested to inform the sender and delete the message. The State accepts no 
liability for damage of any kind resulting from the risks inherent in the 
electronic transmission of messages.
___
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] serialnumber

2011-09-08 Thread Martin Paljak
Hello,

On Thu, Sep 8, 2011 at 13:27,  j.witvl...@mindef.nl wrote:
 According to the openvpn-docu, (at the server-side) one of their environment 
 variables, tls_id_0 should contain the hexadecimal value of the certificate.
 In reality in contains completely other fields, like CN=, OU=, O= and C=.

I guess the tls_id_0 should contain exactly this, the subject of the
certificate?

 Is there any tool to lookup the serialnumber of a certificate stored on a 
 smartcard directly?
 I know I can export the certificate manually and use openssl to analyse it, 
 but can it be done with one of the pkcs* open opensc* tools?

pkcs15-tool --read-certificate num | openssl x509 -text
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel


Re: [opensc-devel] serialnumber

2011-09-08 Thread J.Witvliet
-Original Message-
From: martin.pal...@gmail.com [mailto:martin.pal...@gmail.com] On Behalf Of 
Martin Paljak
Sent: Thursday, September 08, 2011 3:35 PM
To: Witvliet, J, CDC/IVENT/OPS/IS/HIN
Cc: opensc-devel@lists.opensc-project.org
Subject: Re: [opensc-devel] serialnumber

Hello,

On Thu, Sep 8, 2011 at 13:27,  j.witvl...@mindef.nl wrote:
 According to the openvpn-docu, (at the server-side) one of their environment 
 variables, tls_id_0 should contain the hexadecimal value of the certificate.
 In reality in contains completely other fields, like CN=, OU=, O= and C=.

I guess the tls_id_0 should contain exactly this, the subject of the
certificate?

 Is there any tool to lookup the serialnumber of a certificate stored on a 
 smartcard directly?
 I know I can export the certificate manually and use openssl to analyse it, 
 but can it be done with one of the pkcs* open opensc* tools?

pkcs15-tool --read-certificate num | openssl x509 -text

-Original Message-

Would like to try it, but the pkcs15-tool fails with unsupported card

With pkcs11-tool I hev to provide --module /usr/lib/libaetpkss.so.3.0 .
But pkcs15-tool does not have the --module option.


hw

__
Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet 
de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u 
verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat 
aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband 
houdt met risico's verbonden aan het elektronisch verzenden van berichten.

This message may contain information that is not intended for you. If you are 
not the addressee or if this message was sent to you by mistake, you are 
requested to inform the sender and delete the message. The State accepts no 
liability for damage of any kind resulting from the risks inherent in the 
electronic transmission of messages.
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel


Re: [opensc-devel] libp11 engine_pkcs11 support for ECDSA keys

2011-09-08 Thread Felipe Blauth
I've found where the problem is coming from. It is from OpenSSL's function *
o2i_ECPublicKey*, that is used to convert the  asn1 octet string from
PKCS#11 *CKA_EC_POINT* attribute to internal OpenSSL stuff. This function is
called, like you said, at the file src/p11_ec.c from function *
pkcs11_get_ec_private*().

I've used *pkcs11-spy*, and it ouputs the following when calling *
C_GetAttributeValue* with *CKA_EC_POINT* parameter from the public key
object:

84: C_GetAttributeValue
[in] hSession = 0x10002
[in] hObject = 0x3
[in] pTemplate[1]:
CKA_EC_POINT  requested with 136 buffer
[out] pTemplate[1]:
CKA_EC_POINT  [size : 0x88 (136)]
04818504 017C713A 5A1ECAB3 0F7B0C54 35099B53 9AC9740A ED157D70 577D9AA3
3BB11767 95F02C07 9683AEA0 2C32422D DC9C7C9E 3BB9952B 7D692047 2F8B75D0
A23BB5EF CC3E01BE 240FFAFD 64A2F090 D2E8556F C108D251 4C9AD53C 270BE2AD
CA829853 57D26AF3 A65806FD 82CE2011 58C02629 B8E90961 4C00887E DD4184C7
37CE192C 2AB5ED47
Returned:  0 CKR_OK

*ec_pointlen* variable is, therefore, set to 136 bytes. After calling *
o2i_ECPublicKey* OpenSSL puts the following error in its stack:
*error:10067066:elliptic curve routines:ec_GFp_simple_oct2point:invalid
encoding*

So we have some encoding problem. By the way, why we should increment the
pointer by 2 before calling *o2i_ECPublicKey**? *Like you did in the
following:
...
/* PKCS#11 returns ASN1 octstring*/
const unsigned char * a;
/* TODO we have asn1 octet string, need to strip off 04 len */
a = ec_point + 2;
o2i_ECPublicKey(ec, a, ec_pointlen-2);
...

2011/9/7 Douglas E. Engert deeng...@anl.gov



 On 9/6/2011 4:53 PM, Felipe Blauth wrote:

 I've tested your mods and they work well =). I can sign and verify with
 most EC keys (I've tested with p-192, p-224, p-384 and p-521). However I
 cannot load public keys when using p-521 curves. It
 seems that I can load the private key and sign, but the public key is not
 loaded.

 I confess that I didn't look much at engine_pkcs11 source code, but if you
 could give me some appointments I can try to fix that.


 It is not clear where the error could be, it could be in the actual
 encoding of the public key, or the ASN1 decoding or in in some size limit.
 All the other keys are a multiple of 8 bits. The 521 is not,
 and thus the asn1 octet would need an extra byte. Look at the
 libp11 src/p11_ec.c and pkcs11_get_ec_private() and the ec_pointlen
 variable.

 Do you have a dump of the public key?

 If you are using OpenSC's PKCS#11, you could turn on the OpenSC debug,
 by adding to the opensc.conf someting like:
  debug = 7;
  debug_file = /tmp/opensc-debug.log;

 You could use the OpenSC pkcs11-spy.so to trace the PKCS#11 calls,
 that should show the public key being transfered. This can
 work with any PKCS#11 module including the opensc-pkcs11.so

 Set the environment variables:

  export PKCS11SPY=/path/to/your/pkcs11**.module.sohttp://pkcs11.module.so
  export PKCS11SPY_OUTPUT=/tmp/tb.spy.**txt


 OpenSSL error is the following, after loading the key:
 error:10067066:elliptic curve routines:ec_GFp_simple_**oct2point:invalid
 encoding

 Regards,

 2011/8/13 Felipe Blauth f...@inf.ufsc.br mailto:f...@inf.ufsc.br


Thank you, I'll check it out.

2011/8/12 Douglas E. Engert deeng...@anl.gov mailto:deeng...@anl.gov
 


No it has not been incorporated because it requires an OpenSSL
internal header file ecs_locl.h, thus making it impractical to
compile in to any package.

This is a known bug:

http://rt.openssl.org/Ticket/**Display.html?id=2459user=**
 guestpass=guesthttp://rt.openssl.org/Ticket/Display.html?id=2459user=guestpass=guest
 http://rt.openssl.org/Ticket/**Display.html?id=2459user=**
 guestpass=guesthttp://rt.openssl.org/Ticket/Display.html?id=2459user=guestpass=guest
 


It also appeared on the OpenSSL mailing list.

The patch should still work. Please try it, and you can
also add comments to the OpenSSL bug report.


On 8/12/2011 2:12 PM, Felipe Blauth wrote:
  Hello.
 
  I've started using engine_pkcs11 to access PKCS #11 tokens from
 OpenSSL EVP_PKEY's trough ENGINE_load_key_type_key methods. It works
 very well with RSA keys, but it doesn't recognize
ECDSA keys.
 
  Searching trough the web, I've found that Douglas had a patch
 for it at http://www.mail-archive.com/**opensc-devel@lists.opensc-**
 project.org/msg07785.htmlhttp://www.mail-archive.com/opensc-devel@lists.opensc-project.org/msg07785.html
 .
 
  Was that ever incorporated? I couldn't find in the latest
 snapshots.
 
  Thank you very much.
 
  --
  Felipe Menegola Blauth
 
 
 
  __**_
  opensc-devel mailing list
  
 opensc-devel@lists.opensc-**project.orgopensc-devel@lists.opensc-project.orgmailto:
 

Re: [opensc-devel] libp11 engine_pkcs11 support for ECDSA keys

2011-09-08 Thread Douglas E. Engert

Try the attached patch. It compiles, but I have not tested it.

On 9/8/2011 11:48 AM, Felipe Blauth wrote:

I've found where the problem is coming from. It is from OpenSSL's function 
*o2i_ECPublicKey*, that is used to convert the  asn1 octet string from PKCS#11 
*CKA_EC_POINT* attribute to internal OpenSSL
stuff. This function is called, like you said, at the file src/p11_ec.c from 
function *pkcs11_get_ec_private*().

I've used *pkcs11-spy*, and it ouputs the following when calling 
*C_GetAttributeValue* with *CKA_EC_POINT* parameter from the public key object:

84: C_GetAttributeValue
[in] hSession = 0x10002
[in] hObject = 0x3
[in] pTemplate[1]:
 CKA_EC_POINT  requested with 136 buffer
[out] pTemplate[1]:
 CKA_EC_POINT  [size : 0x88 (136)]
 04818504 017C713A 5A1ECAB3 0F7B0C54 35099B53 9AC9740A ED157D70 577D9AA3
 3BB11767 95F02C07 9683AEA0 2C32422D DC9C7C9E 3BB9952B 7D692047 2F8B75D0
 A23BB5EF CC3E01BE 240FFAFD 64A2F090 D2E8556F C108D251 4C9AD53C 270BE2AD
 CA829853 57D26AF3 A65806FD 82CE2011 58C02629 B8E90961 4C00887E DD4184C7
 37CE192C 2AB5ED47
Returned:  0 CKR_OK

*ec_pointlen* variable is, therefore, set to 136 bytes. After calling 
*o2i_ECPublicKey* OpenSSL puts the following error in its stack:
*error:10067066:elliptic curve routines:ec_GFp_simple_oct2point:invalid 
encoding*

So we have some encoding problem. By the way, why we should increment the 
pointer by 2 before calling *o2i_ECPublicKey**? *Like you did in the following:
...


Because the PKCS#11 returns the point as an octet_string, but OpenSSL does not 
want the octet_string
for the o2i_ECPublicKey. All my testing was done with named cureves of 256, or 
384,
and the ans1 header was always 2 bytes. The TODO comment was to come back in 
fix this.
Hopfuly the patch will.


/* PKCS#11 returns ASN1 octstring*/
const unsigned char * a;
/* TODO we have asn1 octet string, need to strip off 04 len */
a = ec_point + 2;
o2i_ECPublicKey(ec, a, ec_pointlen-2);
...

2011/9/7 Douglas E. Engert deeng...@anl.gov mailto:deeng...@anl.gov



On 9/6/2011 4:53 PM, Felipe Blauth wrote:

I've tested your mods and they work well =). I can sign and verify with 
most EC keys (I've tested with p-192, p-224, p-384 and p-521). However I cannot 
load public keys when using p-521 curves. It
seems that I can load the private key and sign, but the public key is 
not loaded.

I confess that I didn't look much at engine_pkcs11 source code, but if 
you could give me some appointments I can try to fix that.


It is not clear where the error could be, it could be in the actual
encoding of the public key, or the ASN1 decoding or in in some size limit.
All the other keys are a multiple of 8 bits. The 521 is not,
and thus the asn1 octet would need an extra byte. Look at the
libp11 src/p11_ec.c and pkcs11_get_ec_private() and the ec_pointlen
variable.

Do you have a dump of the public key?

If you are using OpenSC's PKCS#11, you could turn on the OpenSC debug,
by adding to the opensc.conf someting like:
  debug = 7;
  debug_file = /tmp/opensc-debug.log;

You could use the OpenSC pkcs11-spy.so to trace the PKCS#11 calls,
that should show the public key being transfered. This can
work with any PKCS#11 module including the opensc-pkcs11.so

Set the environment variables:

  export PKCS11SPY=/path/to/your/pkcs11__.module.so 
http://pkcs11.module.so
  export PKCS11SPY_OUTPUT=/tmp/tb.spy.__txt


OpenSSL error is the following, after loading the key:
error:10067066:elliptic curve 
routines:ec_GFp_simple___oct2point:invalid encoding

Regards,

2011/8/13 Felipe Blauth f...@inf.ufsc.br mailto:f...@inf.ufsc.br 
mailto:f...@inf.ufsc.br mailto:f...@inf.ufsc.br


Thank you, I'll check it out.

2011/8/12 Douglas E. Engert deeng...@anl.gov mailto:deeng...@anl.gov 
mailto:deeng...@anl.gov mailto:deeng...@anl.gov


No it has not been incorporated because it requires an OpenSSL
internal header file ecs_locl.h, thus making it impractical to
compile in to any package.

This is a known bug:

http://rt.openssl.org/Ticket/__Display.html?id=2459user=__guestpass=guest 
http://rt.openssl.org/Ticket/Display.html?id=2459user=guestpass=guest
http://rt.openssl.org/Ticket/__Display.html?id=2459user=__guestpass=guest 
http://rt.openssl.org/Ticket/Display.html?id=2459user=guestpass=guest


It also appeared on the OpenSSL mailing list.

The patch should still work. Please try it, and you can
also add comments to the OpenSSL bug report.


On 8/12/2011 2:12 PM, Felipe Blauth wrote:
  Hello.
 
  I've started using engine_pkcs11 to access PKCS #11 tokens from OpenSSL EVP_PKEY's 
trough ENGINE_load_key_type_key methods. It works very well with RSA keys, but 
it 

Re: [opensc-devel] ECDSA cards

2011-09-08 Thread Nikos Mavrogiannopoulos
On 09/06/2011 03:38 PM, Martin Paljak wrote:

   I'm trying to use the opensc 0.12.x ECDSA support, to allow ECDSA
 signing in gnutls via PKCS #11. However I have no such cards to test it.
 Do you have any suggestion on which card to use? (My only requirement is
 that it must be obtainable without placing a mass order)
 This is a difficult requirement. I'm not aware of any, except for a
 PIV card that might work but that's not available any more from
 smartcarfocus.com from where I got one. In fact, it seems that even
 decent java cards is a rarity these days...

Pretty strange. I couldn't find any elliptic curve supporting smart card 
on the market. I'd expect them to be more widespread due to their 
smaller memory requirements than rsa.

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel