SE050: Reading the modulus of an RSA_KEY_PAIR_CRT object generated on chip

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

SE050: Reading the modulus of an RSA_KEY_PAIR_CRT object generated on chip

Jump to solution
2,921 Views
nicolaponzevero
Contributor II

Hi All,

I’m trying to read the modulus of an RSA_KEY_PAIR_CRT object generated on chip.

I tried several variants of the read command (with and without attestation, using tag 44 to read selectively RSA_KEY_COMPONENT 0 only or reading the entire object) but all return an error.

I also tried to adjust the key generation by using several policies having different combination of R, W, DEL, GEN, SIGN permissions, I tried to completely omit the policy tag, I tried to provide or omit the public exponent (TAG  48), and I tested all the allowed lengths, but also playing on this side I could not avoid getting an error when I later attempted to read the modulus.

Trying to read the public exponent on the same key always succeeded.

The same code (and therefore the same APDU sequences) that fails to read the module of the key I generated succeeds instead on reading it on keys 0xF0000120 0xF0000122 (Cloud Onboarding pre-provisioned keys, RSA4096).

I add below the dump of one of my failed attempts, hoping you can help me to understand what I’m doing wrong.

Thanks and regards

N.

MODULE READING FAILED ATTEMPT DUMP

 

Info about the SE050 Chip used for testing

  • Persistent Free memory          >=32767
  • Transient Free memory (deselect) 592
  • Transient Free memory (reset)   607
  • Chip identifier : 04005001463C20E517FFA6047E5BDA0F6880
  • Applet version and configuration
    • Version  : 3.1.0
    • Sec-box: 010B
    • Features : [ECDAA, ECDSA_ECDH_ECDHE, EDDSA, DH_MONT, HMAC, RSA_PLAIN, RSA_CRT, AES, DES, PBKDF, TLS, MIFARE, I2CM, ECC_ALL, RSA_ALL]
  •      ECDAA ______________ ACTIVE
  •      ECDSA_ECDH_ECDHE ___ ACTIVE
  •      EDDSA ______________ ACTIVE
  •      DH_MONT ____________ ACTIVE
  •      HMAC _______________ ACTIVE
  •      RSA_PLAIN __________ ACTIVE
  •      RSA_CRT ____________ ACTIVE
  •      AES ________________ ACTIVE
  •      DES ________________ ACTIVE
  •      PBKDF ______________ ACTIVE
  •      TLS ________________ ACTIVE
  •      MIFARE _____________ ACTIVE
  •      FIPS_MODE_DISABLED _ off
  •      I2CM _______________ ACTIVE

 

SESSION START

[15:23:28.663]:[DEBUG] SEND [00] WAIT_FOR_CARD

[15:23:28.830]:[DEBUG] RECV [35] {[00 A0 00 00 03 96 04 03 E8 00 FE 02 0B 03 E8 08 01 00 00 00 00 64 00 00 0A 4A 43 4F 50 34 20 41 54 50 4F],RESULT_CODE=NO_ERROR,T=WAIT_FOR_CARD,A=0}

[15:23:29.813]:[DEBUG] SEND [22] APDU_DATA  00 A4 04 00 10 A0 00 00 03 96 54 53 00 00 00 01 03 00 00 00 00 00

[15:23:29.966]:[DEBUG] RECV [07] {[03 01 00 6F FF 01 0B],RESULT_CODE=NO_ERROR,T=APDU_DATA,A=0}

Read chip UID

[15:23:29.991]:[DEBUG] SEND [15] APDU_DATA  80 02 00 00 00 00 06 41 04 7F FF 02 06 00 00

[15:23:30.143]:[DEBUG] RECV [22] {[41 82 00 12 04 00 50 01 46 3C 20 E5 17 FF A6 04 7E 5B DA 0F 68 80],RESULT_CODE=NO_ERROR,T=APDU_DATA,A=0}

ENSURE THE ID 0x70707070 USED FOR TESTING IS FREE

[15:23:30.147]:[DEBUG] SEND [12] APDU_DATA  80 04 00 27 06 41 04 70 70 70 70 00

[15:23:30.299]:[DEBUG] RECV [03] {[41 01 01],RESULT_CODE=NO_ERROR,T=APDU_DATA,A=0}

ID IS IN USE: DELETE THE OBJECT USING IT TO FREE THE ID

     [15:23:30.300]:[DEBUG] SEND [11] APDU_DATA  80 04 00 28 06 41 04 70 70 70 70

     [15:23:30.451]:[DEBUG] RECV [00] {[],RESULT_CODE=NO_ERROR,T=APDU_DATA,A=0}

READ PRE-PROVISIONED KEY 0xF0000122 (Cloud Onboarding key 1 RSA4096)

READ KEY 0xF0000122 EXPONENT W/ATTESTATION by THE DEFAULT ATTESTATION KEY 0xF0000012

[15:23:30.465]:[DEBUG] SEND [45] APDU_DATA  80 22 00 00 00 00 24 41 04 F0 00 01 22 44 01 01 45 04 F0 00 00 12 46 01 21 47 10 34 4C 37 A2 2B 75 00 33 9C DA 6C 2D 94 59 A3 9D 00 00

[15:23:30.617]:[DEBUG] RECV [160] {[41 82 00 03 01 00 01 42 82 00 0F F0 00 01 22 05 01 00 00 00 00 00 00 00 00 03 43 82 00 0C 00 00 00 C5 00 00 00 00 05 D2 F7 80 44 82 00 10 34 4C 37 A2 2B 75 00 33 9C DA 6C 2D 94 59 A3 9D 45 82 00 12 04 00 50 01 46 3C 20 E5 17 FF A6 04 7E 5B DA 0F 68 80 46 82 00 48 30 46 02 21 00 95 AC 2D 8D 95 2D 6C 76 44 69 CE 1A 81 BB 6B 4D C2 EE C0 58 EF AA 16 0B 53 5E 43 EF 3F 4B D0 17 02 21 00 A7 9C F3 39 6E 4B 33 34 B1 DF 34 36 3C 73 DE DA 5C 47 EB 7D 74 FA 9C D6 D8 0E F3 1F 6D 51 EB AE],sw=NO_ERROR,T=APDU_DATA,A=0}

READ KEY 0xF0000122 MODULUS W/ATTESTATION by THE DEFAULT ATTESTATION KEY 0xF0000012

[15:23:30.634]:[DEBUG] SEND [45] APDU_DATA  80 22 00 00 00 00 24 41 04 F0 00 01 22 44 01 00 45 04 F0 00 00 12 46 01 21 47 10 99 C5 F7 5D 53 12 7E 51 02 6C D9 74 AE 5E 56 0D 00 00

[15:23:30.785]:[DEBUG] RECV [668] {[41 82 02 00 BD 9B E0 21 28 04 C8 0A E1 12 6F F7 1B 7F E6 DD 68 6D 66 06 32 D7 45 05 24 91 78 1F E0 7A 24 BE CD B3 D9 1D CF B4 F3 F6 6A E6 B4 07 3F BC 02 AA 3E A5 DA 88 5C 6F 8D 30 12 41 32 CC A9 9C AB F4 1D 2D C8 3C 51 6A BF A8 92 B0 73 00 82 11 B6 72 D7 16 2E 96 FF 21 C2 99 B6 27 61 C0 DA B6 32 C6 75 88 58 E2 E9 95 92 DD BF 0F 6D 22 37 15 5F CE BA A0 BA F6 F7 90 3F EA E0 15 6B 7C 9F F2 E4 65 11 A6 D8 41 42 E0 00 A6 CD 79 7A D9 A3 81 D4 16 96 A2 F9 9C 2C 53 D0 44 54 5C C4 CB 17 05 E9 8C A2 1C A5 9B 3F 30 BB 48 C9 84 03 D6 77 C4 04 77 0E 6A 00 E8 0C 13 36 F5 C7 45 04 B1 C9 C3 42 7C EB 10 A4 C5 CF 5D F1 0C FB AF F9 52 14 46 56 FE 69 F8 71 E1 0A CB C1 6E 52 D5 54 54 0E B7 8A C4 32 01 C3 4E 09 60 62 3F 90 BF D9 68 25 CC 25 06 13 F7 E4 EB E9 E3 97 D5 FE F1 73 EC EC 91 92 C5 32 64 F2 E2 BD E8 85 D7 5A DA 6D EE 97 BF 08 ED 2D 71 66 8D 9C F6 69 12 1F E4 52 A2 96 2B 3F 40 4B 05 AD 32 73 A3 34 E8 39 E5 C6 84 53 C1 4C 1F F1 B0 F4 CD 28 FF ED 26 AD FA 9B 8B BE B2 9D 5B 9A 84 EF B1 41 24 31 88 34 AA 04 3C 51 FC ED 83 F2 5D 0F 97 6A 77 7B D9 F6 F1 29 7A 4C 87 AE 3E D0 38 42 64 3C A9 22 A1 2B 1E C0 BB 70 0F 00 06 4B 60 42 08 9F 24 34 B0 73 60 74 62 3D 5A 6B 8D 2C A4 71 A1 62 9F 11 AD 8B 2F 1C 43 49 DB 6E 71 81 3C 9D AF BB 82 26 FC BA 3D A7 35 BC 20 35 D0 14 F2 61 49 DE 74 3C DE C8 DF B8 36 7A 4D 0C FC D7 CC B1 47 E7 00 4E 2C 9B F1 CD 02 BF 48 49 20 AF 05 C0 74 B2 D3 38 E0 00 A0 BB 84 46 27 A7 5A 92 39 D1 1A 0E AE 99 6A 1B 69 0C 21 A2 C9 CA 58 5A 16 EE 96 2D 38 DE 76 A6 1F A0 2E A5 41 AF 3B D3 41 82 7E 09 02 26 56 70 28 14 FE 5F 75 5D 57 42 82 00 0F F0 00 01 22 05 01 00 00 00 00 00 00 00 00 03 43 82 00 0C 00 00 00 C5 00 00 00 00 05 D5 CE 10 44 82 00 10 99 C5 F7 5D 53 12 7E 51 02 6C D9 74 AE 5E 56 0D 45 82 00 12 04 00 50 01 46 3C 20 E5 17 FF A6 04 7E 5B DA 0F 68 80 46 82 00 47 30 45 02 20 75 55 77 72 EA 75 32 90 7F 56 EE CF 9C 50 79 9B 93 7F 73 66 96 6C 19 1F 4C 28 3B 8C 8C 85 C2 7D 02 21 00 A8 BE 89 4E A6 A5 A3 71 9A B3 58 D0 B9 AB 24 D5 B9 34 FD 11 F5 0E F9 84 33 0C ED 87 5B 8A 79 28],RESULT_CODE=NO_ERROR,T=APDU_DATA,A=0}

Successfully read key 0xF0000122 (4096 bits)

READ PRE-PROVISIONED KEY 0xF0000120 (Cloud Onboarding key 0 RSA4096)

<Removed dump; the operation succeeds in the same way of key 0xF0000122>

Successfully read key 0xF0000122 (4096 bits)

Generate a 512 RSA key having public exponent 65537 with object id 0x70707070

NOTE: All the allowed lengths have been tested with the same result. Policy here is supposed to be ALL (READ+DELETE); several other combination of R,W,DEL,GEN,SIGN have been tested without success. Omitting the policy tag leads to an error as well. The test was repeated in a clear text session and in a platform SCP session with the same results. NXP docs seems to indicate that any policy including ALL (POLICY_ALLOW_READ) should work.

[15:23:31.118]:[DEBUG] SEND [31] APDU_DATA  80 01 62 00 1A 11 09 08 00 00 00 00 00 24 00 00 41 04 70 70 70 70 42 02 02 00 48 03 01 00 01

[15:23:31.270]:[DEBUG] RECV [00] {[],RESULT_CODE=NO_ERROR,T=APDU_DATA,A=0}

Read the public exponent (RSA key component 1) w/attestation on key 0xF0000012

[15:23:31.271]:[DEBUG] SEND [45] APDU_DATA  80 22 00 00 00 00 24 41 04 70 70 70 70 44 01 01 45 04 F0 00 00 12 46 01 21 47 10 D0 18 13 BA DB 0A 80 14 85 CB 15 9F F2 1C A3 6C 00 00

[15:23:31.422]:[DEBUG] RECV [169] {[41 82 00 03 01 00 01 42 82 00 18 70 70 70 70 05 01 00 00 00 00 00 00 00 00 08 00 00 00 00 00 24 00 00 01 43 82 00 0C 00 00 00 C5 00 00 00 00 05 DF 43 F0 44 82 00 10 D0 18 13 BA DB 0A 80 14 85 CB 15 9F F2 1C A3 6C 45 82 00 12 04 00 50 01 46 3C 20 E5 17 FF A6 04 7E 5B DA 0F 68 80 46 82 00 48 30 46 02 21 00 A4 42 B3 D5 F3 CC 01 D2 B5 30 E9 19 2B 5D F6 68 05 6A 56 DF 7C 8F DA 1E C5 28 11 DC E5 6C 9F 39 02 21 00 CB 27 5F 69 68 C4 AF E9 08 6A B6 3B 33 C3 01 5C EF 97 37 67 B8 89 86 DE E7 CA 8B D4 3A 4B CF AB],RESULT_CODE=NO_ERROR,T=APDU_DATA,A=0}

Try to read the module (RSA Key Component 00):

Attempt 1:  Read RSA Key component 00 w/ attestation on key 0xF0000012

[15:23:31.423]:[DEBUG] SEND [45] APDU_DATA  80 22 00 00 00 00 24 41 04 70 70 70 70 44 01 00 45 04 F0 00 00 12 46 01 21 47 10 2F DF EE 17 9B 06 67 5C 96 A1 95 1D 1B 84 BB A3 00 00

[15:23:31.574]:[DEBUG] RECV [00] {[],RESULT_CODE=CONDITIONS_NOT_SATISFIED,T=APDU_DATA,A=0}

Attempt 2:  Read object (no component specified) w/ attestation on key 0xF0000012

[15:23:31.575]:[DEBUG] SEND [42] APDU_DATA  80 22 00 00 00 00 21 41 04 70 70 70 70 45 04 F0 00 00 12 46 01 21 47 10 AF 76 BC E0 27 C6 8C 61 84 4E 99 8E A4 21 B4 AD 00 00

[15:23:31.727]:[DEBUG] RECV [00] {[],RESULT_CODE=WRONG_DATA,T=APDU_DATA,A=0}

Attempt 3:  Read RSA Key component 00 w/o attestation

[15:23:31.727]:[DEBUG] SEND [18] APDU_DATA  80 02 00 00 00 00 09 41 04 70 70 70 70 44 01 00 00 00

[15:23:31.878]:[DEBUG] RECV [00] {[],RESULT_CODE=CONDITIONS_NOT_SATISFIED,T=APDU_DATA,A=0}

Attempt 3:  Read object (no component specified) w/o attestation

[15:23:31.879]:[DEBUG] SEND [15] APDU_DATA  80 02 00 00 00 00 06 41 04 70 70 70 70 00 00

[15:23:32.030]:[DEBUG] RECV [00] {[],RESULT_CODE=WRONG_DATA,T=APDU_DATA,A=0}

SESSION END

[15:23:32.032]:[DEBUG] SEND [00] CLOSE

 

Labels (1)
0 Kudos
Reply
1 Solution
2,839 Views
nicolaponzevero
Contributor II

Hi Kan_Li thanks again,

please confirm my understanding, or correct it as needed.

This is what I got from your answers:

  1. In order to request to the SE050 chip the generation of an RSA key pair the user must send an APDU containing POLICY (optional) object id, and key size only. P1 and P2 must refer to writing an RSA keypair, and no key component is allowed (TAG_3 until TAG_9 must be absent). This includes TAG_8 with no exception.
  2. The generated key - immediately after the generation - will always have public exponent 65537.
  3. No APDU that generates a key that - immediately after the generation - has an exponent different from 65537 exists.
  4. If the generated key is writeable (the policy set used for its creation includes POLICY_OBJ_ALLOW_WRITE) the key can be later overwritten with a different keypair having an arbitrary public exponent. In this case only one component can be set at a time.   

If you confirm all the above statements are correct I will consider the question closed.
Thank you very much for your patience and your help.

Best regards

N.

View solution in original post

0 Kudos
Reply
5 Replies
2,907 Views
Kan_Li
NXP TechSupport
NXP TechSupport

Hi @nicolaponzevero ,

 

Thanks for the information! I am wondering if the following is the only command used to create the RSA key pair.

[15:23:31.118]:[DEBUG] SEND [31] APDU_DATA  80 01 62 00 1A 11 09 08 00 00 00 00 00 24 00 00 41 04 70 70 70 70 42 02 02 00 48 03 01 00 01

Referring to https://www.nxp.com.cn/docs/en/application-note/AN12413.pdf , it says on page 59:

Kan_Li_0-1644483473639.png

Seems just TAG_8 : Public exponent was set up in above command.

 

Please kindly clarify.

 

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

0 Kudos
Reply
2,890 Views
nicolaponzevero
Contributor II

Hi Kan_Li thanks for your answer.

I reviewed the section you referred. My goal was to GENERATE the key pair, so my error was to include TAG_8.
Removing TAG_8 the generation is not inhibited by its presence and the sequence completes successfully.
Thanks for your help.
My question then becomes: is there a way to force a specific public exponent (e.g. 3 or 17) for the generated key?
Thanks again
Nicola

0 Kudos
Reply
2,863 Views
Kan_Li
NXP TechSupport
NXP TechSupport

Hi @nicolaponzevero ,

 

Yes, it is possible if POLICY_OBJ_ALLOW_WRITE is enabled for this object. Please also note only 1 component can be set at a time in this case.

 

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

0 Kudos
Reply
2,840 Views
nicolaponzevero
Contributor II

Hi Kan_Li thanks again,

please confirm my understanding, or correct it as needed.

This is what I got from your answers:

  1. In order to request to the SE050 chip the generation of an RSA key pair the user must send an APDU containing POLICY (optional) object id, and key size only. P1 and P2 must refer to writing an RSA keypair, and no key component is allowed (TAG_3 until TAG_9 must be absent). This includes TAG_8 with no exception.
  2. The generated key - immediately after the generation - will always have public exponent 65537.
  3. No APDU that generates a key that - immediately after the generation - has an exponent different from 65537 exists.
  4. If the generated key is writeable (the policy set used for its creation includes POLICY_OBJ_ALLOW_WRITE) the key can be later overwritten with a different keypair having an arbitrary public exponent. In this case only one component can be set at a time.   

If you confirm all the above statements are correct I will consider the question closed.
Thank you very much for your patience and your help.

Best regards

N.

0 Kudos
Reply
2,823 Views
Kan_Li
NXP TechSupport
NXP TechSupport

Hi @nicolaponzevero ,

 

Yes, most of them are correct, but for item 3, I think you may use multiple WriteRSAkey APDU commands to generate a key/key pair with some predefined components, I think the APDU spec already specifies it as below:

An RSA key creation requires multiple ADPUs to be sent:
• The first APDU must contain:
– Policy (optional, so only if non-default applies)
– Object identifier
– Key size
– 1 of the key components.
• Each next APDU must contain 1 of the key components.
The policy applies only once all key components are set.

 

of course you may alternatively follow the way mentioned in item 4 .  

 

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

0 Kudos
Reply