Remote attestation error in HPE platform

[hyunsoo]

Hi all,

I have two machines, both are equipped with Intel CPU. Let me attach brief information about those.

[A]

- CPU: Xeon E-2274G

- Board: HPE Proliant ML30 Gen10 (Updated with latest bios provided in HP official)

[B]

- CPU: i7-8700

- Board: ASUS Z370-A ll

I have had no problem when developing some applications using SGX without remote attestation based on EPID scheme at both A and B. If the application uses remote attestation based on EPID, then It fails in the function sgx_get_extended_epid_group_id().

I ran two examples, one is https://github.com/intel/sgx-ra-sample and another one is sgxsdk/SampleCode/RemoteAttestation. Both examples are successfully run in A, whereas both are failed in B, specifically in the function of sgx_get_extended_epid_group_id().

So, my purpose is to demonstrate remote attestation in A.

1. Is there some cases that cannot run remote attestation in HPE platform?

2. Is there a workaround that can resolve the error of sgx_get_extended_epid_group_id() (the error is 0x4001)

[JesusG_Intel]

Hello Hyunsoo,

According the SGX error list, https://github.com/intel/linux-sgx/blob/master/common/inc/sgx_error.h:

SGX_ERROR_SERVICE_UNAVAILABLE = SGX_MK_ERROR(0x4001), /* Indicates aesm didn't respond or the requested service is not supported */

To resolve this, Start the aesmd service:

$ ps aux | grep -i aesm

$ sudo systemctl start aesmd

$ cat /var/log/syslog | grep -i aesm

Regards,

Jesus G.

Intel Customer Support

[hyunsoo]

Hi JesusG,

Yes I checked meaning of the error but, my aesm is currently working well since other applications using sgx are works. however,  

 cat /var/log/syslog | grep -i aesm

the code above outputs empty.  

[JesusG_Intel]

Hello Hyunsoo,

Please provide verbose logs from both the client and server in the sgx-ra-sample.

Set VERBOSE=1 and DEBUG=1 on both the client and server configs, then attach sp.log and client.log. Be sure to remove any password strings for your user certificate from sp.log before attaching. They will appear as hex strings at the top, and in plain text before contacting IAS.

Regards,

Jesus G.

Intel Customer Support

[hyunsoo]

Hi Jesus, Thanks for your kind response.

Both log files(sp.log and client.log) are empty. Let me attach standard output of two programs.

 The logs of client here.

+++ IAS Primary Subscription Key set to '5ad8........................3e33'
+++ IAS Secondary Subscription Key set to '17a6........................ce59'
+++ Using default CA bundle /etc/ssl/certs/ca-certificates.crt
Using default private key
+++ using private key:

+++ IAS Subscription Key[0]:    
+++ IAS Subscription Key[0] (Hex):   
+++ One-time pad:                       
+++ Encrypted Subscription Key[0]:     


+++ IAS Subscription Key[1]:   
+++ IAS Subscription Key[1] (Hex):     
+++ One-time pad:                     
+++ Encrypted Subscription Key[1]:      

Listening for connections on port 7777
Waiting for a client to connect...
Connection from 127.0.0.1
Waiting for msg0||msg1
protocol error reading msg0||msg1
error processing msg1
Waiting for a client to connect...

And logs of service provider

+++ using default public key
sgx_get_extended_epid_group_id: 00004001

[JesusG_Intel]

Hello Hyunsoo,

It seems that the AESM service is not able to communicate with IAS. Is your system behind a proxy?

If so, configure the proxy as follows (see the bottom of https://github.com/intel/linux-sgx

Configure the Proxy for aesmd Service

The aesmd service uses the HTTP protocol to initialize some services.

If a proxy is required for the HTTP protocol, you may need to manually set up the proxy for the aesmd service.

You should manually edit the file /etc/aesmd.conf (refer to the comments in the file) to set the proxy for the aesmd service.

After you configure the proxy, you need to restart the service to enable the proxy.

[hyunsoo · Accepted solution]

The problem is solved on another platform and I didn't use any proxy. Thanks for your help.

[JesusG_Intel]

This thread has been marked as answered and Intel will no longer monitor this thread. If you want a response from Intel in a follow-up question, please open a new thread.