search

intel / sgx-ra-sample

Other
178 stars 65 forks source link

404 error on getting sigrl #45

Open dinhtta opened 4 years ago

dinhtta commented 4 years ago

I built the latest source successfully. Also got the API key from IAS website.

But got this error (XXXX replaced with my key):

..... +++ Exec: wget --output-document=- --save-headers --content-on-error --no-http-keep-alive --header=Ocp-Apim-Subscription-Key: XXXXXXXXXXX https://api.trustedservices.intel.com/sgx/dev/attestation/v3/sigrl/00000000 --2020-04-22 16:49:47-- https://api.trustedservices.intel.com/sgx/dev/attestation/v3/sigrl/00000000 Resolving api.trustedservices.intel.com (api.trustedservices.intel.com)... 40.87.90.88 Connecting to api.trustedservices.intel.com (api.trustedservices.intel.com)|40.87.90.88|:443... connected. HTTP request sent, awaiting response... 404 Not Found Saving to: ‘STDOUT’

2020-04-22 16:49:48 ERROR 404: Not Found. .....

Is this because the service is down? I tried a few days and the same results.

jmechalas commented 4 years ago

A 404 error from the sigrl function means you are submitting an invalid EPID group ID. The request in your output is for EPID group ID 00000000 which is definitely invalid.

I assume you are using the RA client and not just running wget on the command line. Can you run "client -e" for me on the client system?

dinhtta commented 4 years ago

client -e output 00000000

I assume this is produced by the call xxx_get_msg1() from the client. The Internet say it is because I don't have SGX in HW mode.

But I do have SGX, and I guess guess that it is running in HW mode by seeing this (aesmd is also running):

nm sgx-ra-sample/Enclave/Enclave.so | grep sgx 0000000000008c90 t sgx_accept_forward 0000000000010950 t sgx_cmac128_close 00000000000108f0 t sgx_cmac128_final 0000000000010790 t sgx_cmac128_init 00000000000108a0 t sgx_cmac128_update 00000000000979f0 t sgx_create_report 0000000000012930 t sgx_disp_ippsAES_CMACFinal 0000000000012740 t sgx_disp_ippsAES_CMACGetSize 00000000000127d0 t sgx_disp_ippsAES_CMACInit 0000000000012890 t sgx_disp_ippsAES_CMACUpdate 0000000000012d80 t sgx_disp_ippsBigNumGetSize 0000000000012e20 t sgx_disp_ippsBigNumInit 0000000000013950 t sgx_disp_ippsECCPCheckPoint 00000000000139f0 t sgx_disp_ippsECCPGenKeyPair 0000000000013890 t sgx_disp_ippsECCPGetPoint 0000000000013420 t sgx_disp_ippsECCPGetSize 00000000000134c0 t sgx_disp_ippsECCPInit 0000000000013690 t sgx_disp_ippsECCPPointGetSize 0000000000013730 t sgx_disp_ippsECCPPointInit 0000000000013ac0 t sgx_disp_ippsECCPPublicKey 0000000000013b60 t sgx_disp_ippsECCPSetKeyPair 00000000000137d0 t sgx_disp_ippsECCPSetPoint 0000000000013560 t sgx_disp_ippsECCPSetStd 0000000000013600 t sgx_disp_ippsECCPSetStd256r1 0000000000013c20 t sgx_disp_ippsECCPSharedSecretDH 0000000000013ce0 t sgx_disp_ippsECCPSignDSA 0000000000013db0 t sgx_disp_ippsECCPVerifyDSA 0000000000013020 t sgx_disp_ippsGet_BN 0000000000012ec0 t sgx_disp_ippsGetSize_BN 0000000000012a50 t sgx_disp_ippsHashGetSize_rmf 0000000000012c20 t sgx_disp_ippsHashGetTag_rmf 0000000000012ae0 t sgx_disp_ippsHashInit_rmf 0000000000012cc0 t sgx_disp_ippsHashMessage_rmf 00000000000129d0 t sgx_disp_ippsHashMethod_SHA256_TT 0000000000012b80 t sgx_disp_ippsHashUpdate_rmf 00000000000131a0 t sgx_disp_ippsMod_BN 00000000000132e0 t sgx_disp_ippsPrimeGetSize 0000000000013380 t sgx_disp_ippsPrimeInit 00000000000130e0 t sgx_disp_ippsRef_BN 0000000000012f60 t sgx_disp_ippsSet_BN 0000000000013240 t sgx_disp_ippsSetOctString_BN 00000000000113d0 t sgx_ecc256_calculate_pub_from_priv 0000000000010ec0 t sgx_ecc256_check_point 0000000000010ab0 t sgx_ecc256_close_context 00000000000110c0 t sgx_ecc256_compute_shared_dhkey 0000000000010b40 t sgx_ecc256_create_key_pair 00000000000109c0 t sgx_ecc256_open_context 0000000000011760 t sgx_ecdsa_sign 0000000000011f50 t sgx_ecdsa_verify 0000000000011c00 t sgx_ecdsa_verify_hash 00000000000076c0 t sgx_enclave_ra_close 0000000000007710 t sgx_enclave_ra_get_key_hash 0000000000007b60 t sgx_enclave_ra_init 0000000000007940 t sgx_enclave_ra_init_def 0000000000097d60 t sgx_get_key 0000000000007e50 t sgx_get_report 0000000000010600 t sgx_init_crypto_lib 0000000000010370 t sgx_init_string_lib 0000000000098420 t sgx_is_enclave_crashed 0000000000008360 t sgx_is_outside_enclave 0000000000008310 t sgx_is_within_enclave 0000000000009c10 t sgx_ocall 00000000000083b0 t sgx_ocalloc 00000000000084a0 t sgx_ocfree 000000000000c520 t sgx_ra_close 000000000000b350 t sgx_ra_get_ga 000000000000c3f0 t sgx_ra_get_keys 000000000000bc90 t sgx_ra_get_msg3_trusted 000000000000c3e0 t sgx_ra_init 000000000000c0f0 t sgx_ra_init_ex 000000000000b530 t sgx_ra_proc_msg2_trusted 00000000000084f0 t sgx_read_rand 000000000000a2c0 t sgx_register_exception_handler 0000000000010610 t sgx_rijndael128_cmac_msg 0000000000097b80 t sgx_self_report 00000000000075d0 t sgx_sgx_ra_get_ga 00000000000070b0 t sgx_sgx_ra_get_msg3_trusted 00000000000071c0 t sgx_sgx_ra_proc_msg2_trusted 00000000000121b0 t sgx_sha256_close 0000000000012150 t sgx_sha256_get_hash 0000000000012020 t sgx_sha256_init 00000000000121d0 t sgx_sha256_msg 0000000000012100 t sgx_sha256_update 0000000000010380 t sgx_spin_lock 00000000000103e0 t sgx_spin_unlock 00000000000a7090 D sgx_tcrypto_version 00000000000a7040 D sgx_tkey_exchange_version 00000000000a7010 D sgx_trts_version 00000000000a82c0 D sgx_tservice_version 00000000000a7070 D sgx_tstdc_version 000000000000a400 t sgx_unregister_exception_handler 0000000000097bc0 t sgx_verify_report 000000000000c600 t _Z10derive_keyPK22_sgx_ec256_dh_shared_tPKcjPA16_h 0000000000012240 t _Z13sgx_ipp_newBNPKjiPP9_cpBigNum 0000000000012400 t _Z14sgx_ipp_DRNGenPjiPv 0000000000012450 t _Z19sgx_ipp_newPrimeGeniPP8_cpPrime 0000000000012370 t _Z22sgx_ipp_secure_free_BNP9_cpBigNumi 0000000000099120 r _ZL14sgx_nistp256_r 0000000000008670 t _ZL19sgx_accept_backwardmmm 00000000000a87a0 b _ZZ15sgx_self_reportE7_report

jmechalas commented 4 years ago

Did you ever make progress on this?

The only explanation I can think of here is that the RA sample was built in simulation mode instead of hardware mode. Even if aesmd is running you can still have a binary using the simluation libraries.

nm won't tell you which libraries you linked against because the function names in the simulation libraries are the same as those in the hardware libraries (otherwise sim mode wouldn't mimic hardware mode). Instead, run this:

strings client | grep \.so | grep sgx

balaganapathy-k-8759 commented 4 years ago

I am too receiving 404 error on getting sigrl. client -e returns 00000000 strings client | grep \.so | grep sgx returns /opt/intel/sgxsdk/lib64/libsgx_uae_service.so libsgx_urts.so I guess both of these are hardware libraries. Then what is causing the error? I'm using sgxsdk version 2.9

makurasama commented 4 years ago

I have same problem. I set LD_LIBRARY_PATH=/opt/intel/sgxsdk/lib64. And to run strings client | grep \.so | grep sgx' I get this, 'libsgx_uae_service.so libsgx_urts.sosgx So I am sure of I run in hardware mode.

BrianPHChen commented 4 years ago

I got the same problem

mechalas commented 4 years ago

OK. So we are up to four reports of 404 errors, all using the hardware libraries. And, I suspect, all are returning an EPID group ID of zero as well. And at least one is on 2.9 which is a relatively modern release.

I've tried a number of scenarios that I think might cause this to happen, and they all end in fatal errors rather than invalid data. However...starting an EPID attestation on a system with the DCAP infrastructure might do this. Just to verify, is everyone:

If any DCAP components are getting installed, and if your hardware supports flexible launch control, then you could be using a system configured for ECDSA quoting and attestation to use EPID routines.

BrianPHChen commented 4 years ago

OK. So we are up to four reports of 404 errors, all using the hardware libraries. And, I suspect, all are returning an EPID group ID of zero as well. And at least one is on 2.9 which is a relatively modern release.

yes, EPID group ID is zero, being auto-generated in the file "policy"

I've tried a number of scenarios that I think might cause this to happen, and they all end in fatal errors rather than invalid data. However...starting an EPID attestation on a system with the DCAP infrastructure might do this. Just to verify, is everyone:

My Driver was download from https://download.01.org/intel-sgx/sgx-linux/2.11/distro/ubuntu18.04-server/sgx_linux_x64_driver_1.36.bin The SDK was download from https://download.01.org/intel-sgx/sgx-linux/2.11/distro/ubuntu18.04-server/sgx_linux_x64_sdk_2.11.100.2.bin PSW was installed by following the instruction (apt-get install libsgx-launch libsgx-urts) in the repo above.

If any DCAP components are getting installed, and if your hardware supports flexible launch control, then you could be using a system configured for ECDSA quoting and attestation to use EPID routines.

Do you suggest us to use DCAP driver instead of the out-of-tree driver?

mechalas commented 4 years ago

What I think might be happening is that there's some mixing and matching of components and hardware.

There's an install guide in the works that will hopefully clear up the complexities of SGX installation now that we have to deal with multiple hardware configurations and deployment environments ("Classic" SGX with EPID, Launch Control+EPID, and Launch Control+ECDSA).

Until then, I want to assess the situation and let that guide me to a possible fix. Even though all four reports on here exhibit the same symptoms, the solutions may not match.

First thing to do: tell me your CPU model. What you get from 'lscpu' is fine. I don't need all the details, just the CPU model itself. So:

lscpu | grep Model

Second, let's see if that system supports flexible launch control. The CPU model will tell me if it's not supported, but CPUID output will give me more information on CPU's that technically support it but may not have explicit BIOS options for it:

EDIT 11/12/20: CORRECTED INFORMATION

cpuid -1 -l 0x7 -r

If ECX & 0x40000000 == 1 then you have Launch Control support.

If you do have launch control, then you can use the msrtools to examine the state of launch control (locked or unlocked).

sudo modprobe msr
sudo rdmsr -f 17:17 0x3a

(You might need to install the msr-tools package on your system).

Next, generate a quote from the client app in the RA sample:

./run-client -q

And paste the output here so I can inspect the quote. (The contents of a quote are not private, so there is no information exposure risk to posting it here.)

mechalas commented 4 years ago

Here's what a quote should look like:

$ ./run-client -q
{
"isvEnclaveQuote":"AgABADgLAAALAAoAAAAAAJwYtWm+2ZWSwKSC3wBtrJ8AAAAAAAAAAAAAAAAAAAAACBACBP8CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAHAAAAAAAAAOYQtX2zen8sXyYoHaeS+Bmp+C633uzJkjiXtHwv71feAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC9ccY4Dvd8VBfostHOLUtlBLn0GOUEk0JEDP/yRD2VvQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAqAIAAABFZyiFU35dv10KmIFS92xQk3ApkH0cPmfKAyjsCS+SlOFc5rEz6EqKm2DviICqsN71BlFk/4pXxCTjCLq54J79HErbabrc8PZWHXvW5Rn3Itvq7TEWQ0wnHUUWYgCnzwSs1w2LL0N37utZXNmo9nLdoNZTNBdPPndoG9nZ2A28CSbXN3Ar6rjxiqjci8JB52UKSEqfZFvMtyLxF3vPdUH0TP1IubIeIP7lx9C7/W42gW/iufk0OjX+0wyNr79D/bQAWmN704QdM4oeOGGNE6CvtleR18tJEtjPUfTdB5rfAG3TkRK74iox1nYnO74+lpQER3NVxvh3WITaM0lDnrMoAwOi5+IXqtOWxTcdOtUMSchENCRpiqIUngorAyV0XzH2d5FQGg2U8qqC+GgBAAC8HX/WxvGORatuU3QKlGV2YfwJrn6VFHv7O1Icl63eH603e2ndyQGGAad/LxSIxMX/P/TXlkIDWa2hoCnV4RN1SH3f8ME7+QSEry13YVe4b0a7qmwcLHsm3CBqmHOaVonPgn8n+CZZWg6IU+an5O6hy5wkISjL8PCYHgLreFWvwo5XcDPR5+cndG9CRSwx/uYiRJSTyUtmvd2s+JDw/Kz+NMFACbdliJckWvfCIZMrhVu7ptpVNuqbKU8/tHVgBKic3jaT6WYySxY90l50LVjlGNF437AqXe2OhfYqJr9otkNwjg7UkXUyuMbQK71alF4UAleo/e9Gspvqngz7X3dcvJdHTaL6rV49KUVpFE/Ye78mWNJAJMuIe04Qvl4JhH3Y/EGlOdutvGbype7v8AWjbBLNbb1ostqEYyTUQaHGI1rclG9E/k5R00j1HivnhXh7epkheKst3fclO7FeSsHmBCjEkWOq9fnypvxcSUpONMvxlPvQNLYm",
"nonce":"ee939338c5cad7b5c948b84470405d74"
}
BrianPHChen commented 4 years ago

Here is the output that I follow your instruction

$ lscpu | grep Model

Model:               158
Model name:          Intel(R) Core(TM) i9-9900K CPU @ 3.60GHz

$ cpuid -1 -l 0x12 -r

CPU:
   0x00000012 0x00: eax=0x00000001 ebx=0x00000000 ecx=0x00000000 edx=0x0000241f

$ ./run-client -q

sgx_create_report: 00000001

So obviously my result from generating the quote is totally not in the same form as yours

jmechalas commented 4 years ago

My apologies. I led people astray by mistake. To detect launch control support, you query leaf 0x7 and look for bit 30 in ECX:

cpuid -1 -r -l 7

This system supports Launch Control:

$ cpuid -1 -r -l 7
CPU:
   0x00000007 0x00: eax=0x00000000 ebx=0xf2bf27ef ecx=0x40405f5e edx=0xbc000410

Since 0x40405f5e & 0x40000000 == 1

I apologize for the mistake.

jmechalas commented 4 years ago

@BrianPHChen My gut tells me that you actually do have Launch Control on your CPU, and are using the legacy driver instead of the DCAP driver.

BrianPHChen commented 4 years ago 
$ cpuid -1 -r -l 7
CPU:
   0x00000007 0x00: eax=0x00000000 ebx=0x029c6fbf ecx=0x40000000 edx=0xbc002600

After I reinstall DCAP driver, it is still 404 not found error

jmechalas commented 3 years ago

There may need to be some significant updates to this code to work with systems that have launch control. The DCAP driver means moving to the version 3 quoting structure, which in turn supports both ECDSA and EPID attestations. To do that, we'd need to do several things:

  1. Replace the calls to sgx_get_quote() with sgx_get_quote_ex()
  2. If libsgx_uae_service is not present, don't bomb out and instead look for the equivalent library in the DCAP/ECDSA-based infrastructure
  3. Ensure there are no other calls that are specifically tied to EPID

This is a fairly heavy lift. But I think that's what's going to have to happen.

Originally, this project was created for EPID attestations on EPID infrastructures since that's all there was. With the shift in focus to server hardware with launch control, these assumptions aren't really valid anymore.

I should really update the README to point all this out. Back when the PSW software was 2.8 or 2.9 it wasn't a big deal. But there are enough changes now that this project is causing too much confusion.

yzr95924 commented 3 years ago

I met the same problem. My SGX SDK version is 2.8. I think the root cause is "msg1.gid = 00000000" after I called "sgx_ra_get_msg1". But I cannot figure out why it returns this value after checking the manual.