Re: [opensc-devel] Supporting card Handelsbanken (SHB) BankID
On Tue, 21 Aug 2012, Linus Walleij wrote: When no certs are found, we get: card.c:322:sc_unlock: called iso7816.c:103:iso7816_check_sw: Instruction code not supported or invalid iso7816.c:471:iso7816_select_file: returning with: -1204 (Unsupported INS byte in APDU) Have you tried to make a USB level debug of the traffic with just the proprietary driver? Possibly the handshake is a low-level USB thing? I haven't tried repeating the trick with BankID for Linux yet. Apparently, only 32-bit Ubuntu is supported, but I use 64-bit CentOS. Another alternativ would be to find a usbmon alternative for Windows XP. Rgds, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://cendio.com Teknikringen 8 http://twitter.com/ThinLinc 583 30 Linköpinghttp://facebook.com/ThinLinc Phone: +46-13-214600http://plus.google.com/112509906846170010689___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] SOPIN and PUK in OpenSC
Hi,all I'm confused that while I run the CMD: pkcs15-init -C -p pkcs15 --pin 1234 --so-pin 123456 I won't wanna store a PUK. it returned : Failed to create PKCS #15 meta structure: Security status not satisfied and I run the CMD bellow without any errors: pkcs15-init -C -p pkcs15 --pin 1234 --puk 123456 --so-pin 123456 Q: 1. Does it must contain a PUK in each smart card or a special manufacturer‘s card ? 2. Is it just related to the xx.profile file for each manufacturer in source code ? ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Supporting card Handelsbanken (SHB) BankID
Peter Åstrand wrote: proprietary BankID application I suggest to try https://fribid.se/ out. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] SOPIN and PUK in OpenSC
Le mercredi 22 août 2012 à 14:37 +0800, Grey0502 a écrit : I'm confused that while I run the CMD: pkcs15-init -C -p pkcs15 --pin 1234 --so-pin 123456 I won't wanna store a PUK. it returned : Failed to create PKCS #15 meta structure: Security status not satisfied What is your token? OS? Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu smime.p7s Description: S/MIME cryptographic signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Minidriver assume hexstring encoding for card serial number
Hi everyone, we've come across an issue with the minidriver which assumes the card serial number to be a hex string. In our card the serial number is a string composed of ASCII characters. This works well with pkcs15-tool and the PKCS#11 library, however it fails with the current minidriver when it tries to convert the hex string into binary data for the cardid file. Neither in PKCS#11 spec nor in ISO 7816-15 I can find a definition for encoding the serial number as hex string. I therefore propose to change the code in minidriver.c to do the following: 1. try parsing tokeninfo-serial_number as hex string 2. if that fails copy serial_number as is with the length being the length of the ASCII encoded string This should not interfere with current card drivers which all use a hex string as serial number. Any objections ? Andreas -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 171 8334920 -http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] C_GetSlotList() returns 0 slots in Linux?
I have a Linux user that I'm trying to get working with OpenSC. However, according to my logs, C_GetSlotList() is finding 0 slots. I'm unable to reproduce this problem on my own Linux box. The user claims the smart card reader is plugged in and working properly in Firefox/Thunderbird: Bus 004 Device 012: ID 058f:9540 Alcor Micro Corp. In Firefox´s Device Manager: Security Modules and Devices: PKCS11 Module PKCS11 Path /usr/lib/opensc-pkcs11.so The user's pcsc_scan output is as follows: ~$ pcsc_scan PC/SC device scanner V 1.4.18 (c) 2001-2011, Ludovic Rousseau ludovic.rouss...@free.fr Compiled with PC/SC lite version: 1.7.4 Using reader plug'n play mechanism Scanning present readers... 0: Alcor Micro AU9540 00 00 Tue Aug 21 16:05:52 2012 Reader 0: Alcor Micro AU9540 00 00 Card state: Card inserted, Shared Mode, ATR: 3B 7F 38 00 00 00 6A 44 4E 49 65 10 02 4C 34 01 13 03 90 00 ATR: 3B 7F 38 00 00 00 6A 44 4E 49 65 10 02 4C 34 01 13 03 90 00 + TS = 3B -- Direct Convention + T0 = 7F, Y(1): 0111, K: 15 (historical bytes) TA(1) = 38 -- Fi=744, Di=12, 62 cycles/ETU 64516 bits/s at 4 MHz, fMax for Fi = 8 MHz = 129032 bits/s TB(1) = 00 -- VPP is not electrically connected TC(1) = 00 -- Extra guard time: 0 + Historical bytes: 00 6A 44 4E 49 65 10 02 4C 34 01 13 03 90 00 Category indicator byte: 00 (compact TLV data object) Tag: 6, len: A (pre-issuing data) Data: 44 4E 49 65 10 02 4C 34 01 13 Mandatory status indicator (3 last bytes) LCS (life card cycle): 03 (Initialisation state) SW: 9000 (Normal processing.) Possibly identified card (using /usr/share/pcsc/smartcard_list.txt): 3B 7F 38 00 00 00 6A 44 4E 49 65 10 02 4C 34 01 13 03 90 00 3B 7F 38 00 00 00 6A 44 4E 49 65 [1,2]0 02 4C 34 01 13 03 90 00 DNI electronico (Spanish electronic ID card) http://www.dnielectronico.es If anyone has any ideas on further debugging, please let me know, as I'm not sure where to take it next. -- View this message in context: http://old.nabble.com/C_GetSlotList%28%29-returns-0-slots-in-Linux--tp34334480p34334480.html Sent from the OpenSC - Dev mailing list archive at Nabble.com. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] C_GetSlotList() returns 0 slots in Linux?
I have a Linux user that I'm trying to get working with OpenSC. However, according to my logs, C_GetSlotList() is finding 0 slots. I'm unable to reproduce this problem on my own Linux box. The user claims the smart card reader is plugged in and working properly in Firefox/Thunderbird: Bus 004 Device 012: ID 058f:9540 Alcor Micro Corp. In Firefox´s Device Manager: Security Modules and Devices: PKCS11 Module PKCS11 Path /usr/lib/opensc-pkcs11.so The user's pcsc_scan output is as follows: ~$ pcsc_scan PC/SC device scanner V 1.4.18 (c) 2001-2011, Ludovic Rousseau ludovic.rouss...@free.fr Compiled with PC/SC lite version: 1.7.4 Using reader plug'n play mechanism Scanning present readers... 0: Alcor Micro AU9540 00 00 Tue Aug 21 16:05:52 2012 Reader 0: Alcor Micro AU9540 00 00 Card state: Card inserted, Shared Mode, ATR: 3B 7F 38 00 00 00 6A 44 4E 49 65 10 02 4C 34 01 13 03 90 00 ATR: 3B 7F 38 00 00 00 6A 44 4E 49 65 10 02 4C 34 01 13 03 90 00 + TS = 3B -- Direct Convention + T0 = 7F, Y(1): 0111, K: 15 (historical bytes) TA(1) = 38 -- Fi=744, Di=12, 62 cycles/ETU 64516 bits/s at 4 MHz, fMax for Fi = 8 MHz = 129032 bits/s TB(1) = 00 -- VPP is not electrically connected TC(1) = 00 -- Extra guard time: 0 + Historical bytes: 00 6A 44 4E 49 65 10 02 4C 34 01 13 03 90 00 Category indicator byte: 00 (compact TLV data object) Tag: 6, len: A (pre-issuing data) Data: 44 4E 49 65 10 02 4C 34 01 13 Mandatory status indicator (3 last bytes) LCS (life card cycle): 03 (Initialisation state) SW: 9000 (Normal processing.) Possibly identified card (using /usr/share/pcsc/smartcard_list.txt): 3B 7F 38 00 00 00 6A 44 4E 49 65 10 02 4C 34 01 13 03 90 00 3B 7F 38 00 00 00 6A 44 4E 49 65 [1,2]0 02 4C 34 01 13 03 90 00 DNI electronico (Spanish electronic ID card) http://www.dnielectronico.es If anyone has any ideas on further debugging, please let me know, as I'm not sure where to take it next. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Minidriver assume hexstring encoding for card serial number
On 8/22/2012 5:28 AM, Andreas Schwier (ML) wrote:
Hi everyone,
we've come across an issue with the minidriver which assumes the card
serial number to be a hex string.
In our card the serial number is a string composed of ASCII characters.
This works well with pkcs15-tool and the PKCS#11 library, however it
fails with the current minidriver when it tries to convert the hex
string into binary data for the cardid file.
Neither in PKCS#11 spec nor in ISO 7816-15 I can find a definition for
encoding the serial number as hex string.
The minidriver does not use the PKCS#11 standards, it is the Microsoft
definition of what it expects in the cardid file that counts.
http://www.microsoft.com/whdc/device/input/smartcard/sc-minidriver.mspx
Section 5.4.1 says:
The logical name for this file is “CardId”. It is in the root directory.
The file is organized as a 16-byte array. It should be treated as opaque
binary data.
This value is assigned by Microsoft software to assure that a unique value is
generated for the card. It is unrelated to the serial number that may or may
not
be assigned to the card during manufacture.
In other places it calls it as a GUID.
This also means that when displayed, it maybe displayed as a GUID as hex digits
with {, } , and - added for readability, and some bytes reversed in
little
endian machines. So it may not be recognizable as your serial number.
That said, since the minidriver is emulating a card that should have a cardid
file,
the data to populate the emulated cardid file has to come from the card and be
the same
at every use, and unique across all cards not just one site or one card vendor.
The value or its derivatives are stored in the certificate store and used
to associate cards with data previously cached.
I therefore propose to change the code in minidriver.c to do the following:
1. try parsing tokeninfo-serial_number as hex string
2. if that fails copy serial_number as is with the length being the
length of the ASCII encoded string
It must be 16 bytes.
This should not interfere with current card drivers which all use a hex
string as serial number.
Any objections ?
If you can show that your method has enough uniqueness, to not cause problems
with other cards, then no.
Andreas
--
Douglas E. Engert deeng...@anl.gov
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] encrypt / decrypt
Hi all, I've been trying to make more use of our smartcards, but I think I am missing the point some how. What I would like to do is: a) encrypt some data, by means of one of my private keys on my smartcard someone else should be able to decrypt it with the public key on my certificate. b) let someone else encrypt some data, by means of my public key on my certificate. I should be able to decrypt it with one of my private keys on my smartcard. I speak in plural about keys/certificates, cause we have different pairs for authentication/non-repodiation/etc So first I load the engine: OpenSSL engine dynamic -pre SO_PATH:/usr/lib/engines/engine_pkcs11.so -pre ID:pkcs11 -pre LIST_ADD:1 -pre LOAD -pre MODULE_PATH:/usr/lib/libaetpkss.so.3.0 (dynamic) Dynamic engine loading support [Success]: SO_PATH:/usr/lib/engines/engine_pkcs11.so [Success]: ID:pkcs11 [Success]: LIST_ADD:1 [Success]: LOAD [Success]: MODULE_PATH:/usr/lib/libaetpkss.so.3.0 Loaded: (pkcs11) pkcs11 engine OpenSSL And next I try to encrypt something: OpenSSL OpenSSL enc -base64 -in /root/data.txt -out file.txt.enc -engine pkcs11 engine pkcs11 set. OpenSSL OpenSSL enc -d -aes-256-cbc -a -in file.txt.enc -engine pkcs11 engine pkcs11 set. enter aes-256-cbc decryption password: error in enc OpenSSL I presume, I'll have to specify which private-key (and PIN), although -k 41 or -k 43 does not work either, neither does -key id_43 Am I missing something, or is this just not possible? 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] Minidriver assume hexstring encoding for card serial number
Hi Douglas,
thanks for your infos.
The minidriver.c already ensures that the cardid file is always 16 byte.
It does this by repeating the token serial number until 16 bytes are filled.
We can ensure uniqueness of the serial number for our cards, but no
uniqueness among all other card vendors. There remains a (very) little
probability that a hexadecimal encoded serial number of another vendor's
card resembles one of our ASCII serial numbers.
Our serial numbers are based on the numbering scheme for machine
readable travel documents, a 2 digit country code followed by up to 9
ASCII digits (e.g. UTTM1234567 equals 5554544D313233343536375554544D31
in cardid).
Our proposed change (see [1]) will not alter the current behaviour with
existing cards. It will just allow a card that uses a ASCII serial
number to work as well.
An alternative approach - and probably more invasive - would be to use
the result of SC_CARDCTL_GET_SERIALNR in minidriver.c as input for the
cardid file. This way we could still have our human readable serial
number at the PKCS#11 und PKCS#15 level and a little more uniqueness in
the cardid file. This will however break existing installations, as the
content of the cardid file might change with the driver update.
Andreas
[1]
https://github.com/CardContact/OpenSC/commit/724cdd06e23ecd2e822bd1f138d9c3fbdafe9324
Am 22.08.2012 16:29, schrieb Douglas E. Engert:
On 8/22/2012 5:28 AM, Andreas Schwier (ML) wrote:
Hi everyone,
we've come across an issue with the minidriver which assumes the card
serial number to be a hex string.
In our card the serial number is a string composed of ASCII characters.
This works well with pkcs15-tool and the PKCS#11 library, however it
fails with the current minidriver when it tries to convert the hex
string into binary data for the cardid file.
Neither in PKCS#11 spec nor in ISO 7816-15 I can find a definition for
encoding the serial number as hex string.
The minidriver does not use the PKCS#11 standards, it is the Microsoft
definition of what it expects in the cardid file that counts.
http://www.microsoft.com/whdc/device/input/smartcard/sc-minidriver.mspx
Section 5.4.1 says:
The logical name for this file is “CardId”. It is in the root directory.
The file is organized as a 16-byte array. It should be treated as opaque
binary data.
This value is assigned by Microsoft software to assure that a unique value
is
generated for the card. It is unrelated to the serial number that may or
may not
be assigned to the card during manufacture.
In other places it calls it as a GUID.
This also means that when displayed, it maybe displayed as a GUID as hex
digits
with {, } , and - added for readability, and some bytes reversed in
little
endian machines. So it may not be recognizable as your serial number.
That said, since the minidriver is emulating a card that should have a cardid
file,
the data to populate the emulated cardid file has to come from the card and
be the same
at every use, and unique across all cards not just one site or one card
vendor.
The value or its derivatives are stored in the certificate store and used
to associate cards with data previously cached.
I therefore propose to change the code in minidriver.c to do the following:
1. try parsing tokeninfo-serial_number as hex string
2. if that fails copy serial_number as is with the length being the
length of the ASCII encoded string
It must be 16 bytes.
This should not interfere with current card drivers which all use a hex
string as serial number.
Any objections ?
If you can show that your method has enough uniqueness, to not cause problems
with other cards, then no.
Andreas
--
-CardContact Software System Consulting
|.## ##.| Andreas Schwier
|# #| Schülerweg 38
|# #| 32429 Minden, Germany
|'## ##'| Phone +49 171 8334920
-http://www.cardcontact.de
http://www.tscons.de
http://www.openscdp.org
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] encrypt / decrypt
On 8/22/2012 9:50 AM, j.witvl...@mindef.nl wrote: Hi all, I've been trying to make more use of our smartcards, but I think I am missing the point some how. What I would like to do is: a) encrypt some data, by means of one of my private keys on my smartcard someone else should be able to decrypt it with the public key on my certificate. b) let someone else encrypt some data, by means of my public key on my certificate. I should be able to decrypt it with one of my private keys on my smartcard. I speak in plural about keys/certificates, cause we have different pairs for authentication/non-repodiation/etc So first I load the engine: OpenSSL engine dynamic -pre SO_PATH:/usr/lib/engines/engine_pkcs11.so -pre ID:pkcs11 -pre LIST_ADD:1 -pre LOAD -pre MODULE_PATH:/usr/lib/libaetpkss.so.3.0 (dynamic) Dynamic engine loading support [Success]: SO_PATH:/usr/lib/engines/engine_pkcs11.so [Success]: ID:pkcs11 [Success]: LIST_ADD:1 [Success]: LOAD [Success]: MODULE_PATH:/usr/lib/libaetpkss.so.3.0 Loaded: (pkcs11) pkcs11 engine OpenSSL And next I try to encrypt something: OpenSSL OpenSSL enc -base64 -in /root/data.txt -out file.txt.enc -engine pkcs11 engine pkcs11 set. OpenSSL OpenSSL enc -d -aes-256-cbc -a -in file.txt.enc -engine pkcs11 engine pkcs11 set. enter aes-256-cbc decryption password: error in enc OpenSSL I presume, I'll have to specify which private-key (and PIN), although -k 41 or -k 43 does not work either, neither does -key id_43 Am I missing something, or is this just not possible? Yes you are missing something. Because asymmetric key encryption like RSA is slow and the amount of data that can be encrypted is limited, what is usually done is to encrypt the data in a symmetric key, like AES, then encrypt the AES key using the RSA public key. the encrypted data and the encrypted key are then sent, and the process is reversed using the RSA private key. This packaging of the message is usually done with something like smime or CMS Openssl can do both. (CMS in newer versions only) 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 -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] C_GetSlotList() returns 0 slots in Linux?
2012/8/22 Andrew Zitnay d...@lastpass.com: I have a Linux user that I'm trying to get working with OpenSC. However, according to my logs, C_GetSlotList() is finding 0 slots. I'm unable to reproduce this problem on my own Linux box. The user claims the smart card reader is plugged in and working properly in Firefox/Thunderbird: Bus 004 Device 012: ID 058f:9540 Alcor Micro Corp. In Firefox´s Device Manager: Security Modules and Devices: PKCS11 Module PKCS11 Path /usr/lib/opensc-pkcs11.so OpenSC loads libpcsclite.so.1 dynamically at run time. Check the path is correct in provider_library definition of the /etc/opensc.conf file. Bye -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] encrypt / decrypt
-Original Message- From: opensc-devel-boun...@lists.opensc-project.org [mailto:opensc-devel-boun...@lists.opensc-project.org] On Behalf Of Douglas E. Engert Sent: Wednesday, August 22, 2012 5:12 PM To: opensc-devel@lists.opensc-project.org Subject: Re: [opensc-devel] encrypt / decrypt On 8/22/2012 9:50 AM, j.witvl...@mindef.nl wrote: Hi all, I've been trying to make more use of our smartcards, but I think I am missing the point some how. What I would like to do is: a) encrypt some data, by means of one of my private keys on my smartcard someone else should be able to decrypt it with the public key on my certificate. b) let someone else encrypt some data, by means of my public key on my certificate. I should be able to decrypt it with one of my private keys on my smartcard. I speak in plural about keys/certificates, cause we have different pairs for authentication/non-repodiation/etc So first I load the engine: OpenSSL engine dynamic -pre SO_PATH:/usr/lib/engines/engine_pkcs11.so -pre ID:pkcs11 -pre LIST_ADD:1 -pre LOAD -pre MODULE_PATH:/usr/lib/libaetpkss.so.3.0 (dynamic) Dynamic engine loading support [Success]: SO_PATH:/usr/lib/engines/engine_pkcs11.so [Success]: ID:pkcs11 [Success]: LIST_ADD:1 [Success]: LOAD [Success]: MODULE_PATH:/usr/lib/libaetpkss.so.3.0 Loaded: (pkcs11) pkcs11 engine OpenSSL And next I try to encrypt something: OpenSSL OpenSSL enc -base64 -in /root/data.txt -out file.txt.enc -engine pkcs11 engine pkcs11 set. OpenSSL OpenSSL enc -d -aes-256-cbc -a -in file.txt.enc -engine pkcs11 engine pkcs11 set. enter aes-256-cbc decryption password: error in enc OpenSSL I presume, I'll have to specify which private-key (and PIN), although -k 41 or -k 43 does not work either, neither does -key id_43 Am I missing something, or is this just not possible? Yes you are missing something. Because asymmetric key encryption like RSA is slow and the amount of data that can be encrypted is limited, what is usually done is to encrypt the data in a symmetric key, like AES, then encrypt the AES key using the RSA public key. the encrypted data and the encrypted key are then sent, and the process is reversed using the RSA private key. This packaging of the message is usually done with something like smime or CMS Openssl can do both. (CMS in newer versions only) -Original Message- No, the aspect of using a symmetric key didn't slip my mind. That very well when encrypting large amount of data... But when the symmetric key is large (compared to the data), then the overhead does not justify the means. (I think) And you have to transfer the encrypted key as well as the encrypted data. 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] Minidriver assume hexstring encoding for card serial number
On 8/22/2012 10:09 AM, Andreas Schwier wrote:
Hi Douglas,
thanks for your infos.
The minidriver.c already ensures that the cardid file is always 16 byte.
It does this by repeating the token serial number until 16 bytes are filled.
Unfortunately that gives OpenbSC 16 bytes but does not improve the uniqunness.
Fortunately the uniqueness today only needs to extend over all the cards
as seen on a single machine which may be only a hand full. the cardid
is not sent to AD for example. But it also means that if the certificates
or keys on a card are changed, the cardid should also change.
We can ensure uniqueness of the serial number for our cards, but no
uniqueness among all other card vendors. There remains a (very) little
probability that a hexadecimal encoded serial number of another vendor's
card resembles one of our ASCII serial numbers.
Our serial numbers are based on the numbering scheme for machine
readable travel documents, a 2 digit country code followed by up to 9
ASCII digits (e.g. UTTM1234567 equals 5554544D313233343536375554544D31
in cardid).
You did not say what was the minimum number of digits are, and
in you example the first 4 ACSII digits are letters not numbers that
introduce more uniqueness then numbers. Also for a single machine would
it always see the same country code?
If you have 9 ASCII characters that should introduce enough uniqueness
to avoid conflicts with your other cards and other vendors cards.
One point I am trying to make is the cardid value is not really seen
by the user, thus it does not have to be printable, and it could
hold more uniqueness then a printable string. But if there is not
enough unique data on the card to populate the cardid you have to use
whatever you have.
Our proposed change (see [1]) will not alter the current behaviour with
existing cards. It will just allow a card that uses a ASCII serial
number to work as well.
An alternative approach - and probably more invasive - would be to use
the result of SC_CARDCTL_GET_SERIALNR in minidriver.c as input for the
cardid file. This way we could still have our human readable serial
number at the PKCS#11 und PKCS#15 level and a little more uniqueness in
the cardid file.
On some cards whewre there is no serial readable form the card the
SC_CARDCTL_GET_SERIALNR does similar tricts to come up with a serial number
from what ever data it can use on the card.
This will however break existing installations, as the
content of the cardid file might change with the driver update.
Yes it might break existing installations, as it would look like a new card
to the application, but with the same certificate on two cards. This could be
an issue if Windows searches the cert store for a certificate, then asks the
user to insert the matching card. i.e. the old card, not the new one.
As long as you have 6 digits or characters in your printable string that should
be fine.
Andreas
[1]
https://github.com/CardContact/OpenSC/commit/724cdd06e23ecd2e822bd1f138d9c3fbdafe9324
Am 22.08.2012 16:29, schrieb Douglas E. Engert:
On 8/22/2012 5:28 AM, Andreas Schwier (ML) wrote:
Hi everyone,
we've come across an issue with the minidriver which assumes the card
serial number to be a hex string.
In our card the serial number is a string composed of ASCII characters.
This works well with pkcs15-tool and the PKCS#11 library, however it
fails with the current minidriver when it tries to convert the hex
string into binary data for the cardid file.
Neither in PKCS#11 spec nor in ISO 7816-15 I can find a definition for
encoding the serial number as hex string.
The minidriver does not use the PKCS#11 standards, it is the Microsoft
definition of what it expects in the cardid file that counts.
http://www.microsoft.com/whdc/device/input/smartcard/sc-minidriver.mspx
Section 5.4.1 says:
The logical name for this file is “CardId”. It is in the root directory.
The file is organized as a 16-byte array. It should be treated as opaque
binary data.
This value is assigned by Microsoft software to assure that a unique
value is
generated for the card. It is unrelated to the serial number that may or
may not
be assigned to the card during manufacture.
In other places it calls it as a GUID.
This also means that when displayed, it maybe displayed as a GUID as hex
digits
with {, } , and - added for readability, and some bytes reversed in
little
endian machines. So it may not be recognizable as your serial number.
That said, since the minidriver is emulating a card that should have a
cardid file,
the data to populate the emulated cardid file has to come from the card and
be the same
at every use, and unique across all cards not just one site or one card
vendor.
The value or its derivatives are stored in the certificate store and used
to associate cards with data previously cached.
I therefore propose to change the code in minidriver.c to do the
Re: [opensc-devel] encrypt / decrypt
-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: Wednesday, August 22, 2012 5:51 PM To: deeng...@anl.gov; opensc-devel@lists.opensc-project.org Subject: Re: [opensc-devel] encrypt / decrypt -Original Message- From: opensc-devel-boun...@lists.opensc-project.org [mailto:opensc-devel-boun...@lists.opensc-project.org] On Behalf Of Douglas E. Engert Sent: Wednesday, August 22, 2012 5:12 PM To: opensc-devel@lists.opensc-project.org Subject: Re: [opensc-devel] encrypt / decrypt On 8/22/2012 9:50 AM, j.witvl...@mindef.nl wrote: Hi all, I've been trying to make more use of our smartcards, but I think I am missing the point some how. What I would like to do is: a) encrypt some data, by means of one of my private keys on my smartcard someone else should be able to decrypt it with the public key on my certificate. b) let someone else encrypt some data, by means of my public key on my certificate. I should be able to decrypt it with one of my private keys on my smartcard. I speak in plural about keys/certificates, cause we have different pairs for authentication/non-repodiation/etc So first I load the engine: OpenSSL engine dynamic -pre SO_PATH:/usr/lib/engines/engine_pkcs11.so -pre ID:pkcs11 -pre LIST_ADD:1 -pre LOAD -pre MODULE_PATH:/usr/lib/libaetpkss.so.3.0 (dynamic) Dynamic engine loading support [Success]: SO_PATH:/usr/lib/engines/engine_pkcs11.so [Success]: ID:pkcs11 [Success]: LIST_ADD:1 [Success]: LOAD [Success]: MODULE_PATH:/usr/lib/libaetpkss.so.3.0 Loaded: (pkcs11) pkcs11 engine OpenSSL And next I try to encrypt something: OpenSSL OpenSSL enc -base64 -in /root/data.txt -out file.txt.enc -engine pkcs11 engine pkcs11 set. OpenSSL OpenSSL enc -d -aes-256-cbc -a -in file.txt.enc -engine pkcs11 engine pkcs11 set. enter aes-256-cbc decryption password: error in enc OpenSSL I presume, I'll have to specify which private-key (and PIN), although -k 41 or -k 43 does not work either, neither does -key id_43 Am I missing something, or is this just not possible? Yes you are missing something. Because asymmetric key encryption like RSA is slow and the amount of data that can be encrypted is limited, what is usually done is to encrypt the data in a symmetric key, like AES, then encrypt the AES key using the RSA public key. the encrypted data and the encrypted key are then sent, and the process is reversed using the RSA private key. This packaging of the message is usually done with something like smime or CMS Openssl can do both. (CMS in newer versions only) -Original Message- Or actually, if you mean that I took the wrong tool from the gigantic openssl-toolbox... When looking at openssl-manpage I see... `openssl smime -sign -in text.plain -text -out text.encr -signer mycert.pem -inkey mykey.pem -certfile mycerts.pem´ So how should I point to the keys and crt on the smartcard? 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] Minidriver assume hexstring encoding for card serial number
Hi Douglas, see below. Am 22.08.2012 18:00, schrieb Douglas E. Engert: On 8/22/2012 10:09 AM, Andreas Schwier wrote: Hi Douglas, thanks for your infos. The minidriver.c already ensures that the cardid file is always 16 byte. It does this by repeating the token serial number until 16 bytes are filled. Unfortunately that gives OpenbSC 16 bytes but does not improve the uniqunness. Fortunately the uniqueness today only needs to extend over all the cards as seen on a single machine which may be only a hand full. the cardid is not sent to AD for example. But it also means that if the certificates or keys on a card are changed, the cardid should also change. We can ensure uniqueness of the serial number for our cards, but no uniqueness among all other card vendors. There remains a (very) little probability that a hexadecimal encoded serial number of another vendor's card resembles one of our ASCII serial numbers. Our serial numbers are based on the numbering scheme for machine readable travel documents, a 2 digit country code followed by up to 9 ASCII digits (e.g. UTTM1234567 equals 5554544D313233343536375554544D31 in cardid). You did not say what was the minimum number of digits are, and in you example the first 4 ACSII digits are letters not numbers that introduce more uniqueness then numbers. Also for a single machine would it always see the same country code? The serial number is always 11 characters (0-9, A-Z). The country code is the country of the card issuer, within a country the card issuer gets a 2-character prefix and will define the remaining 7 character. If you have 9 ASCII characters that should introduce enough uniqueness to avoid conflicts with your other cards and other vendors cards. One point I am trying to make is the cardid value is not really seen by the user, thus it does not have to be printable, and it could hold more uniqueness then a printable string. But if there is not enough unique data on the card to populate the cardid you have to use whatever you have. Yes, I understand. I'm just concerned about the serial number visible to the user at the PKCS#15 and PKCS#11 level. There it would be nice to see the same serial number as the one printed on the card. My point is, that currently the minidriver silently assumes that the tokeninfo-serial_number contains a string with hexadecimal characters. Our proposed change (see [1]) will not alter the current behaviour with existing cards. It will just allow a card that uses a ASCII serial number to work as well. An alternative approach - and probably more invasive - would be to use the result of SC_CARDCTL_GET_SERIALNR in minidriver.c as input for the cardid file. This way we could still have our human readable serial number at the PKCS#11 und PKCS#15 level and a little more uniqueness in the cardid file. On some cards whewre there is no serial readable form the card the SC_CARDCTL_GET_SERIALNR does similar tricts to come up with a serial number from what ever data it can use on the card. This will however break existing installations, as the content of the cardid file might change with the driver update. Yes it might break existing installations, as it would look like a new card to the application, but with the same certificate on two cards. This could be an issue if Windows searches the cert store for a certificate, then asks the user to insert the matching card. i.e. the old card, not the new one. As long as you have 6 digits or characters in your printable string that should be fine. Andreas [1] https://github.com/CardContact/OpenSC/commit/724cdd06e23ecd2e822bd1f138d9c3fbdafe9324 Am 22.08.2012 16:29, schrieb Douglas E. Engert: On 8/22/2012 5:28 AM, Andreas Schwier (ML) wrote: Hi everyone, we've come across an issue with the minidriver which assumes the card serial number to be a hex string. In our card the serial number is a string composed of ASCII characters. This works well with pkcs15-tool and the PKCS#11 library, however it fails with the current minidriver when it tries to convert the hex string into binary data for the cardid file. Neither in PKCS#11 spec nor in ISO 7816-15 I can find a definition for encoding the serial number as hex string. The minidriver does not use the PKCS#11 standards, it is the Microsoft definition of what it expects in the cardid file that counts. http://www.microsoft.com/whdc/device/input/smartcard/sc-minidriver.mspx Section 5.4.1 says: The logical name for this file is “CardId”. It is in the root directory. The file is organized as a 16-byte array. It should be treated as opaque binary data. This value is assigned by Microsoft software to assure that a unique value is generated for the card. It is unrelated to the serial number that may or may not be assigned to the card during manufacture. In other places it calls it as a GUID. This also means that when displayed, it maybe
Re: [opensc-devel] encrypt / decrypt
On 8/22/2012 10:51 AM, j.witvl...@mindef.nl wrote: -Original Message- From: opensc-devel-boun...@lists.opensc-project.org [mailto:opensc-devel-boun...@lists.opensc-project.org] On Behalf Of Douglas E. Engert Sent: Wednesday, August 22, 2012 5:12 PM To: opensc-devel@lists.opensc-project.org Subject: Re: [opensc-devel] encrypt / decrypt On 8/22/2012 9:50 AM, j.witvl...@mindef.nl wrote: Hi all, I've been trying to make more use of our smartcards, but I think I am missing the point some how. What I would like to do is: a) encrypt some data, by means of one of my private keys on my smartcard someone else should be able to decrypt it with the public key on my certificate. b) let someone else encrypt some data, by means of my public key on my certificate. I should be able to decrypt it with one of my private keys on my smartcard. I speak in plural about keys/certificates, cause we have different pairs for authentication/non-repodiation/etc So first I load the engine: OpenSSL engine dynamic -pre SO_PATH:/usr/lib/engines/engine_pkcs11.so -pre ID:pkcs11 -pre LIST_ADD:1 -pre LOAD -pre MODULE_PATH:/usr/lib/libaetpkss.so.3.0 (dynamic) Dynamic engine loading support [Success]: SO_PATH:/usr/lib/engines/engine_pkcs11.so [Success]: ID:pkcs11 [Success]: LIST_ADD:1 [Success]: LOAD [Success]: MODULE_PATH:/usr/lib/libaetpkss.so.3.0 Loaded: (pkcs11) pkcs11 engine OpenSSL And next I try to encrypt something: OpenSSL OpenSSL enc -base64 -in /root/data.txt -out file.txt.enc -engine pkcs11 engine pkcs11 set. OpenSSL openssl enc only works with symmetric keys. You could write your own program to use openssl to use RSA. OpenSSL enc -d -aes-256-cbc -a -in file.txt.enc -engine pkcs11 engine pkcs11 set. enter aes-256-cbc decryption password: error in enc OpenSSL I presume, I'll have to specify which private-key (and PIN), although -k 41 or -k 43 does not work either, neither does -key id_43 Am I missing something, or is this just not possible? Yes you are missing something. Because asymmetric key encryption like RSA is slow and the amount of data that can be encrypted is limited, what is usually done is to encrypt the data in a symmetric key, like AES, then encrypt the AES key using the RSA public key. the encrypted data and the encrypted key are then sent, and the process is reversed using the RSA private key. This packaging of the message is usually done with something like smime or CMS Openssl can do both. (CMS in newer versions only) -Original Message- No, the aspect of using a symmetric key didn't slip my mind. That very well when encrypting large amount of data... But when the symmetric key is large (compared to the data), then the overhead does not justify the means. (I think) And you have to transfer the encrypted key as well as the encrypted data. How short are these messages? Using PKCS#11 CKM_RSA_X_509, the size of the message must be less then the size of the modulus and if using some padded version between 11 bytes less and maybe half the size of the modulus. Using RSA directly of a previously sent message will produce the same encrypted output which could be subject examination or re-play. Smime and CMS avoid many of these security issues and others. 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. -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Minidriver assume hexstring encoding for card serial number
On 8/22/2012 11:24 AM, Andreas Schwier (ML) wrote:
Hi Douglas,
see below.
Am 22.08.2012 18:00, schrieb Douglas E. Engert:
On 8/22/2012 10:09 AM, Andreas Schwier wrote:
Hi Douglas,
thanks for your infos.
The minidriver.c already ensures that the cardid file is always 16 byte.
It does this by repeating the token serial number until 16 bytes are filled.
Unfortunately that gives OpenbSC 16 bytes but does not improve the
uniqunness.
Fortunately the uniqueness today only needs to extend over all the cards
as seen on a single machine which may be only a hand full. the cardid
is not sent to AD for example. But it also means that if the certificates
or keys on a card are changed, the cardid should also change.
We can ensure uniqueness of the serial number for our cards, but no
uniqueness among all other card vendors. There remains a (very) little
probability that a hexadecimal encoded serial number of another vendor's
card resembles one of our ASCII serial numbers.
Our serial numbers are based on the numbering scheme for machine
readable travel documents, a 2 digit country code followed by up to 9
ASCII digits (e.g. UTTM1234567 equals 5554544D313233343536375554544D31
in cardid).
You did not say what was the minimum number of digits are, and
in you example the first 4 ACSII digits are letters not numbers that
introduce more uniqueness then numbers. Also for a single machine would
it always see the same country code?
The serial number is always 11 characters (0-9, A-Z). The country code
is the country of the card issuer, within a country the card issuer gets
a 2-character prefix and will define the remaining 7 character.
OK, so you are looking at how to handle the failure
in minidriver.c at line 1071, not on getting a printable string to show up.
1069 rv = sc_hex_to_bin(vs-p15card-tokeninfo-serial_number,
sn_bin, sn_len);
1070 if (rv)
1071 return SCARD_E_INVALID_VALUE;
by change to something like:
rv = sc_hex_to_bin(vs-p15card-tokeninfo-serial_number, sn_bin,
sn_len);
if (rv) {
strncpy(s_bin, vs-p15card-tokeninfo-serial_number,
sizeof(sn_bin));
sn_len = strlen(vs-p15card-tokeninfo-serial_number);
if (sn_len 2) /* really too short to use as a cardid */
return SCARD_E_INVALID_VALUE;
if (sn_len sizeof(sn_bin)) sn_len = sizeof(sn_bin);
}
I have not tried this.
Since this fails, in your case, I don't have any objection to adding something
like the above.
If you have 9 ASCII characters that should introduce enough uniqueness
to avoid conflicts with your other cards and other vendors cards.
One point I am trying to make is the cardid value is not really seen
by the user, thus it does not have to be printable, and it could
hold more uniqueness then a printable string. But if there is not
enough unique data on the card to populate the cardid you have to use
whatever you have.
Yes, I understand. I'm just concerned about the serial number visible to
the user at the PKCS#15 and PKCS#11 level. There it would be nice to see
the same serial number as the one printed on the card. My point is, that
currently the minidriver silently assumes that the
tokeninfo-serial_number contains a string with hexadecimal characters.
Our proposed change (see [1]) will not alter the current behaviour with
existing cards. It will just allow a card that uses a ASCII serial
number to work as well.
An alternative approach - and probably more invasive - would be to use
the result of SC_CARDCTL_GET_SERIALNR in minidriver.c as input for the
cardid file. This way we could still have our human readable serial
number at the PKCS#11 und PKCS#15 level and a little more uniqueness in
the cardid file.
On some cards whewre there is no serial readable form the card the
SC_CARDCTL_GET_SERIALNR does similar tricts to come up with a serial number
from what ever data it can use on the card.
This will however break existing installations, as the
content of the cardid file might change with the driver update.
Yes it might break existing installations, as it would look like a new card
to the application, but with the same certificate on two cards. This could be
an issue if Windows searches the cert store for a certificate, then asks the
user to insert the matching card. i.e. the old card, not the new one.
As long as you have 6 digits or characters in your printable string that
should
be fine.
Andreas
[1]
https://github.com/CardContact/OpenSC/commit/724cdd06e23ecd2e822bd1f138d9c3fbdafe9324
Am 22.08.2012 16:29, schrieb Douglas E. Engert:
On 8/22/2012 5:28 AM, Andreas Schwier (ML) wrote:
Hi everyone,
we've come across an issue with the minidriver which assumes the card
serial number to be a hex string.
In our card the serial number is a string composed of ASCII characters.
This works well with
Re: [opensc-devel] Minidriver assume hexstring encoding for card serial number
Yes, that's basically what our patch is all about. There are actually
two places in minidriver.c where the tokeninfo-serial_number value is
copied. We propose to change both as you can see in [1].
Andreas
[1]
https://github.com/CardContact/OpenSC/commit/724cdd06e23ecd2e822bd1f138d9c3fbdafe9324
Am 22.08.2012 20:30, schrieb Douglas E. Engert:
On 8/22/2012 11:24 AM, Andreas Schwier (ML) wrote:
Hi Douglas,
see below.
Am 22.08.2012 18:00, schrieb Douglas E. Engert:
On 8/22/2012 10:09 AM, Andreas Schwier wrote:
Hi Douglas,
thanks for your infos.
The minidriver.c already ensures that the cardid file is always 16 byte.
It does this by repeating the token serial number until 16 bytes are
filled.
Unfortunately that gives OpenbSC 16 bytes but does not improve the
uniqunness.
Fortunately the uniqueness today only needs to extend over all the cards
as seen on a single machine which may be only a hand full. the cardid
is not sent to AD for example. But it also means that if the certificates
or keys on a card are changed, the cardid should also change.
We can ensure uniqueness of the serial number for our cards, but no
uniqueness among all other card vendors. There remains a (very) little
probability that a hexadecimal encoded serial number of another vendor's
card resembles one of our ASCII serial numbers.
Our serial numbers are based on the numbering scheme for machine
readable travel documents, a 2 digit country code followed by up to 9
ASCII digits (e.g. UTTM1234567 equals 5554544D313233343536375554544D31
in cardid).
You did not say what was the minimum number of digits are, and
in you example the first 4 ACSII digits are letters not numbers that
introduce more uniqueness then numbers. Also for a single machine would
it always see the same country code?
The serial number is always 11 characters (0-9, A-Z). The country code
is the country of the card issuer, within a country the card issuer gets
a 2-character prefix and will define the remaining 7 character.
OK, so you are looking at how to handle the failure
in minidriver.c at line 1071, not on getting a printable string to show up.
1069 rv =
sc_hex_to_bin(vs-p15card-tokeninfo-serial_number, sn_bin, sn_len);
1070 if (rv)
1071 return SCARD_E_INVALID_VALUE;
by change to something like:
rv = sc_hex_to_bin(vs-p15card-tokeninfo-serial_number, sn_bin,
sn_len);
if (rv) {
strncpy(s_bin, vs-p15card-tokeninfo-serial_number,
sizeof(sn_bin));
sn_len = strlen(vs-p15card-tokeninfo-serial_number);
if (sn_len 2) /* really too short to use as a cardid */
return SCARD_E_INVALID_VALUE;
if (sn_len sizeof(sn_bin)) sn_len = sizeof(sn_bin);
}
I have not tried this.
Since this fails, in your case, I don't have any objection to adding something
like the above.
If you have 9 ASCII characters that should introduce enough uniqueness
to avoid conflicts with your other cards and other vendors cards.
One point I am trying to make is the cardid value is not really seen
by the user, thus it does not have to be printable, and it could
hold more uniqueness then a printable string. But if there is not
enough unique data on the card to populate the cardid you have to use
whatever you have.
Yes, I understand. I'm just concerned about the serial number visible to
the user at the PKCS#15 and PKCS#11 level. There it would be nice to see
the same serial number as the one printed on the card. My point is, that
currently the minidriver silently assumes that the
tokeninfo-serial_number contains a string with hexadecimal characters.
Our proposed change (see [1]) will not alter the current behaviour with
existing cards. It will just allow a card that uses a ASCII serial
number to work as well.
An alternative approach - and probably more invasive - would be to use
the result of SC_CARDCTL_GET_SERIALNR in minidriver.c as input for the
cardid file. This way we could still have our human readable serial
number at the PKCS#11 und PKCS#15 level and a little more uniqueness in
the cardid file.
On some cards whewre there is no serial readable form the card the
SC_CARDCTL_GET_SERIALNR does similar tricts to come up with a serial
number
from what ever data it can use on the card.
This will however break existing installations, as the
content of the cardid file might change with the driver update.
Yes it might break existing installations, as it would look like a new card
to the application, but with the same certificate on two cards. This could
be
an issue if Windows searches the cert store for a certificate, then asks the
user to insert the matching card. i.e. the old card, not the new one.
As long as you have 6 digits or characters in your printable string that
should
be fine.
Andreas
[1]
Re: [opensc-devel] Minidriver assume hexstring encoding for card serial number
On 8/22/2012 1:53 PM, Andreas Schwier wrote:
Yes, that's basically what our patch is all about. There are actually
two places in minidriver.c where the tokeninfo-serial_number value is
copied. We propose to change both as you can see in [1].
Looks good.
Andreas
[1]
https://github.com/CardContact/OpenSC/commit/724cdd06e23ecd2e822bd1f138d9c3fbdafe9324
Am 22.08.2012 20:30, schrieb Douglas E. Engert:
On 8/22/2012 11:24 AM, Andreas Schwier (ML) wrote:
Hi Douglas,
see below.
Am 22.08.2012 18:00, schrieb Douglas E. Engert:
On 8/22/2012 10:09 AM, Andreas Schwier wrote:
Hi Douglas,
thanks for your infos.
The minidriver.c already ensures that the cardid file is always 16 byte.
It does this by repeating the token serial number until 16 bytes are
filled.
Unfortunately that gives OpenbSC 16 bytes but does not improve the
uniqunness.
Fortunately the uniqueness today only needs to extend over all the cards
as seen on a single machine which may be only a hand full. the cardid
is not sent to AD for example. But it also means that if the certificates
or keys on a card are changed, the cardid should also change.
We can ensure uniqueness of the serial number for our cards, but no
uniqueness among all other card vendors. There remains a (very) little
probability that a hexadecimal encoded serial number of another vendor's
card resembles one of our ASCII serial numbers.
Our serial numbers are based on the numbering scheme for machine
readable travel documents, a 2 digit country code followed by up to 9
ASCII digits (e.g. UTTM1234567 equals 5554544D313233343536375554544D31
in cardid).
You did not say what was the minimum number of digits are, and
in you example the first 4 ACSII digits are letters not numbers that
introduce more uniqueness then numbers. Also for a single machine would
it always see the same country code?
The serial number is always 11 characters (0-9, A-Z). The country code
is the country of the card issuer, within a country the card issuer gets
a 2-character prefix and will define the remaining 7 character.
OK, so you are looking at how to handle the failure
in minidriver.c at line 1071, not on getting a printable string to show up.
1069 rv =
sc_hex_to_bin(vs-p15card-tokeninfo-serial_number, sn_bin, sn_len);
1070 if (rv)
1071 return SCARD_E_INVALID_VALUE;
by change to something like:
rv = sc_hex_to_bin(vs-p15card-tokeninfo-serial_number, sn_bin,
sn_len);
if (rv) {
strncpy(s_bin, vs-p15card-tokeninfo-serial_number,
sizeof(sn_bin));
sn_len = strlen(vs-p15card-tokeninfo-serial_number);
if (sn_len 2) /* really too short to use as a cardid */
return SCARD_E_INVALID_VALUE;
if (sn_len sizeof(sn_bin)) sn_len = sizeof(sn_bin);
}
I have not tried this.
Since this fails, in your case, I don't have any objection to adding
something
like the above.
If you have 9 ASCII characters that should introduce enough uniqueness
to avoid conflicts with your other cards and other vendors cards.
One point I am trying to make is the cardid value is not really seen
by the user, thus it does not have to be printable, and it could
hold more uniqueness then a printable string. But if there is not
enough unique data on the card to populate the cardid you have to use
whatever you have.
Yes, I understand. I'm just concerned about the serial number visible to
the user at the PKCS#15 and PKCS#11 level. There it would be nice to see
the same serial number as the one printed on the card. My point is, that
currently the minidriver silently assumes that the
tokeninfo-serial_number contains a string with hexadecimal characters.
Our proposed change (see [1]) will not alter the current behaviour with
existing cards. It will just allow a card that uses a ASCII serial
number to work as well.
An alternative approach - and probably more invasive - would be to use
the result of SC_CARDCTL_GET_SERIALNR in minidriver.c as input for the
cardid file. This way we could still have our human readable serial
number at the PKCS#11 und PKCS#15 level and a little more uniqueness in
the cardid file.
On some cards whewre there is no serial readable form the card the
SC_CARDCTL_GET_SERIALNR does similar tricts to come up with a serial
number
from what ever data it can use on the card.
This will however break existing installations, as the
content of the cardid file might change with the driver update.
Yes it might break existing installations, as it would look like a new
card
to the application, but with the same certificate on two cards. This could
be
an issue if Windows searches the cert store for a certificate, then asks
the
user to insert the matching card. i.e. the old card, not the new one.
As long as you have 6 digits or characters in your printable string that
should
be fine.
