Importing 4096 bit RSA keys from P12 into SmartCard-HSM 4K Mini-SIM Card (3.3) failed with SCSH v3.15.388 about scsh-scripts

[Emantor]

We are seeing the same issue on NitroKey HSM.

[CardContact]

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.

[jluebbe]

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.

[CardContact]

Can you post a trace of the last 5 APDUs in the "trace" tab ?

[CardContact]

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).

[jluebbe]

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.

[jluebbe]

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

[CardContact]

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.

[jluebbe]

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:

1. development keys loaded into SoftHSM2 (test PKCS#11 client implementation and normal development)
2. development keys imported into Nitrokey HSM (testing usage of a real token with the same locked devices as in 1.)
3. 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?

[jluebbe]

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.

[CardContact]

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.

[danielliang]

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.

[Ryetschye]

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!

[eighthave]

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

[CardContact]

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:

1. Did you initialize the SmartCard-HSM ?
2. Did you specify to use a DKEK ?
3. Did you generate a DKEK share ?
4. Did you import the DKEK share after initializing the device (The DKEK node must show the KCV) ?
5. Did you use the same DKEK share in initialization and import ?

[eighthave]

1. Yes, I've initialized the HSM many times.
2. Yes, I did the DKEK part as per that blog post
3. Yes, I generated the DKEK share.
4. Yes, the DKEK node shows up
5. 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

[CardContact]

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

1. Generate a DKEK share - that is basically a password encrypted AES-256 key in a file on your disk
2. Initialize the SmartCard-HSM to use a DKEK
3. Import the share from 1 into the SmartCard-HSM

Now the SmartCard-HSM internally has a 256-Bit AES key for wrapping and unwrapping

4. 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.

[CardContact]

Btw. the Smart Card Shell shows 2.5. You can also run sc-hsm-tool from OpenSC to see the version.

[eighthave]

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.

[carlosfrodriguez]

@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

[CardContact]

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.

[carlosfrodriguez]

Hi @CardContact

Yes I tried that after reading this issue comments. but unfortunately it does not help locally. but I will try it again

[carlosfrodriguez]

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

[CardContact]

You need to reload the key manager with CTRL-M after doing a reset.

[carlosfrodriguez]

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"

[isc-rschu]

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