Re:SGX Remote Attestation 0x2003 error at sgx_msg2_proc_ex

krmal · ‎10-15-2020

Hello,

Basing on this code sample I am trying to implement the Service Provider in Node JS, which communicates with the ISV app from the RA example. My problem is, the msg2 created by the SP is never accepted at the ISV app (see the logs below):

Sent MSG1 to remote attestation service provider. Received the following MSG2:
176 bytes:
{
0x2, 0x0, 0x0, 0xa8, 0x0, 0x0, 0x0, 0x0, 
0x7b, 0x7f, 0xe3, 0x71, 0x6, 0x6f, 0xf2, 0xd4, 
0x86, 0x14, 0xa6, 0x87, 0x1a, 0x50, 0x5f, 0x9b, 
0x13, 0x11, 0x11, 0x7a, 0x73, 0xaa, 0x8a, 0x80, 
0xad, 0xbc, 0xcb, 0x5a, 0xdb, 0xf4, 0x77, 0x2f, 
0x5c, 0xb9, 0x12, 0xf3, 0x20, 0x47, 0x34, 0x88, 
0x1, 0x75, 0x46, 0xab, 0xb1, 0x24, 0x8d, 0x49, 
0xa0, 0xab, 0x73, 0xf9, 0xe6, 0x43, 0x74, 0x4b, 
0xe9, 0x1b, 0x5b, 0xba, 0x67, 0xd, 0x5, 0x16, 
0xc8, 0xc5, 0x61, 0x21, 0x81, 0x8e, 0x4f, 0x0, 
0xfe, 0x4a, 0xb8, 0x68, 0x38, 0x9f, 0x30, 0x59, 
0x0, 0x0, 0x1, 0x0, 0xea, 0x50, 0x1c, 0xcb, 
0x72, 0xa5, 0x59, 0xb3, 0x35, 0x46, 0xa3, 0x4d, 
0xd1, 0xe1, 0xf8, 0xb2, 0x17, 0x8e, 0xea, 0x40, 
0xd0, 0x65, 0xc3, 0x54, 0xc, 0x67, 0xc9, 0x10, 
0x34, 0xcc, 0x6f, 0x49, 0x11, 0xa9, 0x90, 0x91, 
0xba, 0x63, 0x6a, 0x70, 0xd5, 0xed, 0xe2, 0xa4, 
0x3c, 0x57, 0x87, 0x84, 0x92, 0x13, 0xc0, 0x5e, 
0x28, 0x28, 0x5e, 0x46, 0x31, 0xf8, 0x80, 0x84, 
0x7, 0xaa, 0x99, 0x0, 0xb5, 0x3f, 0x5d, 0x23, 
0x9f, 0x55, 0x6b, 0x28, 0x9, 0x8, 0xe9, 0x5d, 
0xf6, 0x4a, 0x9a, 0xfe, 0x0, 0x0, 0x0, 0x0 
}

A more descriptive representation of MSG2:
RESPONSE TYPE: 0x2
RESPONSE STATUS: 0x0 0x0
RESPONSE BODY SIZE: 168
MSG2 gb - 64 bytes:
{
0x7b, 0x7f, 0xe3, 0x71, 0x6, 0x6f, 0xf2, 0xd4, 
0x86, 0x14, 0xa6, 0x87, 0x1a, 0x50, 0x5f, 0x9b, 
0x13, 0x11, 0x11, 0x7a, 0x73, 0xaa, 0x8a, 0x80, 
0xad, 0xbc, 0xcb, 0x5a, 0xdb, 0xf4, 0x77, 0x2f, 
0x5c, 0xb9, 0x12, 0xf3, 0x20, 0x47, 0x34, 0x88, 
0x1, 0x75, 0x46, 0xab, 0xb1, 0x24, 0x8d, 0x49, 
0xa0, 0xab, 0x73, 0xf9, 0xe6, 0x43, 0x74, 0x4b, 
0xe9, 0x1b, 0x5b, 0xba, 0x67, 0xd, 0x5, 0x16 
}
MSG2 spid - 16 bytes:
{
0xc8, 0xc5, 0x61, 0x21, 0x81, 0x8e, 0x4f, 0x0, 
0xfe, 0x4a, 0xb8, 0x68, 0x38, 0x9f, 0x30, 0x59 
}
MSG2 quote_type : 0
MSG2 kdf_id : 1
MSG2 sign_gb_ga - 64 bytes:
{
0xea, 0x50, 0x1c, 0xcb, 0x72, 0xa5, 0x59, 0xb3, 
0x35, 0x46, 0xa3, 0x4d, 0xd1, 0xe1, 0xf8, 0xb2, 
0x17, 0x8e, 0xea, 0x40, 0xd0, 0x65, 0xc3, 0x54, 
0xc, 0x67, 0xc9, 0x10, 0x34, 0xcc, 0x6f, 0x49, 
0x11, 0xa9, 0x90, 0x91, 0xba, 0x63, 0x6a, 0x70, 
0xd5, 0xed, 0xe2, 0xa4, 0x3c, 0x57, 0x87, 0x84, 
0x92, 0x13, 0xc0, 0x5e, 0x28, 0x28, 0x5e, 0x46, 
0x31, 0xf8, 0x80, 0x84, 0x7, 0xaa, 0x99, 0x0 
}
MSG2 mac - 16 bytes:
{
0xb5, 0x3f, 0x5d, 0x23, 0x9f, 0x55, 0x6b, 0x28, 
0x9, 0x8, 0xe9, 0x5d, 0xf6, 0x4a, 0x9a, 0xfe 
}
MSG2 sig_rl - 
( null )

Error, call sgx_ra_proc_msg2_ex fail. p_msg3 = 0x(nil) [main]. Ret: 0x00002003
Call enclave_ra_close success.
Enter a character before exit ...

I double-checked the SPID and my subscription, which is unlinkable. The IAS returns empty SigRL with code 200 (sigrl_size is given as 00000000). Regarding the sign operation at the SP side, I use SP private key from the example (denoted g_sp_priv_key in service_provider.cpp), but the signature is invalid.

Since I have already gone through endianness checks at the SP side, I would first ask, if I am correctly generating the SigSP: signing the concatenated public keys of SP and the client (this order, Little Endian), with the SP "hard-coded" private key? I am applying the SP private key byte array "as-is", i.e. I do not change the endianness.

Thank you in advance for help.

Best Regards,

Kris

JesusG_Intel · ‎10-15-2020

Hello Kris,

We are looking into your issue. Please stay tuned.

JesusG_Intel · ‎10-16-2020

Hello Kris,

The problem may be in the endianness or components of the signature itself.

Try running the sample's SP code, which should work correctly, and compare its MSG2 components to what your NodeJS-based SP code is generating.

krmal · ‎10-22-2020

Dear Jesus,

Yes, the problem persists. Sorry for late message. I have taken my time trying to debug the endianness issues, both with the original version of RemoteAttestation in SampleCode, and with the standalone client and server found here. The output of the client is as follows:

./run-client --verbose --debug --pubkey=38eb4b1c62e85bb01d73609ceeaa3d3eadae3037623ad085bf6e52177a8a1272065e141110c83ca8289af203c9bdb724e214c6e741b7ee267b57e250d94081d4 -z
+++ using supplied public key

---- Msg0 Details ----------------------------------------------------------
Extended Epid Group ID: 00000000
----------------------------------------------------------------------------

---- Msg1 Details ----------------------------------------------------------
msg1.g_a.gx = 9950d2a4069698315e11bae7ba7c2b27772b4e911d9aff316eec64c7b3bc65cb
msg1.g_a.gy = ba8d01a0a2357647739f005e216cb445ca64370df47d86ee4dce01e8db112c99
msg1.gid    = c70a0000
----------------------------------------------------------------------------

---- Copy/Paste Msg0||Msg1 Below to SP -------------------------------------
000000009950d2a4069698315e11bae7ba7c2b27772b4e911d9aff316eec64c7b3bc65cbba8d01a0a2357647739f005e216cb445ca64370df47d86ee4dce01e8db112c99c70a0000
----------------------------------------------------------------------------
Waiting for msg2
31cc5f3510950fdca9761472ba8c1e5ddf3d20ee6c69d2f69afd929126cb305890fd029163e8eeafb5f2d93be1a5893543ae02f277ac8710f9c583b6930398a5c8c56121818e4f00fe4ab868389f305900000100403299edeb28bfe3c7dcb2b0069daf29213a64c6fde330913ec83036f872641355a7101b8917ed23eb1be4ac2b9285ae6a9fc638b3a8423306f565d0ee280c57c04b9081b1c9a5d21ef0bab92e6a1af300000000

---- read buffer -----------------------------------------------------------
31cc5f3510950fdca9761472ba8c1e5ddf3d20ee6c69d2f69afd929126cb305890fd029163e8eeafb5f2d93be1a5893543ae02f277ac8710f9c583b6930398a5c8c56121818e4f00fe4ab868389f305900000100403299edeb28bfe3c7dcb2b0069daf29213a64c6fde330913ec83036f872641355a7101b8917ed23eb1be4ac2b9285ae6a9fc638b3a8423306f565d0ee280c57c04b9081b1c9a5d21ef0bab92e6a1af300000000
----------------------------------------------------------------------------

---- Msg2 Details ----------------------------------------------------------
msg2.g_b.gx      = 31cc5f3510950fdca9761472ba8c1e5ddf3d20ee6c69d2f69afd929126cb3058
msg2.g_b.gy      = 90fd029163e8eeafb5f2d93be1a5893543ae02f277ac8710f9c583b6930398a5
msg2.spid        = c8c56121818e4f00fe4ab868389f3059
msg2.quote_type  = 0000
msg2.kdf_id      = 0100
msg2.sign_ga_gb  = 403299edeb28bfe3c7dcb2b0069daf29213a64c6fde330913ec83036f872641355a7101b8917ed23eb1be4ac2b9285ae6a9fc638b3a8423306f565d0ee280c57
msg2.mac         = c04b9081b1c9a5d21ef0bab92e6a1af3
msg2.sig_rl_size = 00000000
msg2.sig_rl      = 
----------------------------------------------------------------------------
+++ msg2_size = 168
sgx_ra_proc_msg2: 00002003

Moreover, I got the same error using the ECDSA signatures with elliptic JS library and python ecdsa library. I am out of ideas what to do.

At the same time, I spotted some inconsistencies across the code docs and the CodeSample . In service_provider.h of the RemoteAttestation project I could found:

typedef struct sample_ra_msg2_t
{
    sample_ec_pub_t             g_b;        /* the Endian-ness of Gb is
                                                  Little-Endian*/
    sample_spid_t               spid;       /* In little endian*/
    uint16_t                    quote_type; /* unlinkable Quote(0) or linkable Quote(0) in little endian*/
    uint16_t                    kdf_id;     /* key derivation function id in little endian.
                                             0x0001 for AES-CMAC Entropy Extraction and Key Derivation */
    sample_ec_sign256_t         sign_gb_ga; /* In little endian*/
    sample_mac_t                mac;        /* mac_smk(g_b||spid||quote_type||
                                                       sign_gb_ga)*/
    uint32_t                    sig_rl_size;
    uint8_t                     sig_rl[];
} sample_ra_msg2_t;

Is one supposed to derive the mac INCLUDING KDF_ID (as in the CodeSample description), or WITHOUT (as in the above snippet comment)? I have chosen to include KDF_ID, otherwise got an error; still it is a bit confusing.

Side question: is there any way to enforce exactly the same values of Ga and Gb keys across multiple runs of the example? I know it does not make any sense from the security viewpoint, but would help debugging.

Best Regards,

Kris

JesusG_Intel · ‎10-20-2020

Hello Kris,

Do you still need help with this issue?

JesusG_Intel · ‎10-22-2020

Hello Kris,

We are not sure what is going wrong. Regarding the MAC, according to the key_exchange code, KDF_ID is included: https://github.com/intel/linux-sgx/blob/74b24b69f90dee2638ab646d9090cb286ec8abc9/common/inc/sgx_key_exchange.h#L72

krmal · ‎10-23-2020

Dear Jesus,

May I just ask you to look at the following algorithm and confim that both the flow and the endianness of the variables are correct?

1. Generate SP ECDH keypair (prime256v1 curve, generated at random in JS in Big-Endian). 
2. Compute Gabx as ECDH shared secret, giving Ga (Big-Endian, for the JS library) as foreign public key.
3. Convert Gabx to Little-Endian.
4. Compute KDK as AES128-CMAC of Gabx (in Little-Endian) with zeroes as the key.
5. Compute SMK as AES128-CMAC of [0x01 0x53 0x4d 0x4b 0x00 0x80 0x00] with KDK as the key (KDK endianness remains unchanged).
6. Quote_type = 0x00 (unlinkable).
7. KDF_ID = 0x01.
8. Compute SHA256 digest of Gbx||Gby||Gax||Gay (Gb and Ga in Little-Endian).
9. Compute Sig(Gb_Ga): ECDSA sign of the keys' digest from 8. using the private key from 1.
10. Compute AES128-CMAC of A, A = Gb (Little-Endian) || SPID (unchanged) || 0x0000 || 0x0100 || Sig(Gb_Ga) (Little-Endian)
11. In MSG2, Gb, Quote_type, KDF_ID, Sig(Gb_Ga)_x, Sig(Gb_Ga)_y and SigRL_Size are in Little-Endian. CMAC of A is unchanged.

Thank you for your help.

Best Regards,

Kris

JesusG_Intel · ‎10-23-2020

Hello Kris,

Your algorithm looks good except one small detail. In step 10, your KDF_ID is 0x0100 but it should be 0x01. Is this a typo?

You may also want to look at the section, Debugging a Remote Attestation Service Provider, in the Intel SGX Developer Reference Guide for Windows or Linux.

krmal · ‎10-27-2020

Dear Jesus,

Thanks for your reply. In step 10, I simply wrote KDF_ID as Little-Endian 2-byte integer, thus 0x0100.

I will try to observe what happens with "Debugging a Remote Attestation Service Provider" guidelines.

Regards,

Kris

JesusG_Intel · ‎11-02-2020

Intel is no longer monitoring this thread. If you want a response from Intel in a follow-up question, please open a new thread.