Expandall |
---|
Gemalto cards
Expand | ||
---|---|---|
| ||
Tested card types include the following (this list is not complete): IDPrimePKCS11 DLL from IDGo 800 Installer
eTPKCS11 DLL from SAC Installer
IDPrimePKCS11 DLL from SAC Installer
|
Expand | ||
---|---|---|
| ||
|
Support for cards with signature slot
Expand | ||
---|---|---|
| ||
Gemalto IDPrime 940 cardsand USB tokens (like SafeNet eToken 5110 CC) contain a secondary slot for digital signatures, using its own set of credentials. The factory default for the signature PIN and PUK is 000000 for each. From PRIME 3.12, these are supported on the IDPrimePKCS11 DLLs that are included with a recent Safenet Authentication Client (SAC) Installer. SAC version 10.7 or later is required, see above for tested versions. |
Encodings
Expand | |||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||
The PKCS11 library setting depends on the DLL and installer you used:
|
Expand | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
Do not use the PUK in encodings, use only the Card Manager Key (CMK). The two keys are identical but using a PUK with our implementation would only limit the effective key size.
The CMK must always be a sequence of 24 bytes. To set this value, specify the hex values of the bytes.
|
Deviations from PKCS#11 standard
Expand | ||
---|---|---|
| ||
Tokens are always preinitialized. The initial PUK is a bytearray consisting of 24 nullbytes. |
Expand | ||
---|---|---|
| ||
A new PUK must always be 24 bytes long. |
Expand | ||
---|---|---|
| ||
The following restrictions apply:
|
Configuration
Expand | |||||||
---|---|---|---|---|---|---|---|
| |||||||
To configure logging behaviour:
This is an example of a configuration file:
|
Known issues and troubleshooting
Expand | ||
---|---|---|
| ||
Problem Identity Manager versions before 3.10.6 / 3.11 have a bug that fails to detect the eTPKCS11 middleware type correctly. This causes a change to the PUK/cardManagerKey to silently fail. Therefore the PUK/cardManagerKey on the card is still the old one, but Identity Manager thinks it was changed, thus breaking the unblocking process. Solution Upgrade to Identity Manager 3.10.6 or 3.11 to solve the issue. Note that this will not automatically fix cards which were produced with the broken version. |
Expand | ||
---|---|---|
| ||
Problem With a lot of certificates on the card, but about 9Kb on the card still free according to the Mini-Driver Manager, InitToken or DestroyObject returned CKR_DEVICE_MEMORY. Even the Mini-Driver Manager crashed when attempting "Erase Card". Solution Delete single containers through the GUI. At 11Kb free, InitToken succeeded again (with 830 rev.A cards). |
Expand | ||
---|---|---|
| ||
Trying to write a CA certificate that is already on the card fails with C_CreateObject failed with CKR_FUNCTION_FAILED. JPKIEncoder will notice this and will avoid trying to rewrite it. |
Expand | ||
---|---|---|
| ||
Problem You get an error like this in the log when trying to encode a card through Smart ID Desktop App:
Solution Make sure the DLLs are present and specified in a correct way (absolute paths are usually required, see DLL Locations above). |
Expand | ||
---|---|---|
| ||
Problem Trying to delete a CA certificate can sometimes result in a state in which the certificate is no longer visible through PKCS#11, but still present on the card and visible through the SafeNet Authentication Client (SAC). Observed e.g. with IDPrime DLLs from SAC 10.7 . Solution Manually delete the certificate with SAC (multiple attempts might be needed) to fully remove it. Problem Similarly, trying to delete a CA certificate can sometimes result in a state where the certificate is not deleted but its label changed to a UUID. Observed e.g. with IDPrime DLLs from SAC 10.8 R2 and eTPKCS11 DLLs from SAC 10.7 . Solution Either manually delete the certificate with SAC or re-run the deletion (provided you are not using LABEL as deletion criteria, which would now fail to find the certificate) |
. |