Eutron offers the CryptoIdentity ITSEC-I & ITSEC-P, an USB readerless smart card / crypto token with 32k memory and support for RSA keys up to 1024bit key length.
The CryptoIdentity ITSEC-I & ITSEC-P is fully supported by OpenSC, but has not been tested for a while.
Note that Eutron also offers two other crypto tokens in the CryptoIdentity line, but those
are not supported at all (no documentation available); “combo” models are also available
offering USB flash memory mass-storage functionality in addiction to smart card features.
The smart card inside is an Infineon Chip with the [[Siemens CardOS M4|Siemens-CardOS-M4]] smart card operating system (ITSEC-I model) or Philips Chip with the [wiki:STARCOS StarCOS SPK 2.3/2.4] operating system (ITSEC-P, model).
The driver is called “etoken” because this was the first device with that smart card that was tested with OpenSC. Only the usb
interface differs, the rest seems to be the same.
One minor feature of the Siemens CardOS M4 is, that a rsa key cannot be used for both signing
and decryption. OpenSC has implemented a workaround: software key generation and storing that
key twice, once marked as decryption key and once marked as signing key. To enable this workaround
specifiy “—split-key” on the command line, when creating the key.
Eutron has their own software for windows. This software does not implement PKCS#15 and thus is not
compatible with OpenSC. As long as the card has memory, you can initialize the card with both software
packages, and thus install files and keys side by side – each software can only handle their own structures.
Documentation was not necessary, as the driver for the smart card inside was already implemented.
However there is no official tool to format a token (for example if you lock it up by accident), you must contact Eutron in this case.
For price and availability, please contact Eutron directly.
Big thanks to Eutron, they donated several tokens and a sim card reader. We are working on
improving our support for the cards. Thanks!
As of 2006-06-17 there are known problems with ITSEC-I toekn, which have been initialized by Eutron for their own software.
As a symptom you encounter the following error when trying to generate a private key atop of an existing PIN:
$ pkcs15-init -G rsa/1024 -a 1 -i 45 -u sign --so-pin 11111111 --pin 11112222
card-cardos.c:225:cardos_check_sw: required access right not granted
card-cardos.c:907:cardos_put_data_oci: Card returned error: Security status
not satisfied
card.c:686:sc_card_ctl: returning with: Security status not satisfied
Failed to generate key: Security status not satisfied
You might also come across the following error, if you try to generate an PIN-protected private key more than once,
after you have got the above error message:
$ pkcs15-init -G rsa/1024 -a 1 -i 46 -u sign
card-cardos.c:225:cardos_check_sw: invalid parameters in data field
card.c:376:sc_create_file: returning with: Incorrect parameters in APDU
Failed to generate key: Incorrect parameters in APDU
The reason for the above error messages is, that the Token is in the wrong cardos-lifecycle “operational”, where some operations
like key generation do not seem to be suported. You can get the current lifecycle of a token using the cardos-tool command:
# cardos-tool
Info : CardOS/M4.01a (C) Siemens AG 1994-2002
Chip type: 108
Serial number: 24 72 7b 03 1c 0a
Full prom dump:
33 66 00 1F DD DD DD DD 6C FF 24 72 7B 03 1C 0A 3f......l.$r{...
00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 ................
OS Version: 200.4 (that's CardOS M4.01a)
Current life cycle: 16 (operational)
Security Status of current DF:
Free memory : 1000
ATR Status: 0x0 ROM-ATR
Packages installed:
01 04 07 02 C8 04 01 04 13 04 C8 04 ............
Ram size: 4, Eeprom size: 32, cpu type: 66, chip config: 63
Free eeprom memory: 20596
System keys: PackageLoadKey (version 0x00, retries 10)
System keys: StartKey (version 0xff, retries 10)
Path to current DF:
In the above snippet you see, that this token is in the “operational” lifecycle and is hence subject to the above mentioned problems.
As a side effect of the wrong operational mode, opensc is not alble to delete any DFs/MFs when the private key generation fails.
In such a case you will discover a temporary object EF 5015/7EAD on your token, which triggers the second problem mentioned above.
$ opensc-explorer
OpenSC Explorer version 0.11.0
OpenSC [3F00]> cd 5015
OpenSC [3F00/5015]> ls
FileID Type Size
4401 wEF 256
5031 wEF 256
5032 wEF 42
4946 wEF 128
4402 wEF 256
3048 wEF 142
4403 wEF 256
7EAD wEF 512
OpenSC [3F00/5015]> quit
Nils Larsch has kindly provided me with a workaround for the problem of deleting EFs/MFs, however there’s no benefit for the end-user, because
you neither will be able to generate a private key if you can delete the temporatry object. If you are interested in the whole story,
mail me (wolfgang dot wglas at ev-i dot at).
A satisfying solution of this problem is unfortunately tied to the solution of the initialization problem. Eutron has been so kind to provide me with Tokens, which are in the “manufactured” lifecycle, which means that these tokens are not initialized with any software package. In this state, these tokens are not usable for opensc, because you need some APDU-initalization scripts from Siemens in order to initialize the software packages on the chip.
The Eutron entry in the openct Wiki has some informations on an initialization tool, which is available from Eutron, but this tool is not very helpful, since is restores the token to the state described above.
We are currently trying to find a solution for this problem together with Siemens, Eutron and Andreas Jellinghaus. If we make further progress with this issue, we will publish them on this Wiki page as soon as possible.