SW_CONDITIONS_NOT_SATISFIED when reading RSA key pair or executing RSASign operations

[danbissler]

I've been working with the OM-SE050ARD demo board connected via the external I2C interface to a proprietary circuit card. I have generated an RSA-2048 key pair, and according to the APDU specification, I should be able to read the public key using the ReadSecureObject command and sign data using the RSASign command.

I have run tests in both a session-less and UserID session context. I have tried assigning policies to the keys, but from my understanding of the documentation, the default policy should be adequate (default secure object policy is full access, except attestation. This would mean read, write, generate, delete, sign, verify, encrypt, decrypt, etc.) as I only am attempting to read and sign right now. 

To read the RSA public key modulus, the APDU command is as follows

80 02 00 00 09 41 04 00 00 00 01 44 01 00 00

CLA = 80

INS = INS_READ

P1 = P1_DEFAULT

P2 = P2_DEFAULT

Lc = 09

TAG_1 04 00 00 00 01 (object id = 0x00000001)

TAG_4 01 00 (RSA_COMP_MOD)

Lc = 0

TAG_2, TAG_3, TAG_5-TAG_7 are optional and do not apply to RSA keys

In response I receive 69 85, SW_CONDITIONS_NOT_SATISFIED. I get this regardless of whether the keys have the default policy or an explicit policy set. 

Furthermore, when I try to sign some random data, I get the same result of SW_CONDITIONS_NOT_SATISFIED. The command for that is as follows:

80 03 0c 09 2b 41 04 00 00 00 01 42 01 28 43 20 69 47 56 c0 a4 1d 6b 60 69 43 74 63 1c a3 80 7b 87 f3 5b 48 9e dd 82 9c 75 6b b3 32 ba e6 17 5d 00

CLA = 80

INS = INS_CRYPTO

P1 = P1_SIGNATURE

P2 = P2_SIGN

Lc = 2B

TAG_1 04 00 00 00 01 (object id = 0x00000001)

TAG_2 01 28 (RSASignatureAlgo = RSA_SHA_256_PKCS1)

TAG_3 20 69 47 56 c0 a4 1d 6b 60 69 43 74 63 1c a3 80 7b 87 f3 5b 48 9e dd 82 9c 75 6b b3 32 ba e6 17 5d (data)

Le 00

Here I get SW_CONDITIONS_NOT_SATISFIED as well regardless of whether I use the default policy or an explicitly set policy.

The applet version is 3.1.0 and applet config is 0x6FFF.

What other conditions would need satisfied to read the RSA public key components or sign using a generated RSA private key?

[Kan_Li]

Hi Daniel,

Did you create the RSA key pair correctly? 

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.

We provide an example for RSAsign operation as well, you may refer to "ex_sss_rsa" for details.

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

[danbissler]

The keys should have been generated on chip. The command APDU was as follows

80 01 62 4f 0a 41 04 00 00 00 01 42 02 08 00

CLA = 80

INS = 01 (INS_WRITE)

P1 = 62 (P1_KEY_PAIR | P1_RSA)

P2 = 4F (P2_RAW, according to AN 123413 Rev 2.8, "P2_RAW only in case P1KeyType = P1_KEY_PAIR and TLV[TAG_3] until TLV[TAG_10] must be empty and the SE050 must generate a raw RSA key pair")

LEN = 0A

TLV[TAG_1] (object ID), len = 4, 00 00 00 01

TLV[TAG_2] (RSABitLength), len 2, 80 00 (2048-bit keys)

No policy was set.

This also looks like it would match the behavior of sss_se05x_key_store_generate_key where Se05x_API_WriteRSAKey is called with SE05X_RSA_NO_p/q/dp/dq/qInv/pubExp/priv/pubMod are passed in.

Is this not the correct way to generate keys on chip?

[Kan_Li · Accepted solution]

Hi Daniel,

The issue is due to the answer to read the public key of RSA2028 is 262 bytes long - so it does not fit inside a standard length APDU and it needs to be sent as extended length APDU to allow response longer than 256 bytes as LC and LE bytes are now longer:

800200000000094104000000014401000000

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

[Kan_Li]

The key generation should be ok, and I can reproduce your issue here but RSA_COMP_PUB_EXP can be successfully fetched.

smCom:DEBUG:H> (Len=4)
01 00 00 0F
smCom:DEBUG:Tx> (Len=15)
80 02 00 00 09 41 04 00 00 00 01 44 01 01 00
smCom:DEBUG:<H (Len=4)
01 00 00 09
smCom:DEBUG:<Rx (Len=9)
41 82 00 03 01 00 01 90 00

I will investigate it further and let you know the result.

Thanks for your patience!

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