search

ietf-rats-wg / architecture

RATS Architecture
Other
17 stars 10 forks source link

Brendan's feedback about local clock #292

Closed dthaler closed 3 years ago

dthaler commented 3 years ago

At the IETF 110 meeting, Brendan Moran asked why local clocks are a problem since even MCUs have them. Currently we have text in the doc like...

in the nonce section:

and might be suitable, for example, in case the Attester does not have a reliable clock or time synchronization is otherwise impaired

in the handles section:

Like the nonce approach, this allows associating a "rough" epoch without requiring a reliable clock or time synchronization in order to generate or appraise the freshness of Evidence or Attestation Results.

I answered this by saying in the TEE use case for example, attesting the TEE needs a trusted clock, and having a trusted clock is not common. Brendan suggested clarifying the clock text.

mcr commented 3 years ago

Isn't it synchronized clocks that are the requirement? When you say "trusted clocks", do you mean, I can trust that they are securely synchronized? (Or that I can trust that Cesium still has that frequency, and that the laws of physics haven't been altered?)

dthaler commented 3 years ago

I mean a clock for which code outside the TEE cannot tamper with. Whether it's synchronized or not is not about whether the clock itself is trusted.

If a TEE wants to know how much time has passed since a previous event, and it has to ask the REE, and the REE can lie, then that clock is not trusted by the TEE.

mcr commented 3 years ago

Add text to TEE section about how it needs a local clock, and then add to the example involving nonces.