OpenSC on Solaris

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

OpenSC on Solaris

Douglas E. Engert
Two problems with the OpenSC svn source from 08/08/2005 on Solaris 9.


(1) pkcs11-tool would crash while looking at attributes with
    debug level set to 4. Looks like pkcs11/debug.c needs "FALSE"

--- ./src/pkcs11/,debug.c Sun Aug  7 19:13:05 2005
+++ ./src/pkcs11/debug.c Tue Aug  9 14:58:09 2005
@@ -257,7 +257,7 @@
  memcpy(&value, ptr, count);
  if (value)
  return "TRUE";
- return FALSE;
+ return "FALSE";
  }

  return sc_pkcs11_print_value(NULL, ptr, count);


(2) Solaris 9 does not have stdint.h, but does have sys/type.h
     pkcs15-tool.c includes stdint.h  Configure could check
     for stdint.h. A temporary fix is below.

--- ./src/tools/,pkcs15-tool.c Sun Aug  7 19:13:04 2005
+++ ./src/tools/pkcs15-tool.c Mon Aug  8 15:42:55 2005
@@ -25,7 +25,11 @@
  #ifdef _WIN32
  typedef unsigned __int32 uint32_t;
  #else
+#ifdef __sparc__
+#include <sys/types.h>
+#else
  #include <stdint.h>
+#endif
  #endif
  #include <openssl/bn.h>
  #include <openssl/crypto.h>



--

  Douglas E. Engert  <[hidden email]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenSC on Solaris

Nils Larsch
Douglas E. Engert wrote:

> Two problems with the OpenSC svn source from 08/08/2005 on Solaris 9.
>
>
> (1) pkcs11-tool would crash while looking at attributes with
>    debug level set to 4. Looks like pkcs11/debug.c needs "FALSE"
>
> --- ./src/pkcs11/,debug.c    Sun Aug  7 19:13:05 2005
> +++ ./src/pkcs11/debug.c    Tue Aug  9 14:58:09 2005
> @@ -257,7 +257,7 @@
>          memcpy(&value, ptr, count);
>          if (value)
>              return "TRUE";
> -        return FALSE;
> +        return "FALSE";
>      }

yep, looks like a typo. strange that no one noticed this before ...

>
>      return sc_pkcs11_print_value(NULL, ptr, count);
>
>
> (2) Solaris 9 does not have stdint.h, but does have sys/type.h
>     pkcs15-tool.c includes stdint.h  Configure could check
>     for stdint.h. A temporary fix is below.
>
> --- ./src/tools/,pkcs15-tool.c    Sun Aug  7 19:13:04 2005
> +++ ./src/tools/pkcs15-tool.c    Mon Aug  8 15:42:55 2005
> @@ -25,7 +25,11 @@
>  #ifdef _WIN32
>  typedef unsigned __int32 uint32_t;
>  #else
> +#ifdef __sparc__
> +#include <sys/types.h>
> +#else
>  #include <stdint.h>
> +#endif
>  #endif
>  #include <openssl/bn.h>
>  #include <openssl/crypto.h>

I've included a check for stdint.h in configure. The question is what
we do if stdint.h doesn't exist. For now pkcs15-tool then includes
sys/types.h and hopes that uint32_t is defined there ...
Please test a new snapshot.

Thanks,
Nils
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenSC on Solaris

Ludovic Rousseau
On 09/08/05, Nils Larsch <[hidden email]> wrote:

> Douglas E. Engert wrote:
> > (2) Solaris 9 does not have stdint.h, but does have sys/type.h
> >     pkcs15-tool.c includes stdint.h  Configure could check
> >     for stdint.h. A temporary fix is below.
> > [...]
>
> I've included a check for stdint.h in configure. The question is what
> we do if stdint.h doesn't exist. For now pkcs15-tool then includes
> sys/types.h and hopes that uint32_t is defined there ...
> Please test a new snapshot.

I also had such a problem with pcsc-lite. I noticed that Debian
GNU/Linux (and I guess the other GNU based systems) and Solaris (it
was version 8) have /usr/include/inttypes.h

According to [1] it "should" be "portable". But I don't know what to
do if the file is not found.
Maybe /usr/include/inttypes.h is available on all the plateforms
supported by OpenSC? And if the file is not found we just stop the
configure script and ask the user to contact opensc-devel?

Bye,

[1] http://www.opengroup.org/onlinepubs/009695399/basedefs/inttypes.h.html
--
 Dr. Ludovic Rousseau
 For private mail use [hidden email] and not "big brother" Google
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

TCOS & Decrypt & padding

richter-5
Hi,

I have done some work with the goal to get a TCOS card which was either
written by Kobil SmartKey software or is a NetKey card with preinstalled
certificates, to work with strongswan ipsec.

I have it working, but there is one problem left, that is pkcs1 padding.

If I use the pkcs15-crypt -c and do the padding on my own everythings works.
If I use the --pkcs1 option to let the smartcard do the padding and supply
the raw data (16 Byte) as input, then it doesn't work.

I have verified in the debug output that the corect bytes are sent to the
card and also the tcos specs says that it supports pkcs1 padding during
decryption, it returns 6a87, which means missing data.

(Log of working and non working session see below)

Has anybody any experiences with TCOS & decryption & padding? Is it
supported at all or do just make a stupid mistake?

BTW: Strongswan uses the pkcs11 api, which seems to have the PKCS1_PAD flags
always set, so the smartcard decryption fail. For testing I have implemented
the pkcs1 padding in strongswan and changed the padding byte in card-tcos.c
from 81 to 02 (which means no padding) and then everything works as
expected.

I would be happy if this problem could be solved and I could supply it as a
patch to opensc and strongswan.

Gerald

with software padding -> ok

card.c:229:sc_transmit_apdu: called
card.c:196:sc_transceive: Sending 8 bytes (resp. 2 bytes):
00 22 C1 B8 03 84 01 83 ."......
card.c:249:sc_transmit_apdu: Received 0 bytes (SW1=90 SW2=00)
sec.c:67:sc_set_security_env: returning with: 0
sec.c:35:sc_decipher: called
card-tcos.c:713:tcos_decipher: called
card.c:229:sc_transmit_apdu: called
card.c:196:sc_transceive: Sending 135 bytes (resp. 260 bytes, sensitive):
00 2A 80 86 81 02 00 01 FF FF FF FF FF FF FF FF .*..............
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF 00 DC 64 9F D6 9C CC A3 AD FB 9B .......d........
9C FB 33 81 BC 43 80                            ..3..C.
card.c:249:sc_transmit_apdu: Received 128 bytes (SW1=90 SW2=00)
08 80 89 60 A4 ED C5 4A 73 CF 79 F9 87 7F 99 9F ......Js.y.....
00 95 9F 33 B7 47 C0 01 B7 E5 D7 7A 78 DB 58 AA ...3.G.....zx.X.
....


with padding on the smartcard -> fails

card.c:229:sc_transmit_apdu: called
card.c:196:sc_transceive: Sending 8 bytes (resp. 2 bytes):
00 22 C1 B8 03 84 01 83 ."......
card.c:249:sc_transmit_apdu: Received 0 bytes (SW1=90 SW2=00)
sec.c:67:sc_set_security_env: returning with: 0
sec.c:35:sc_decipher: called
card-tcos.c:713:tcos_decipher: called
card.c:229:sc_transmit_apdu: called
card.c:196:sc_transceive: Sending 23 bytes (resp. 260 bytes, sensitive):
00 2A 80 86 11 81 33 09 08 95 BB F7 4A CF 86 6F .*....3.....J..o
45 16 56 51 6D A0 10                            E.VQm..
card.c:249:sc_transmit_apdu: Received 0 bytes (SW1=6A SW2=87)
framework-pkcs15.c:1864:pkcs15_prkey_decrypt: Key unwrap/decryption
complete. Result -1205.
misc.c:79:sc_to_cryptoki_error: opensc error: Incorrect parameters in APDU
(-1205)
pkcs11-object.c:745:C_Decrypt: Decryption result was 5


---------------------------------------------------------------------------
Gerald Richter            ecos electronic communication services gmbh
IT-Securitylösungen * Webapplikationen mit Apache/Perl/mod_perl/Embperl

Post:       Tulpenstrasse 5          D-55276 Dienheim b. Mainz
E-Mail:     [hidden email]          Voice:   +49 6133 939-122
WWW:        http://www.ecos.de/      Fax:     +49 6133 939-333
---------------------------------------------------------------------------
ECOS BB-5000 Firewall- und IT-Security Appliance: www.bb-5000.info
---------------------------------------------------------------------------

 

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: TCOS & Decrypt & padding

Chaskiel Grundman-3
--On Wednesday, August 10, 2005 08:56:31 AM +0200 Gerald Richter
<[hidden email]> wrote:

>  have it working, but there is one problem left, that is pkcs1 padding.
>
> If I use the pkcs15-crypt -c and do the padding on my own everythings
> works. If I use the --pkcs1 option to let the smartcard do the padding
> and supply the raw data (16 Byte) as input, then it doesn't work.

Padding is for plaintext, not ciphertext. RSA ciphertext is always be the
same size as the RSA modulus.  I'm somewhat surprised that your "software
padded" ciphertext actually decrypts successfully. I suppose TCOS might
support raw RSA (which would "work", but the resulting plaintext would not
be meaningful.)

The padding you are adding appears to be BT01 padding, which is used for
signature operations, not encryption. Are you actually trying to perform a
signature operation and not a decryption? (If so, you should use
sc_pkcs15_compute_signature/pkcs15-crypt -s instead of
sc_pkcs15_decipher/pkcs15-crypt -c). Are you actually trying to perform rsa
encryption? (If so, you need to do that in software, after reading the
public key from the card. the card will not do the public key encryption
for you)



_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel

attachment0 (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OpenSC on Solaris

Nils Larsch
In reply to this post by Ludovic Rousseau
Ludovic Rousseau wrote:

> On 09/08/05, Nils Larsch <[hidden email]> wrote:
>
>>Douglas E. Engert wrote:
>>
>>>(2) Solaris 9 does not have stdint.h, but does have sys/type.h
>>>    pkcs15-tool.c includes stdint.h  Configure could check
>>>    for stdint.h. A temporary fix is below.
>>>[...]
>>
>>I've included a check for stdint.h in configure. The question is what
>>we do if stdint.h doesn't exist. For now pkcs15-tool then includes
>>sys/types.h and hopes that uint32_t is defined there ...
>>Please test a new snapshot.
>
>
> I also had such a problem with pcsc-lite. I noticed that Debian
> GNU/Linux (and I guess the other GNU based systems) and Solaris (it
> was version 8) have /usr/include/inttypes.h
>
> According to [1] it "should" be "portable". But I don't know what to
> do if the file is not found.
> Maybe /usr/include/inttypes.h is available on all the plateforms
> supported by OpenSC? And if the file is not found we just stop the
> configure script and ask the user to contact opensc-devel?

thanks for the hint. pkcs15-tool.c now uses inttypes.h and if it's not
available I've disable the code that needs it (plus a short warning
that one should contact the [hidden email], see commit
message).

Thanks,
Nils
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

RE: TCOS & Decrypt & padding

richter-5
In reply to this post by Chaskiel Grundman-3
Hi,

>
> Padding is for plaintext, not ciphertext. RSA ciphertext is
> always be the same size as the RSA modulus.  

That's what I thought also, but the code in tcos_decipher from card-tcos.c
(line 716, trunk version from yesterday) has:


        if (xdata->pad_flags & SC_ALGORITHM_RSA_PAD_PKCS1)
                pad_byte = 0x81;        /* pkcs1 padding */
        else
                pad_byte = 0x02;        /* no padding */

Which seems to conform to the TCOS 2.03 specs I have, but it doesn't work in
reality. If padding encyrpted text doesn't make sense, than I suggest to
remove this piece of code and use always

pad_byte = 0x02 ;


> I'm somewhat
> surprised that your "software padded" ciphertext actually
> decrypts successfully. I suppose TCOS might support raw RSA
> (which would "work", but the resulting plaintext would not be
> meaningful.)
>
> The padding you are adding appears to be BT01 padding, which
> is used for signature operations, not encryption. Are you
> actually trying to perform a signature operation and not a
> decryption?

Yes, you are right. My goal is ipsec authentication

> (If so, you should use
> sc_pkcs15_compute_signature/pkcs15-crypt -s instead of
> sc_pkcs15_decipher/pkcs15-crypt -c).

TCOS can only handle one key for signing and so normaly (for example on the
NetKey card from German Telcom), you have one offical key which is used for
signing and all other keys are marked for encryption only.

These addional keys, are the ones that needs to be used for VPN
authentication (and officaly dedicated to this purpose). So what I have done
is to patch strongswan, to do the signing which is needed for ipsec
authentication, via the C_Decrypt function (and do the padding in software),
in case the configured key is not able to sign.

That works as exptected as long as the pad_byte sent to the card is 0x02
(which means no padding).

So the question is can card-tcos.c changed as suggested above or does this
make trouble within other applications?

Gerald


_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

RE: TCOS & Decrypt & padding

Chaskiel Grundman-3
>         if (xdata->pad_flags & SC_ALGORITHM_RSA_PAD_PKCS1)
>                 pad_byte = 0x81;        /* pkcs1 padding */
>         else
>                 pad_byte = 0x02;        /* no padding */
>
> Which seems to conform to the TCOS 2.03 specs I have, but it doesn't
> work in reality.

What I presume this means (pad_byte == 0x81) is that it requests that the
card check for and strip off BT02 padding from the plaintext after
decryption (and fail the decryption operation if it isn't present). I
would certainly expect that to fail in your case. The only time that rsa
decryption and signing are identical is when you are performing the raw
rsa operation. Since it seems that tcos will perform the raw operation for
you, what you are attempting should be possible. Which pkcs11 mechanism
are you using? The one that corresponds to 'raw', unpadded RSA (and which
should cause sc_pkcs15_decipher to be called without
SC_ALGORITHM_RSA_PAD_PKCS1, which in turn should cause 0x2 to be passed
to the card) is CKM_RSA_X_509.


_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: TCOS & Decrypt & padding

Nils Larsch
In reply to this post by richter-5
Gerald Richter wrote:
...

>>I'm somewhat
>>surprised that your "software padded" ciphertext actually
>>decrypts successfully. I suppose TCOS might support raw RSA
>>(which would "work", but the resulting plaintext would not be
>>meaningful.)
>>
>>The padding you are adding appears to be BT01 padding, which
>>is used for signature operations, not encryption. Are you
>>actually trying to perform a signature operation and not a
>>decryption?
>
>
> Yes, you are right. My goal is ipsec authentication
>
>
>>(If so, you should use
>>sc_pkcs15_compute_signature/pkcs15-crypt -s instead of
>>sc_pkcs15_decipher/pkcs15-crypt -c).
>
>
> TCOS can only handle one key for signing and so normaly (for example on the
> NetKey card from German Telcom), you have one offical key which is used for
> signing and all other keys are marked for encryption only.

is the card a so-called netkey card or a blank tcos card you've
personalized ? In case it's a netkey card I'm somewhat surprised as
all keys have the sign key usage set in pkcs15-netkey.c .

Nils
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

RE: TCOS & Decrypt & padding

richter-5
>
> is the card a so-called netkey card or a blank tcos card
> you've personalized ?

I have tested both a pre initialzied Netkey card and a blank TCOS card that
was initialzied with Kobil SmartKey on Windows.

> In case it's a netkey card I'm somewhat
> surprised as all keys have the sign key usage set in pkcs15-netkey.c .
>

That is true, but does not work, because on the card itself (in prop_attr)
only the first certificate is marked as usable for signing, all other keys
are marked for encryption.

So the code in pkcs15-netkey.c should extented by assigning USAGE_SIGN only
when prop_attr & 8 is set. (I have tested it the card really refuses to sign
with the keys marked for encryption).

I have the tcos 2.03 spec here (in german) and it clearly states that tcos
can handle only one key for signing. (I can send you the pdf if you like).

Fortunately it does the right thing when you do the pkcs1 padding in
software and then let the card decrypt the result.

Gerald

P.S. I didn't realized this assignment of the key usage in the trunk version
until now, I will provide a patch later on to correct this, as stated above.



_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

RE: TCOS & Decrypt & padding

richter-5
In reply to this post by Chaskiel Grundman-3
>
> What I presume this means (pad_byte == 0x81) is that it
> requests that the card check for and strip off BT02 padding
> from the plaintext after decryption (and fail the decryption
> operation if it isn't present). I would certainly expect that
> to fail in your case. The only time that rsa decryption and
> signing are identical is when you are performing the raw rsa
> operation. Since it seems that tcos will perform the raw
> operation for you, what you are attempting should be
> possible. Which pkcs11 mechanism are you using? The one that
> corresponds to 'raw', unpadded RSA (and which should cause
> sc_pkcs15_decipher to be called without
> SC_ALGORITHM_RSA_PAD_PKCS1, which in turn should cause 0x2 to
> be passed to the card) is CKM_RSA_X_509.
>

Ok, this makes sense. I will test the CKM_RSA_X_509 later on.

Gerald


_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: TCOS & Decrypt & padding

Nils Larsch
In reply to this post by richter-5
Gerald Richter wrote:

>>is the card a so-called netkey card or a blank tcos card
>>you've personalized ?
>
>
> I have tested both a pre initialzied Netkey card and a blank TCOS card that
> was initialzied with Kobil SmartKey on Windows.
>
>
>>In case it's a netkey card I'm somewhat
>>surprised as all keys have the sign key usage set in pkcs15-netkey.c .
>>
>
>
> That is true, but does not work, because on the card itself (in prop_attr)
> only the first certificate is marked as usable for signing, all other keys
> are marked for encryption.
>
> So the code in pkcs15-netkey.c should extented by assigning USAGE_SIGN only
> when prop_attr & 8 is set. (I have tested it the card really refuses to sign
> with the keys marked for encryption).

could you please contact Peter Koch on this issue, I would like to know
if this is true for his cards as well

>
> I have the tcos 2.03 spec here (in german) and it clearly states that tcos
> can handle only one key for signing. (I can send you the pdf if you like).

please do so (off the list of course), I have a somewhat antique version
here. It would be interesting to know if this is a new restriction or if
it's true for all tcos versions.

>
> Fortunately it does the right thing when you do the pkcs1 padding in
> software and then let the card decrypt the result.

we could exchange the sign and decrypt operation for these keys ...

>
> Gerald
>
> P.S. I didn't realized this assignment of the key usage in the trunk version
> until now, I will provide a patch later on to correct this, as stated above.

please contact Peter as I don't want to disable something that works
for him.

Nils

PS: next time please use a new thread for new topic (this thread has
     nothing to do with building opensc on solaris).
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

RE: TCOS & Decrypt & padding

richter-5
In reply to this post by richter-5
> The one that corresponds to 'raw',
> > unpadded RSA (and which should cause sc_pkcs15_decipher to
> be called
> > without SC_ALGORITHM_RSA_PAD_PKCS1, which in turn should
> cause 0x2 to
> > be passed to the card) is CKM_RSA_X_509.
> >
>
> Ok, this makes sense. I will test the CKM_RSA_X_509 later on.
>

With CKM_RSA_X_509 it works!

Thanks

Gerald

 

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel