sgx_get_trusted_time

[aalanwar]

Hi

Thanks for your efforts in maintaining the repo. I would like to ask about sgx_get_trusted_time I see it keeps going until it reaches pse_read_timer

What is the idea behind it? How can you guarantee security? Is it a trusted Hw or what?

Regards

[lingyuj]

The trusted time is provided by the CSE/ME which is trusted HW. It's based upon the PRTC within the CSE/ME. This time does not guarantee wall-clock time, but rather delivers a robust source of relative time that would allow an enclave to provision wall-clock time via an offset if necessary.

Regarding the code logic here, the call flow in pse_op enclave is:
pse_read_timer->psda_read_timer->invoke_psda_service->psda_invoke_service_ocall
psda_invoke_service_ocall is an OCALL to untrusted code (AESM) , which invokes JHI interface to communicate with CSE/ME.

There is a secure session between PSE and CSE/ME so the messages are encrypted when passed to untrusted domain.
There is also a secure session between the app enclave and the PSE. With the help of trusted and untrusted service libraries, users don't need to create and maintain the secure channel by themselves.

The whole message flow looks like below:
App Enclave <->AESM(untrusted)<-> PSE enclave(trusted) <-> AESM <->CSE/ME(trusted)

[aalanwar]

Hi

Thanks a bunch for such nice and detailed response. I really appreciate that.
What I got that that it is helpful to get the trusted execution time of some code like the following pseudo-code example:

(Time1 , nonce1 ) = sgx_get_trusted_time().
// some code goes here
(Time2 , nonce2 ) = sgx_get_trusted_time().

if( nonce1 == nonce2)
Execution_time = Time2 - Time1
else
//no trusted execution time can be obtained so no useful information

Is that right?
I would like to ask, who would reset that nonce and why? Is it under os hand to reset it ?
Also based on your explanation it should already has a high uncertainty due to all this long process which may affect the time accuracy.
Do you have any estimate of its accuracy, resolution ?
Also, do you have any estimate for how long does it take to execute that API?

Thanks again for your great support

[lingyuj]

Hi,
Your usage of sgx_get_trusted_time() is correct. The nonce will be reset due to battery power loss. The time resolution is second here so you cannot use it for subtle time measurement. Regarding the latency of this API, I believe it's about several ten milliseconds.

[llly]

trusted_time is uint64_t in seconds relative, so you example can work but not a common usage scenario.

//App start
(Time1 , nonce1 ) = sgx_get_trusted_time()
sealed_data1 = sgx_seal_data(Time1 , nonce1)
//App end
// some time goes here
//App start again
(Time2 , nonce2 ) = sgx_get_trusted_time()
(Time1 , nonce1) = sgx_unseal_data(sealed_data1)
if( nonce1 == nonce2)
    elapsed_time = Time2 - Time1 
else
    // Time1 and Time2 cannot be compared. 
//App end

Reset CSE/ME will reset the nonce. Of course, Enclaves signed by different key get different nonce.
In worst condition, first sgx_get_trusted_time() call after PSW installer installed may take 10 seconds to complete, the following calls take more than 1 second.

[aalanwar]

Hi,
Thank you guys a lot for your reply and support. I will take a look into that and come back if you do not mind if I have more questions.
Finally, I found experts and knowledgeable people about this trusted time :) :)

[bodzhang]

Intel published a white paper on SGX Platform Service (Monotonic Counter and Trusted Time): https://software.intel.com/sites/default/files/managed/1b/a2/Intel-SGX-Platform-Services.pdf

[aalanwar]

This seems a very good resource. I did not notice that before.
Thanks a lot for sharing it!

[fatimanwar]

This seems like an interesting discussion.
I am concerned about the change of nonce that affects sgx time. The white paper posted by bodzhang says that nonce will change whenever battery is replaced for CSME. I assume that would be a rare event.
What I wanted to ask if CSME is affected by any of the CPU power management states? What I assume that since CSME is backed up with a battery, whatever the state of CPU, CSME will always have power to keep its timer ticking, hence the source epoch will not change and the nonce will not change and the time would always make sense.
Kindly correct me if I am wrong.
Thanks.

[lingyuj]

Hi fatimanwar, your understanding of the time source epoch is correct.

[fatimanwar]

I recently figured out that in the sgx_get_trusted_time API execution flow which is,

App Enclave <->AESM(untrusted)<-> PSE enclave(trusted) <-> AESM <->CSE/ME(trusted)

even if all the data is encrypted, there is a chance that a malicious Operating System can delay the packet through the IPC communication between App Enclave and AESM. If a packet can be delayed, then the encrypted time value inside the packet will no longer make sense. So my question is, Is it possible for an OS to delay the packet between AESM and App enclave? If yes, then sgx_get_trusted_time can no longer be trusted. Kindly correct me if I am wrong?

[bodzhang]

@fatimanwar, your understanding about the IPC delay is correct. A single reading of sgx_get_trusted_time does not provide a trusted wall clock time stamp. The IPC can be delayed, and the returned time stamp is in reference to a fixed (until time_epoch reset) but arbitrary starting value. The intended usage is to use two readings of this API to enforce an expiration policy, for example access to a downloaded ERMed document expiring after 3 days and the user must go online to reverify access right. The system is design to guarantee that the difference between the two readings is larger than the time passed between the Instance the first call RETURNs and the instance the second call is INVOKEed, no matter how much delay is introduced to each call. This security property provides what’s needed to enforce the expiration policy. An implementation can record the reading of the first call AFTER the first call RETURNs, where the 3 day expiration counter starts ticking. When the enclave needs to check expiration, say before decrypting the ERMed doc for viewing, it INVOKEs the API again. If the time between the first call RETURNing and the second call INVOKing is more than 3 days, the difference between the value returned in the second call and the value recorded for the first call is guaranteed to be more than 3 days. Therefore, an attacker can’t trick the system to decrypt the doc after the expiration period of 3 days, with the counting starting when the first call RETURNs.

[fatimanwar]

@bodzhang thanks for your detailed response and I understand the use case for the sgx_get_trusted_time API. Also, would the OS be able to pull off a replay attack for this scenario? Say the OS would always return the same value (previously recorded) for every invocation of sgx_get_trusted_time API hence not enforcing an expiration policy ever?

[bodzhang]

@fatimanwar, the secure channel between the CSME and PSE, and the secure channel between PSE and the Application Enclave, both have protection against replay attack using the captured message. Any replayed message will be detected and not considered a valid response, and might cause the PSE to reset the secure channel. PSE will not send trusted time response to Application Enclave's trusted time query request in this situation, unless the attack attempt is transient and the secure channel and legit message exchange resumed. The sgx_get_trusted_time() API will return error if the attack is persistent.

[fatimanwar]

Thanks. I have one question about the channel between AESM and CSME. From what I understood through forums and discussions, the AESM & CSME communicates through MEI driver which is a PCI memory mapped based peripheral. What I would like to know if this PCI memory used is protected and cannot be accessed by operating system in any way? Is there a chance of any kind of DMA attacks?
I have all these questions because the Management Engine is closed source and not much information is present online.

[bl4ck5un]

@bodzhang I'm also curious about replay attacks. What does "the captured message" in your previous comment mean exactly?

From what I read in the white paper:

Upon successful completion of the PSE – CSME ephemeral session establishment flow, the PSE and the CSME use an HMAC algorithm with their shared pairing key SK and nonce Nonce_PSE and Nonce_CSME to derive session specific symmetric keys. The established session only lasts until the PSE stops and is thus called an ephemeral session.

It's not clear that messages sent in a secure session are associated nonces. Is that implicit? Can you clarify? Thanks.

[bodzhang]

@bl4ck5un, the encrypted and integrity protected (using the "session" key established by the "PSE-CSME ephemeral session establishment flow") messages between PSE and CSME are transmitted through the OS layer, and thus can be captured/replayed by an attacker. The messages include sequence number to detect replay attacks. See psda_service.cpp->invoke_psda_service() for details.

@fatimanwar, sorry for not addressing your question earlier. ME/CSME has its own runtime memory, not accessible by the host. The MEI interface supports data exchange between the host and the CSME through specific memory mapped access. https://www.amazon.com/Platform-Embedded-Security-Technology-Revealed/dp/143026571X/ might have detailed information you need. I do like to warn that the SGX related statement in the book is a bit ambiguous. SGX Technology itself does not depend on ME/CSME, only the SGX Platform Service, which is a SW service implemented in the Intel's SGX SW stack.

[bl4ck5un]

@bodzhang Great. The sequence number is what I'm looking for. Thanks.