Wall time and trusted time

[chrysn]

When using ACE/OAuth for authentication, the tokens (CWTs) typically carry expiry information. Currently, we don't have wall time, let alone trusted wall time.

A document I'm working on in T2TRG (raytime) describes what is about a minimal thing a device can do, but it'd still be about keeping some time. (In essence, it's about just keeping a lower bound of time, bumping it guided by seen tokens, and pushing it along while the device has a timer running).

So, what do we need in general, what do we want, and what should be default?

• Do we expect that securely networked devices are used in a mode that can do with no time at all?
  • If yes, how should this be made opt-in so that we are still secure by default (with "secure" following general guidance on not granting infinitely long-lived access)?
• Do we want to offer wall time as an OS-wide service? How many of them / at which trust levels?
  • Some secure time source authorized by the owner? The AS itself?
  • What precisions do we expect?
  • Which reliability v. security trade-offs are acceptable for which clock?
  • Can we even protect high precision time sources? (GNSS such as GPS can give us "perfect" time without authentication, AS provided time is ultimately trusted but goes through a full network round trip and might include extra times when the AS is heavily guarded)
  • How does an application select "the" time to use, eg. for storing timestamps of sensor values?
• Do we want to check token validity against a wall-time-ish service, or do we better split those, let the token security parts do their own weird raytime thing, and trust the time multiplexer to keep things efficient hardware-wise?

[chrysn]

One approach I start favoring is that the OS manages something like cumulative experienced-time. This is a time counter on some constant scale, and it is monotonous across reboots. As this would be backed by flash writes that consume power and wear down flash, it may make sense to model this as an interval (guaranteed-monotonous, best-effort-latest), the monotony only applies to the lower bound, but the application querying time can request this interval to be arbitrarily small (but requesting a small interval may force the OS to do a flash write, so applications please use lose bounds), or may contribute to the system wide policy on how large that window may become. (Early guesses are that when the time is requested, an application might ask for a maximum 10-minute window, which would create a flash write every 10 minutes while under load, and a maximum of 1-day when idle).

As a monotonous counter, any adjustments for clock skew would need to be applied at run time, but I don't expect precision requirements above what even built-in oscillators can provide. The value would only be allowed to reset if all credentials used with the clock are erased.

Then, the storage of an authorization server (especially when different ASes are around) can express their AS's time scale as an offset from the cumulative uptime, and the flash writes are decoupled from the individual AS's time lines.

Rough data structure:

• Constant:
  • Unit of time (eg. 1s)
  • Confidence intervals for the conversion between ticks and SI units
• in RAM or peripherals: Time since last stored (this value overflowing is rounds for a system reset, as apparently the time update task has not completed in time)
• in RAM, if we want "uptime": Cumulative counter when the system came up
• in configuration ROM:
  • Stored cumulative uptime
  • For each AS we are RS for (or other peer with which we want to have time base freshness): Maximum difference between AS time and cumulative uptime (adjusted for the fastest expected clock tick rate)
• Calculated: Cumulative uptime is stored cumulative uptime + time since last stored

If "uptime" is a deliverable, we'll want to have the confidence intervals (at least one-sided), so that uptime can be reported as the most likely value. If all users are like the AS clocks that can err on the side of caution (there, accepting certificates/tokens for a few minutes longer is tolerated, but rejecting a short-lived token because we think we're ahead of time by a few minutes breaks things), the confidence intervals may just as well be baked into the tick-to-time conversion factor.