scsh-scripts
scsh-scripts copied to clipboard
CardContact
Importing 4096 bit RSA keys from P12 into SmartCard-HSM 4K Mini-SIM Card (3.3) failed with SCSH v3.15.388
Importing key and certificate...
GPError: Card (CARD_INVALID_SW/27264) - "Unexpected SW1/SW2=6A80 (Checking error: Incorrect parameter in the command data field) received" in D:\XXXXX\scsh3.15.388\scsh\sc-hsm\SmartCardHSM.js#1270
at D:\XXXXX\scsh3.15.388\scsh\sc-hsm\SmartCardHSM.js#1270
at D:\XXXXX\scsh3.15.388\scsh\sc-hsm\HSMKeyStore.js#300
at D:\XXXXX\scsh3.15.388\keymanager\keymanager.js#1931
at D:\XXXXX\scsh3.15.388\keymanager\keymanager.js#2085
This bug should be fixed since v3.15.383 by Issue #5 , so I added "dkek.dumpKeyBLOB(blob);" in "KeyManager.prototype.importPKCS12" for debugging (hiding some infos below):
Values from key blob:
---------------------
Checking the MAC : Passed
KCV : XXXXXXX [Must match the KCV of the DKEK for import]
Key type : 5 [5=RSA, 6=RSA-CRT, 12=ECC, 15=AES]
Default Algorithm ID : 0.4.0.127.0.7.2.2.2.1.2 (10) [Default algorithm]
Allowed Algorithm IDs : (0)
Access Conditions : (0) [Not used]
Key OID : (0) [Not used]
Randomize : XXXXXXXX [Random data prepended at export]
Key size : 4096 [Key size in bits (ECC/RSA) or bytes (AES)]
Private Exponent : 00A230822B41......A6FE9141 (513)
Modulus : BF00540892CD......A1C90B (512)
Public Exponent : 010001 (3)
and used "openssl rsa -in keyfile -text" for checking it:
modulus:
00:bf:00:54:08:92:cd:......:a1:c9:0b
publicExponent: 65537 (0x10001)
privateExponent:
00:a2:30:82:2b:41:......:a6:fe:91:41
The format of keyblob seems to be OK, I don't know where's wrong...
Below actions work:
- Importing 2048 bit RSA keys from P12
- Generating 4096 bit RSA keys on the card, then exporting them, then deleting them from the card, and then importing them
Seems like the private exponent is too long.
Can you try to edit scsh/sc-hsm/DKEK.js and add
var d = e.modInverse(r);
if (d.byteAt(0) == 0) {
d = d.bytes(1);
}
var nk = new Key();
in convertCRT2PEM(). You need the restart command to reload the module before you test.
After inserting this code, I've been able to import one key successfully, but after deleting it and trying a second time I get:
Importing key and certificate...
GPError: Card (CARD_INVALID_SW/27268) - "Unexpected SW1/SW2=6A84 (Checking error: Not enough memory space in the file) received" in …/nitrokey-hsm/scsh3.15.388/scsh/sc-hsm/SmartCardHSM.js#1270
The test keys are available here: https://git.pengutronix.de/cgit/ptx-code-signing-dev/tree/
I've used openssl pkcs12 -export -inkey fit-4096-development.key -in fit-4096-development.crt -name fit -out fit-4096-development.p12 -passout pass: to convert them to a .p12 file. I'm using a nitrokey HSM2 updated from 3.1 to 3.4.
Did you try the import directly after initializing the device ?
Try a card reset between initialization and import. There is a known bug in the JVM garbage collector that causes the import of 3K and 4K key directly after INITIALIZE DEVICE to fail. We can not fix this issue, as it lays outside of our code. The workaround is to do a card reset between initialization and import (Enter "r" on the Smart Card Shell console).
Did you try the import directly after initializing the device ?
I imported the DKEK via sc-hsm-tool and then generated a devnet cert and replugged the HSM. I was able to import it once successfully, but after deleting and retrying it failed.
Try a card reset between initialization and import. There is a known bug in the JVM garbage collector that causes the import of 3K and 4K key directly after INITIALIZE DEVICE to fail. We can not fix this issue, as it lays outside of our code. The workaround is to do a card reset between initialization and import (Enter "r" on the Smart Card Shell console).
OK. I'll do some more experiments.
Can you post a trace of the last 5 APDUs in the "trace" tab ?
I had do delete the key again, import it successfully and try to import another 4k key to get it to fail again: https://gist.github.com/jluebbe/2f897df679d51d7b6ed89d11ee1c5856
So far, I've only been able to import one of these keys per power-cycle or reset ('r' command). The second try always fails again with:
Importing key and certificate...
GPError: Card (CARD_INVALID_SW/27268) - "Unexpected SW1/SW2=6A84 (Checking error: Not enough memory space in the file) received" in …/nitrokey-hsm/scsh3.15.388/scsh/sc-hsm/SmartCardHSM.js#1270
I can reproduce the issue with your development key. It fails with out-of-memory during import.
I then disabled secure messaging and after a card reset it worked. You can disable secure messaging by opening keymanager/keymanager.js and disable
// this.sc.openSecureChannel(this.crypto, this.certchain.publicKey);
in KeyManager.prototype.setCard().
The problem with 4K key is, that all operations are very RAM consuming and the JVM stretches very close to the limit. We generally test with key material generated internally and not so much with externally generated keys (This is not a recommended approach, as it defeats the purpose of having a hardware token to protect keys).
My first guess is, that the key has some specific properties that cause problems in the JCOP OS. I will do some more testing in the emulator to see what makes the key specific.
Generally we recommend to use 2K RSA keys or if you need larger keys switch to ECC. ECC keys up to 521 bit work perfectly. 3K and 4K keys are problematic on JCOP3 devices. Importing 3K and 4K also has the problem, that they can not be imported in CRT format but PE/M. The wrapped CRT components are just to large to fit into the APDU buffer of the card.
In the future we will switch to JCOP4, which has a different implementation for larger RSA keys. Maybe things get better than.
I can reproduce the issue with your development key. It fails with out-of-memory during import.
Thanks for looking into this!
I then disabled secure messaging and after a card reset it worked. You can disable secure messaging by opening keymanager/keymanager.js and disable
// this.sc.openSecureChannel(this.crypto, this.certchain.publicKey);in KeyManager.prototype.setCard().
This is already commented out in scsh3.15.388. Is it already disabled?
The problem with 4K key is, that all operations are very RAM consuming and the JVM stretches very close to the limit. We generally test with key material generated internally and not so much with externally generated keys (This is not a recommended approach, as it defeats the purpose of having a hardware token to protect keys).
These keys are for software signing/verified boot of embedded devices. To be able to test the signing workflow as completely as possible, three cases:
- development keys loaded into SoftHSM2 (test PKCS#11 client implementation and normal development)
- development keys imported into Nitrokey HSM (testing usage of a real token with the same locked devices as in 1.)
- release keys generated on a separate set of Nitrokey HSMs (and backuped via warped key export/import)
The issue only happens for me with 2. So far I've been able to import the keys one by one, with resets in between. That's time intensive but allows me to test the whole chain with the existing locked devices.
My first guess is, that the key has some specific properties that cause problems in the JCOP OS. I will do some more testing in the emulator to see what makes the key specific.
Thanks.
Generally we recommend to use 2K RSA keys or if you need larger keys switch to ECC. ECC keys up to 521 bit work perfectly. 3K and 4K keys are problematic on JCOP3 devices. Importing 3K and 4K also has the problem, that they can not be imported in CRT format but PE/M. The wrapped CRT components are just to large to fit into the APDU buffer of the card.
I'd agree, but in this case, RSA 4k is the best supported by the Hardware/ROM-Code and ECC is not supported.
In the future we will switch to JCOP4, which has a different implementation for larger RSA keys. Maybe things get better than.
OK. Is JCOP3/4 part of the updateable firmware or would this be a new device?
The issue only happens for me with 2. So far I've been able to import the keys one by one, with resets in between. That's time intensive but allows me to test the whole chain with the existing locked devices.
After importing them from p12 one-by-one and exporting them as wrapped keys, I was able to reimport all .wky files in one session. So it seems there is some difference between how SCSH and the HSM wrap the same key material.
That is well possible. We suspect, that these kind of problems are caused by the way RAM objects in the JVM are garbage collected. Unfortunately NXP does not offer any documentation or support info how that is actually done.
So it depends on the sequence of APDUs, which is different when importing from wky or P12.
It works now with this patch, and with v3.16.426
Seems like the private exponent is too long.
Can you try to edit scsh/sc-hsm/DKEK.js and add
var d = e.modInverse(r); if (d.byteAt(0) == 0) { d = d.bytes(1); } var nk = new Key();in convertCRT2PEM(). You need the restart command to reload the module before you test.
Thank you for your effort to resolve the issue, but I still have exactly the problem:
Importing key and certificate...
GPError: Card (CARD_INVALID_SW/27268) - "Unexpected SW1/SW2=6A84 (Checking error: Not enough memory space in the file) received" in /home/crypto/CardContact/scsh3/scsh/sc-hsm/SmartCardHSM.js#1348
My trace shows the following:
2B C: 80 58 00 00 - ENUMERATE OBJECTS Le=0 Extended
R: SW1/SW2=9000 (Normal processing: No error) Lr=4
0000 2F 02 CC 00 /...
2B C: 80 52 00 00 - MANAGE KEY DOMAIN Lc=32
*** Sensitive Information Removed *** Le=0
R: SW1/SW2=9000 (Normal processing: No error) Lr=10
0000 01 00 6E 81 2E E3 06 38 4E E3 ..n....8N.
2B C: 80 74 01 93 - UNWRAP KEY Lc=1099 Extended
0007 6E 81 2E E3 06 38 4E E3 05 00 0A 04 00 7F 00 07 n....8N.........
0017 02 02 02 01 02 00 00 00 00 00 00 11 BB ED 32 20 ..............2
......
0437 07 4D 14 99 B3 00 1B 63 7C 7F 84 CD 6F 20 D0 DF .M.....c|...o ..
0447 3D EF 1B 6A AF BA 02 A9 3A B6 AB =..j....:..
R: SW1/SW2=6A84 (Checking error: Not enough memory space in the file) Lr=0
I have the following setup: SmartCard-HSM Version 3.3 on JCOP 3 - Free memory 86228 byte Windows 10 and /or Linux (Ubuntu 20.04) with Java 8 and /or Java 11 Smart Card Shell 3.16.426 PKCS12 file with RSA 4k key and self-signed certificate (no password protection) 1 generated and imported DKEK with no password
What I am doing wrong?
By the way: importing a 2k RSA key works fine.
SOLVED: I have updated the HSM to version 3.4 and I used the reset functionality!
I have a NitroKey HSM 2 that I updated to firmware v2.5. I still have this problem importing a RSA 4096 bit generated by keytool in a JKS then converted using keytool to P12. I'm using Smart Card Shell v3.17.453 and following the directions from https://vessokolev.blogspot.com/2019/06/smartcard-hsm-usb-token-using-smart.html
$ keytool -genkey \
-keystore keystore.jks -alias foo \
-keyalg RSA -keysize 2048 -sigalg SHA256withRSA \
-validity 10000 -storepass:env KEY_STORE_PASS -keypass:env KEY_PASS \
-dname "CN=foo, OU=Test" -J-Duser.language=en
$ keytool -importkeystore \
-srckeystore keystore.jks -srcalias foo -srcstorepass:env KEY_STORE_PASS -srckeypass:env KEY_PASS \
-destkeystore keystore.p12 -deststoretype PKCS12 -deststorepass:env KEY_STORE_PASS -destkeypass:env KEY_PASS
Here's the error:
Importing key and certificate...
GPError: Card (CARD_INVALID_SW/27013) - "Unexpected SW1/SW2=6985 (Checking error: Condition of use not satisfied) received" in /home/hans/scsh/sc-hsm/SmartCardHSM.js#1348
at /home/hans/scsh/sc-hsm/SmartCardHSM.js#1348
at /home/hans/scsh/sc-hsm/HSMKeyStore.js#300
at /home/hans/keymanager/keymanager.js#2118
at /home/hans/keymanager/keymanager.js#2272
There must be something wrong here: The HSM 2 is a SmartCard-HSM 4K which is version 3.x. If version 2.5 is the latest version offered for your device, then you have a HSM 1, which actually is a SmartCard-HSM EA+ version based on an older chip. That chip does not support 4K keys. However your keytool steps generate a 2048 bit key anyway.
Tried your sequence myself and it worked as expected:
>Initializing, please wait...
Initializing complete
Derive DKEK share encryption key (Step 1 of 3)...
Derive DKEK share encryption key (Step 2 of 3)...
Derive DKEK share encryption key (Step 3 of 3)...
New DKEK share written to /home/asc/share/projects/workspace_scsh/passwd.pbe
Derive DKEK share encryption key (Step 1 of 3)...
Derive DKEK share encryption key (Step 2 of 3)...
Derive DKEK share encryption key (Step 3 of 3)...
Derive DKEK share encryption key (Step 1 of 3)...
Derive DKEK share encryption key (Step 2 of 3)...
Derive DKEK share encryption key (Step 3 of 3)...
[0] Version: 3
SerialNumber: 1396963484
IssuerDN: OU=Test,CN=foo
Start Date: Wed Aug 05 17:21:17 CEST 2020
Final Date: Sun Dec 22 16:21:17 CET 2047
SubjectDN: OU=Test,CN=foo
Public Key: RSA Public Key [f2:dc:67:7d:f8:91:79:d9:02:ea:99:58:37:6d:0c:4f:aa:a7:7a:4c]
modulus: b2507838004038fe9a44776ebedc334d5f40d94bcc86d91c604f4f053a4b94483381bd4c2be12c7a4c58ce53c572985e9f95faaa753f8f7ac27badb1349da6aefc8d8504fc117dd26610905fd257f512e209823a5a9b23dcae5d72c9135352de7376eb9a63d0990c67a132b9fa37ea08c7ab7629971c185bb59206eaaa17de25d24e8c28b703721e7b598b1b58f6f1fe033a4180dfe1e107d16bcc5378744deab7f160b5ad9ef47d0327de36fbf686470b7e6eca8bd77b4c9db6ad228ef02dcf3643448a86889b31310511ab978ba23f7d124708e1680e16d4d9d9a5c34c444b1d29c556a1704b094d79d5603613c167432374ef79d8c291187a6b1ca33983af
public exponent: 10001
Signature Algorithm: SHA256WITHRSA
Signature: 5e275322815512b71aac7eeaedad0123e1504a4b
425de2720d1ae8ab491316f4be1cee7fb3a8641b
8b2dcbd75d4b178cd0502e7f83f2269f8e1c002a
adda16961a64272718769e649e17823518209ec1
b553b2087c81cb95add7ad5b71dd12ab4ec73d6c
a5d015838113843f6498f2955d0650e6bcadf5c5
07a3d0c5a1df230213df7102e742e72a2af8cbef
28495933b3bcf4a6f765c4f7efdca812d402190e
b95c48076e2da658ee1469fcf28323c4ad3ba915
e8991e6b409fc9631f069f5ae6a035b1f635657e
8cb8493c4d15d11c666c93a6b0ac4ab3959bf6b6
a7aa81f69658abf7da6f35aceac546cdbd3488b7
14710b5af45832592bf067dbc2a929fc
Extensions:
critical(false) 2.5.29.14 value = DER Octet String[20]
Importing key and certificate...
Import completed
Things you could take a look at:
- Did you initialize the SmartCard-HSM ?
- Did you specify to use a DKEK ?
- Did you generate a DKEK share ?
- Did you import the DKEK share after initializing the device (The DKEK node must show the KCV) ?
- Did you use the same DKEK share in initialization and import ?
- Yes, I've initialized the HSM many times.
- Yes, I did the DKEK part as per that blog post
- Yes, I generated the DKEK share.
- Yes, the DKEK node shows up
- yes, I've been deleting old DKEK share files
I have had a hard time confirming which exact hardware it is. pkcs11-tool tells me this one supports RSA 1024-4096:
$ pkcs11-tool -T
Available slots:
Slot 0 (0x0): Nitrokey Nitrokey HSM (010000000000000000000000) 00 00
token label : UserPIN (SmartCard-HSM)
token manufacturer : www.CardContact.de
token model : PKCS#15 emulated
token flags : login required, rng, token initialized, PIN initialized
hardware version : 24.13
firmware version : 2.5
serial num : DENK0200570
pin min/max : 6/15
$ pkcs11-tool -M
Using slot 0 with a present token (0x0)
Supported mechanisms:
SHA-1, digest
SHA256, digest
SHA384, digest
SHA512, digest
MD5, digest
RIPEMD160, digest
GOSTR3411, digest
ECDSA, keySize={192,521}, hw, sign, other flags=0x1d00000
ECDSA-SHA1, keySize={192,521}, hw, sign, other flags=0x1d00000
ECDH1-COFACTOR-DERIVE, keySize={192,521}, hw, derive, other flags=0x1d00000
ECDH1-DERIVE, keySize={192,521}, hw, derive, other flags=0x1d00000
ECDSA-KEY-PAIR-GEN, keySize={192,521}, hw, generate_key_pair, other flags=0x1d00000
RSA-X-509, keySize={1024,4096}, hw, decrypt, sign, verify
RSA-PKCS, keySize={1024,4096}, hw, decrypt, sign, verify
SHA1-RSA-PKCS, keySize={1024,4096}, sign, verify
SHA256-RSA-PKCS, keySize={1024,4096}, sign, verify
SHA384-RSA-PKCS, keySize={1024,4096}, sign, verify
SHA512-RSA-PKCS, keySize={1024,4096}, sign, verify
MD5-RSA-PKCS, keySize={1024,4096}, sign, verify
RIPEMD160-RSA-PKCS, keySize={1024,4096}, sign, verify
RSA-PKCS-PSS, keySize={1024,4096}, hw, sign
SHA1-RSA-PKCS-PSS, keySize={1024,4096}, sign
SHA256-RSA-PKCS-PSS, keySize={1024,4096}, sign
RSA-PKCS-KEY-PAIR-GEN, keySize={1024,4096}, generate_key_pair
If this really is the older hardware, then perhaps this isn't related to the 4096 issue then. I meant to set the key size above to 4096, since the keys I need are actually 4096. But I reran the procedure with 2048:
$ keytool -list -keystore scsh3.17.453/asdfasdf.p12 -v
Enter keystore password:
Keystore type: PKCS12
Keystore provider: SUN
Your keystore contains 1 entry
Alias name: foo
Creation date: Aug 5, 2020
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=foo, OU=Test
Issuer: CN=foo, OU=Test
Serial number: 4c8160a6
Valid from: Wed Aug 05 17:51:58 CEST 2020 until: Sun Dec 22 16:51:58 CET 2047
Certificate fingerprints:
SHA1: 1D:A0:10:0A:F7:C9:65:B3:1C:59:FF:C1:C0:1F:F3:1A:C6:CD:52:58
SHA256: 2A:01:F4:93:FE:B9:6A:92:51:A7:6C:E3:8A:73:64:C3:AE:8C:98:46:F9:08:E4:37:4A:6E:95:ED:57:40:FF:A4
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 2048-bit RSA key
Version: 3
Extensions:
#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 87 D0 22 69 0F DE E5 87 05 5A 1E DB E1 95 8F 1B .."i.....Z......
0010: D6 0E FE 7A ...z
]
]
*******************************************
*******************************************
Then the log from SmartCardShell:
Running setup script config.js ...
Smart Card Shell Scripting Engine (scdp4j) 3.17.355
----------------------------------------------------------------------------
(c) 2005-2016 CardContact Systems GmbH, Minden, Germany (www.cardcontact.de)
Enter 'help' for a command overview or 'quit' to close the shell
>load("keymanager/keymanager.js");
SmartCard-HSM Version 2.5 on JCOP 2.4.1r3 Free memory 32767 byte (at least)
Issuer : CVC id-SC-HSM DICA CAR=DESRCACC100001 CHR=DEDINK0200001 CED=May 29, 2017 CXD=May 28, 2025
Device : CVC id-SC-HSM Device CAR=DEDINK0200001 CHR=DENK020057000000 CED=August 5, 2020 CXD=May 28, 2025
-------------------------------------------------------------------
Please right-click on nodes in the outline to see possible actions.
For most operations you will need to authenticate first using a
mechanism from the User PIN context menu.
>Initializing, please wait...
Initializing complete
Derive DKEK share encryption key (Step 1 of 3)...
Derive DKEK share encryption key (Step 2 of 3)...
Derive DKEK share encryption key (Step 3 of 3)...
New DKEK share written to /home/hans/DKEK-share.pbe
Derive DKEK share encryption key (Step 1 of 3)...
Derive DKEK share encryption key (Step 2 of 3)...
Derive DKEK share encryption key (Step 3 of 3)...
[0] Version: 3
SerialNumber: 1283547302
IssuerDN: OU=Test,CN=foo
Start Date: Wed Aug 05 17:51:58 CEST 2020
Final Date: Sun Dec 22 16:51:58 CET 2047
SubjectDN: OU=Test,CN=foo
Public Key: RSA Public Key [da:00:74:5a:80:c4:33:7e:6d:1a:09:c2:b0:0e:d8:79:ec:60:00:7b]
modulus: 844ab1defb2804bb8766bf3c4731434a4ec5a7e5e1103c0a9957d0647d96508e9b55ce190c78a920271e6568f9afeae848c594f77536c75268637a3857158109a389ebfdc7a999a988642377f53366f988597e7720970ce556b54200adc6beb4ca17d0c43c035e9289c746620a808962ad967f80179b5807d0577be805402a44ad1514995cba096e36724f35035dfc645613cd0fd058be4a829aabe43fd55fa4a308ee69dff86ab9116cdb54542ff750c43a23c3eabc4370d318cb1bab927b1c6696e8828351ed90ec72fc5277075594c350f1d14e91392aa46850b5716a44c64d0f4dc46e0a719a7011c39deb6e84a33146a7823aeb25daebee0e6ff39d66b7
public exponent: 10001
Signature Algorithm: SHA256WITHRSA
Signature: 7149d49425682dbabda57f38c13387881ee73045
c00ee96150584ebe54c8aaf0e6ffd2d06259e0ab
9d785cd929fd99aadc75a5051dffbd5a90d23d8e
3b053083642dfe2370d9483bc87f7bf662ffb9c2
8e3feeaebdc8b6d5f220edc66c21bef745bfb184
d15d87ccb1c7b4bb9b16c8d9eeb5d5bcaff7c8ad
ebb7fb093def6da7ded220c8c5de2ca7bbfe232e
13d33048304769f481df73366cd8558ee5d7250a
597946140b1ff33ca75f0d74291c14b289e3b349
4ed35d1faec43547b3fd156dcec01d0c71812c00
9754a2a874bbfa4266e764fcd5e3fdfcffa66677
7aecc76be7375c3d9a2988b830fb72d19d67e787
ea1128569d6cfd11af1b3c77352e0b77
Extensions:
critical(false) 2.5.29.14 value = DER Octet String[20]
Importing key and certificate...
GPError: Card (CARD_INVALID_SW/27013) - "Unexpected SW1/SW2=6985 (Checking error: Condition of use not satisfied) received" in /home/hans/scsh/sc-hsm/SmartCardHSM.js#1348
at /home/hans/scsh/sc-hsm/SmartCardHSM.js#1348
at /home/hans/scsh/sc-hsm/HSMKeyStore.js#300
at /home/hans/keymanager/keymanager.js#2118
at /home/hans/keymanager/keymanager.js#2272
Maybe I'm missing something from your post.
You need to use the same DKEK share for initialization and for import. I see only two steps where the DKEK share is handled.
The principle is
- Generate a DKEK share - that is basically a password encrypted AES-256 key in a file on your disk
- Initialize the SmartCard-HSM to use a DKEK
- Import the share from 1 into the SmartCard-HSM
Now the SmartCard-HSM internally has a 256-Bit AES key for wrapping and unwrapping
- Import a key from PKCS#12. The script basically recreates the DKEK that is also in the device and encrypts the key from the PKCS#12 container. The encrypted key is then imported into the SmartCard-HSM, there encrypted with the key imported in 3 and made available for subsequent use.
I guess in your scenario you left step 3 out.
Btw. the Smart Card Shell shows 2.5. You can also run sc-hsm-tool from OpenSC to see the version.
Ok, now its clear that its not an HSM 2, I wish I had found https://support.nitrokey.com/t/how-do-i-know-if-i-have-an-hsm1-or-hsm2/2553 before, it was not easy to identify it. So its clear the problems that I'm having are not related to 4096 bit. Sorry for posting in the wrong place. I'll follow up on the support forum.
@CardContact
I have a similar issue with a NitroKey HSM 2
Using reader with a card: Nitrokey Nitrokey HSM
Version : 3.4
Config options :
User PIN reset with SO-PIN enabled
SO-PIN tries left : 15
User PIN tries left : 3
DKEK shares : 1
DKEK key check value : ECC5BD02F7B065B8
I'm using Smart Card Shell 3.17.502 on MacOS bug Sur 11.2.3
I can import .p12s with 2,048 bit keys but not one with a 4,096 bit key, I'm using the same procedure and the same DKEK share, both .p12 are from the same source https://www.digicert.com
This is the output:
Importing key and certificate...
GPError: Card (CARD_INVALID_SW/27268) - "Unexpected SW1/SW2=6A84 (Checking error: Not enough memory space in the file) received" in /Users/carlos/Downloads/scsh3.17.502/scsh/sc-hsm/SmartCardHSM.js#1372
at /Users/carlos/Downloads/scsh3.17.502/scsh/sc-hsm/SmartCardHSM.js#1372
at /Users/carlos/Downloads/scsh3.17.502/scsh/sc-hsm/HSMKeyStore.js#306
at /Users/carlos/Downloads/scsh3.17.502/keymanager/keymanager.js#2196
at /Users/carlos/Downloads/scsh3.17.502/keymanager/keymanager.js#2350
Please let me know if I can provide any more data to help fixing this issue.
((enjoy)) Carlos Rodriguez
Did you reset the card between initialization and key import ? There is an OOM condition with large RSA keys if device initialization and import is done in the same session. Entering "r" in the scsh or unplug/plug the device should help.
Hi @CardContact
Yes I tried that after reading this issue comments. but unfortunately it does not help locally. but I will try it again
Hi @CardContact
If I reset the card after I import the DKEK share there is no effect and have the same error, but if I reset the card right after initialize and before importing the DKEK share then it is even worst as it does not let me import it
>Initializing, please wait...
Initializing complete
r
0000 3B DE 18 FF 81 91 FE 1F C3 80 31 95 54 48 53 4D ;.........1.THSM
0010 31 73 80 21 40 95 07 1C 1s.!@...
TS : 3B Direct logic
TO : DE K = 14 byte [historical characters]
TA1 : 18 Fi/f = 372/ 5 [clock rate conversion factor / max. frequency (MHz)]
Di = 12 [bit rate conversion factor]
TC1 : FF N = 255 etu [extra guardtime]
TD1 : 81 T = T=1 [protocol type]
TD2 : 91 T = T=1 [protocol type]
TA3 : FE IFSC = 254 [information field size]
TD3 : 1F T = GLO [protocol type]
TA4 : C3 X = No Pref [clock stop indicator]
U = A and B [class indicator (5, 3, 1.8 V)]
Card service indicator :
Application selection by full DF name
EF.DIR / EF.ATR access with READ RECORD
Card without MF
Card issuer data : 48534D31 HSM1
Card capabilities :
DF selection by full DF name
Proprietary write
Data unit size is 8 bits
'FF' means padding in BER.TLV coded data fields
Extended Le and Lc fields supported
Status byte(s) : 07 .
>Derive DKEK share encryption key (Step 1 of 3)...
Derive DKEK share encryption key (Step 2 of 3)...
Derive DKEK share encryption key (Step 3 of 3)...
GPError: Card (CARD_INVALID_SW/27904) - "Unexpected SW1/SW2=6D00 (Checking error: Invalid instruction (0)) received" in /Users/carlos/Downloads/scsh3.17.502/scsh/sc-hsm/SmartCardHSM.js#1304
at /Users/carlos/Downloads/scsh3.17.502/scsh/sc-hsm/SmartCardHSM.js#1304
at /Users/carlos/Downloads/scsh3.17.502/scsh/sc-hsm/SmartCardHSM.js#1343
at /Users/carlos/Downloads/scsh3.17.502/keymanager/keymanager.js#1857
at /Users/carlos/Downloads/scsh3.17.502/keymanager/keymanager.js#2356
Hi @CardContact
I see, I tried again with this steps...
- Open Key Manager
- Initialize the device
- Reset Card
- Open Key Manager
- Login with User PIN
- Import DKEK Share
- Import .p12
Still getting the original GPError: Card (CARD_INVALID_SW/27268) - "Unexpected SW1/SW2=6A84 (Checking error: Not enough memory space in the file) received"
Hi @carlosfrodriguez I was stuck with the same problem, but then tried resetting the card and reloading the keymanager after importing the DKEK share and getting a successful import now. Here are my steps to reproduce:
- Open Key Manager
- Initialize the device
- Import DKEK Share
- Reset Card
- Open Key Manager
- Login with User PIN
- Import .p12
note the changed order. Have to do any further testing yet. Hope this helps
