SE050 WriteECKey Secp256k1 w KEY_PAIR fails with 6a80

[3Nigma]

Hello there!

I'm trying to import a Secp356k1 key pair into a SE050 device using APDU and the operation fails with a SW_WRONG_DATA (0x6a80) response.

What could I be doing wrong?

Here is the complete log:

Se05x_API_WriteECKey: APDU - WriteECKey []
se05x_APDU: Se05x_API_WriteECKey: APDU kSE05x_TAG_MAX_ATTEMPTS["maxAttempt"] = 0x0
se05x_APDU: Se05x_API_WriteECKey: APDU kSE05x_TAG_1["object id"] = 0x7B000300
se05x_APDU: Se05x_API_WriteECKey: APDU kSE05x_TAG_2["curveID"] = 0x10
se05x_APDU: Se05x_API_WriteECKey: APDU kSE05x_TAG_3["privKey"]
41 31 fe 06 6f be e7 36 f6 b6 80 27 00 64 f8 a8 |A1..o..6 ...'.d..
af df 91 c7 29 c1 3c d2 1a 76 33 ab 48 d5 17 4d |....).<. .v3.H..M
se05x_APDU: Se05x_API_WriteECKey: APDU kSE05x_TAG_4["pubKey"]
04 d6 d7 86 ee 29 3d c0 a8 e1 39 90 35 d3 0f d0 |.....)=. ..9.5...
48 fe ee 22 5c 9a ec 7b 1e ab 8d 0e b1 f8 b2 81 |H.."\..{ ........
77 e4 7a bf 33 b4 88 36 f1 86 74 16 62 64 03 82 |w.z.3..6 ..t.bd..
6c ee 7a 3d 7e 60 39 33 f2 39 bd 64 c0 06 51 c8 |l.z=~`93 .9.d..Q.
23                                              |# 
se05x_smCom: smComT1oI2C_TransceiveRaw: APDU Tx>
80 01 61 00 70 41 04 7b 00 03 00 42 01 10 43 00 |..a.pA.{ ...B..C.
20 41 31 fe 06 6f be e7 36 f6 b6 80 27 00 64 f8 | A1..o.. 6...'.d.
a8 af df 91 c7 29 c1 3c d2 1a 76 33 ab 48 d5 17 |.....).< ..v3.H..
4d 44 00 41 04 d6 d7 86 ee 29 3d c0 a8 e1 39 90 |MD.A.... .)=...9.
35 d3 0f d0 48 fe ee 22 5c 9a ec 7b 1e ab 8d 0e |5...H.." \..{....
b1 f8 b2 81 77 e4 7a bf 33 b4 88 36 f1 86 74 16 |....w.z. 3..6..t.
62 64 03 82 6c ee 7a 3d 7e 60 39 33 f2 39 bd 64 |bd..l.z= ~`93.9.d
c0 06 51 c8 23                                  |..Q.# 
smComT1oI2C_TransceiveRaw: APDU Rx<
6a 80

Sanitised APDU (for easier reference):

80 01 61 00 70 41 04 7b 00 03 00 42 01 10 43 00 20 41 31 fe 06 6f be e7 36 f6 b6 80 27 00 64 f8 a8 af df 91 c7 29 c1 3c d2 1a 76 33 ab 48 d5 17 4d 44 00 41 04 d6 d7 86 ee 29 3d c0 a8 e1 39 90 35 d3 0f d0 48 fe ee 22 5c 9a ec 7b 1e ab 8d 0e b1 f8 b2 81 77 e4 7a bf 33 b4 88 36 f1 86 74 16 62 64 03 82 6c ee 7a 3d 7e 60 39 33 f2 39 bd 64 c0 06 51 c8 23

I would also like to mention that I'm able to import ED25519. After that successful import, I've wiped the key so the Object Id is empty prior to the Secp256k1 import trial attempt.

[Kan_Li · Accepted solution]

Hi @3Nigma , 

Please use the CreateECCurve command to create the curve for Secp256k1 and use SetECCurveParam command to configure this curve, and then try with WriteECKey again. please also make sure the key values comply with this curve.

Hope that makes sense,

Have a great day,
Kan

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[3Nigma]

That worked, thank you!

I ended up porting a lot of the functions described in section 4.8 of AN12413 (EC curve management) from the mini variant to the nano variant.

Following your guidance and doing the calls in the right order/logic I was finally able to do a WriteECKey key-pair with a secp256k1 configuration.

[Kan_Li]

Hi @3Nigma ,

Please kindly check whether Secp256k1 Curve is setup already and ECCurve Parameters are provided, otherwise you have to create it at first. Please also note creating ECCurve by SSS APIs will automatically create the ECCurve with the built-in ECCurve parameters, you may test it with the demo of ex_ecc, by changing kSSS_CipherType_EC_NIST_P to kSSS_CipherType_EC_NIST_K.

Hope that helps,

Have a great day,
Kan

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[3Nigma]

Thank you, @Kan_Li !

I'll have a look, give it a try and reply back after that.

For full context and future reference, I'm using NXP's Plug & Trust Nano Package to create the keypair.

Take care,

V

[3Nigma]

I'm bringing up an update to this: It turns out I was encoding the length of the tag elements wrongly: using 2 bytes instead of 1 since both the privateKey and the publicKey transmitted were, in this scenario, below 0x7F in size.

Now, I get a 0x6985 (SW_CONDITIONS_NOT_SATISFIED) response. I don't know what those conditions might be.

Here are the completed new logs:

se05x_APDU: Se05x_API_WriteECKey: APDU - WriteECKey []
se05x_APDU: Se05x_API_WriteECKey: APDU kSE05x_TAG_MAX_ATTEMPTS["maxAttempt"] = 0x0
se05x_APDU: Se05x_API_WriteECKey: APDU kSE05x_TAG_1["object id"] = 0x7B000210
se05x_APDU: Se05x_API_WriteECKey: APDU kSE05x_TAG_2["curveID"] = 0x10
se05x_APDU: Se05x_API_WriteECKey: APDU kSE05x_TAG_3["privKey"]
41 31 fe 06 6f be e7 36 f6 b6 80 27 00 64 f8 a8 |A1..o..6 ...'.d..
af df 91 c7 29 c1 3c d2 1a 76 33 ab 48 d5 17 4d |....).<. .v3.H..M
cw> cw> [00:00:14.767,200] <dbg> se05x_APDU: Se05x_API_WriteECKey: APDU kSE05x_TAG_4["pubKey"]
04 d6 d7 86 ee 29 3d c0 a8 e1 39 90 35 d3 0f d0 |.....)=. ..9.5...
48 fe ee 22 5c 9a ec 7b 1e ab 8d 0e b1 f8 b2 81 |H.."\..{ ........
77 e4 7a bf 33 b4 88 36 f1 86 74 16 62 64 03 82 |w.z.3..6 ..t.bd..
6c ee 7a 3d 7e 60 39 33 f2 39 bd 64 c0 06 51 c8 |l.z=~`93 .9.d..Q.
23                                              |# 
se05x_smCom: smComT1oI2C_TransceiveRaw: APDU Tx>
80 01 61 00 6e 41 04 7b 00 02 10 42 01 10 43 20 |..a.nA.{ ...B..C 
41 31 fe 06 6f be e7 36 f6 b6 80 27 00 64 f8 a8 |A1..o..6 ...'.d..
af df 91 c7 29 c1 3c d2 1a 76 33 ab 48 d5 17 4d |....).<. .v3.H..M
44 41 04 d6 d7 86 ee 29 3d c0 a8 e1 39 90 35 d3 |DA.....) =...9.5.
0f d0 48 fe ee 22 5c 9a ec 7b 1e ab 8d 0e b1 f8 |..H.."\. .{......
b2 81 77 e4 7a bf 33 b4 88 36 f1 86 74 16 62 64 |..w.z.3. .6..t.bd
03 82 6c ee 7a 3d 7e 60 39 33 f2 39 bd 64 c0 06 |..l.z=~` 93.9.d..
51 c8 23                                        |Q.# 
se05x_smCom: smComT1oI2C_TransceiveRaw: APDU Rx<
69 85 

Please note that I've also switched to using a new ObjectId ( 0x7B000210 ) instead of the previous one ( 0x7B000300 ) just to rule out the possibility that, for some reason, the 0x7B000300 objectId was still in use although I did a DeleteSecureObject on it.

Here is the sanitised, complete, APDU:

80 01 61 00 6e 41 04 7b 00 02 10 42 01 10 43 20 41 31 fe 06 6f be e7 36 f6 b6 80 27 00 64 f8 a8 af df 91 c7 29 c1 3c d2 1a 76 33 ab 48 d5 17 4d 44 41 04 d6 d7 86 ee 29 3d c0 a8 e1 39 90 35 d3 0f d0 48 fe ee 22 5c 9a ec 7b 1e ab 8d 0e b1 f8 b2 81 77 e4 7a bf 33 b4 88 36 f1 86 74 16 62 64 03 82 6c ee 7a 3d 7e 60 39 33 f2 39 bd 64 c0 06 51 c8 23 

Thank you for your interest.