Cryptographic time for Year 2038 rollover

[dpkristensen]

I posted a suggestion for mbedtls, but I am thinking the best solution might be to provide a PSA API for time. Not all systems will provide a time system that is suitable for use in cryptographic purposes (certificate expiration, etc...).

See: Mbed-TLS/TF-PSA-Crypto#362

The time epoch and width of time_t are unspecified by the C standard, so it cannot be guaranteed that time(), localtime() etc... will work for these purposes.

[MarcusJGStreets]

If we do thi, I think it needs to be its own API, so it can be optional.
We do not want to make small M-class implementation take this unless they need it - as they are already on the limit for code size.

[dpkristensen]

That makes sense. There is already a separate API for storage, so maybe one for time?

Are there other use cases besides X.509 certificates? The NTP v4 protocol mentions filling missing time bits with random data for security reasons.

[dpkristensen]

ASN.1 UTCTime sequences used by X-509 go back to 1950, but GeneralTime sequences could represent years from 0000-9999. Taking the historical view, it seems that the valid timestamps needed to represent in an X-509 certificate are from 1950/01/01 to 9999/12/31. The solar cycle is 400 years, and there are 20 cycles between 2000 and 10000 CE/AD, so by my calculations that's a total duration of 254033452800 seconds between that range, which needs 38 bits to represent. In an 8-bit system, it could be represented as a sequence of only 5 bytes.

For the years 0000-9999, that's 315569520000 seconds, which needs 39 bits to represent as an integer (still 5 bytes).

For the purposes of cryptographic date, I don't think the concept of a timestamp in seconds must exist strictly as an integral value. But being able to do integer math to calculate a duration is useful on 64-bit systems. A system could provide a function to compare something like two date/time objects (e.g., POSIX tm structs). A datetime library I saw from the late 90's represented time as Julian Days in double precision floating point values. That puts a lot of extra strain on an FPU or a soft-float library for less powerful systems.

Performance and optimization aside, I think a possible implementation could be:

/*
    Define a value capable of representing absolute time points in
    seconds from the range of 1950 to 9999 (at a minimum).  This is
    38 bits of precision as a contiguous integral value.

    Examples:
        typedef int64_t PSA_timestamp_t;
        typedef uint8_t PSA_timestamp_t[5];
        typedef struct {
            int32_t date_val;
            int32_t time_val;
        } PSA_timestamp_t;
        typedef time_t PSA_timestamp_t;
*/
typedef /* define */ PSA_timestamp_t;

/*
    Define initializer for an invalid timestamp variable

    Examples:
        #define PSA_INIT_TIMESTAMP -1
        #define PSA_INIT_TIMESTAMP 0x7FFFFFFFFFFFFFFFULL
        #define PSA_INIT_TIMESTAMP { 0U };
*/
#define PSA_INIT_TIMESTAMP /* define */

/*
    Define test to determine if a timestamp is valid, evaluates to logical false or
    zero value if invalid, logical true or non-zero value if valid.

    Examples:
        #define PSA_timestamp_is_valid(p_ts) (*(p_ts) >= 0)
        #define PSA_timestamp_is_valid(p_ts) (*(p_ts) < 315569520000LL)
        #define PSA_timestamp_is_valid(p_ts) (((p_ts)[4] & 0x80) != 0)
        #define PSA_timestamp_is_valid(p_ts) ((p_ts)->date_val >= 0)
        #define PSA_timestamp_is_valid(p_ts) (*(p_ts) != -1)
*/
#define PSA_timestamp_is_valid(p_ts) /* define */

/*
    Define a conversion of the given parameters to PSA_timestamp_t, stored in
    the output parameter p_ts.  If unable to be represented, the value
    should be set to PSA_INVALID_TIMESTAMP.

    On success, p_ts is updated with the current value.
    Returns p_ts on success, or NULL on failure.
*/
PSA_timestamp_t* PSA_make_timestamp(PSA_timestamp_t* p_ts, int year, int month, int day, int hour, int min, int sec);

/*
    Define a function to retrieve the current timestamp in UTC.  This should be a
    monotonically increasing clock not affected by DST or time zone; but may be
    affected when the system time is synchronized from an external source.

    On success, p_ts is updated with the current value.
    Returns p_ts on success, or NULL if the system time has not been set.
*/
PSA_timestamp_t* PSA_get_sys_time_utc(PSA_timestamp_t* p_ts);

/*
    Define a function to compare two timestamps.

    Returns a negative value if lhs < rhs
    Returns 0 if lhs == rhs
    Returns a positive value if lhs > rhs
*/
int PSA_timestamp_compare(PSA_timestamp_t const* lhs, PSA_timestamp_t const* rhs);

Thoughts?

[dpkristensen]

Also FWIW, I saw the implementation of newlib only guarantees functions like gmtime() to work until 9999. We'll all be dead by then and it will be someone else's problem (except for you immortals, out there; I do not mean to be exclusive).

[gilles-peskine-arm]

There are many scenarios where some form of “secure time” is useful, and they require different properties. So we should be clear about the purpose of the API, both in function names and descriptions. And that can influence the functionality that the API does and does not offer.

Time for certificate verification needs to be as close as possible to the real time, but it doesn't need to be very precise (even being hours off isn't a problem in practice). Time may be unavailable in legitimate circumstances, for example when a device that doesn't have an RTC (or whose RTC battery has died) is freshly booted. It's suspicious if the time goes backward, but not necessarily a security violation, so we shouldn't require monotonicity: many devices need to recover if the date has accidentally been entered as 2036 instead of 2026.

(A few other examples of secure time: if you're rate-limiting password attempts, you need to wait for X seconds without allowing an untrusted party to shorten the wait, but this doesn't need to be persistent and the origin is irrelevant. If you're managing the expiry of a token then it's similar except you don't want an untrusted party to lengthen the validity of the token. If you're logging activity, you probably want the time to be both monotonic and persistent. And so on.)

I would suggest holding off on trying to make APIs that cater for all use cases, this is just too complex. So let's focus on the use case that we know we want, which is certificate validation. (X.509 or otherwise.)

---

Do we really need “give me the current time”? In practice the device may have partial time information. A less powerful API may be better at conveying this.

For example, let's consider what I think is a fairly common scenario: a device has trusted persistent storage, but no real-time clock. When it boots, it tries to connect securely to a trusted time server. There's a bootstrap problem that device doesn't know the time until it has successfully connected to the server, but it would like to verify the server's certificate. The device knows that the current time is later than the last timestamp saved in storage, but it has no idea how much later it is. The most likely attack would be that an old key of the server was compromised. We'd like to limit the effects of this compromise to devices that were rebooted during the compromised certificate's validity. For that, the device should reject certificates that are too old, while in a state where it can't meaningfully tell the time.

In this scenario, the interface we need is: “is this datetime in the past or the future?”, available even when the device can't tell how much in the past or future.

[dpkristensen]

So ultimately that's what the API PSA_timestamp_compare() answers. In order to compare, you have to have some way to represent the times being compared. If the current time is unknown, you can't make any qualified judgement about whether it's in the past or future.

PSA_timestamp_t is abstract; we don't know what it is, just that it represents a point in time which either is valid, was valid, or was never valid. It may not even be current. This is the abstract concept of the object that needs to be compared.

X.509 certificates have data indicating its representation of expiry time, which is converted via PSA_make_timestamp().

If a system is not capable of tracking time, then it is impossible to track certificate expiration. I believe mbedtls has a configuration for this case where it just doesn't check expiry time at all when there is no concept of current time. For the other cases there could be different types of times in a system. A local time is displayed to the user and may adjust with DST or be corrected. A time in UTC won't change wrt DST, but could still be corrected. A time since boot usually has no concept of calendar time.

The purpose of my qualification about PSA_get_sys_time_utc() being monotonically increasing isn't meant to bar it from getting updates, but merely to say that if you call it once and then call it later without any system clock correction, it should represent a later point in time. In any case there's always a real possibility that the time will not be available.

There's at least two scenarios for time restoration. Let's say a system was offline for a couple of years:

• If the last known time was written to non-volatile storage, you'd have a time point which was valid at some point. Restoring that time point as the system time should indicate that the timestamp is valid at least. Any certificates that had previously expired are still expired, anything that may have expired in the interim will be seen as "in the future", so they will be allowed. How the user wants to handle that in the system is completely up to the implementation and their system design / acceptability of risk; they also have the option of not storing the time (see below).
• If the time was not persisted and is treated as "invalid" on startup, a monotonic clock might still present the time as an offset from an epoch. But that clock system should still have a way to know whether it actually is that time, or if a time was set.

Based on the above scenarios, the configuration of the X.509 checker will have a policy to either disallow or allow certificate expiry checks if the system time has not been configured when the certificate is checked. That's not the responsibility of PSA, but the PSA API should provide that information to detect when that policy needs to be applied. You could theoretically have a system where time is explicitly invalidated upon some condition, which would also trigger such a policy (maybe there's an OOB keepalive message which must be periodically refreshed or something); again that's up to the system implementers to determine what the policy is and ensure it is enforced through the PSA API.

I suppose you could have a separate PSA API to determine if time is available, but that seems overly complicated more than just checking whether the timestamp is valid:

PSA_timestamp_t cur_ts = PSA_INIT_TIMESTAMP;
PSA_get_sys_time_utc(&cur_ts);
if(PSA_timestamp_is_valid(&cur_ts)) {
    /* Do expiry check here */
}

[gilles-peskine-arm]

If the current time is unknown, you can't make any qualified judgement about whether it's in the past or future.

My point is that the current time can be partially known. And then some useful judgements about past-or-future are possible, while others are not.

PSA_timestamp_t is abstract; we don't know what it is, just that it represents a point in time which either is valid, was valid, or was never valid. It may not even be current. This is the abstract concept of the object that needs to be compared.

I suppose a PSA_timestamp_t could represent an interval (last-known-timestamp to infinitely-in-the-future, in the reboot-without-RTC scenario I described), but that seems rather complicated compared to a simple past-or-future function.

What would be the use case for comparing two timestamps, neither of which are the current time?

The purpose of my qualification about PSA_get_sys_time_utc() being monotonically increasing isn't meant to bar it from getting updates, but merely to say that if you call it once and then call it later without any system clock correction, it should represent a later point in time.

By definition, a monotonically increasing time cannot be corrected backwards. It's a useful concept, but only with an arbitrary origin, not when it's real-world time. (Except for devices that absolutely must have accurate real-world time and will brick themselves otherwise, which could be the case for some HSM, but that's not the main target of PSA APIs.)

[dpkristensen]

Ok, let's forget monotonic for clarity. The behavior this should match is closest to CLOCK_REALTIME in the POSIX standard, and could be implemented with such.

PSA_timestamp_t represents an absolute time point, not a duration or interval. In practical terms it's likely implemented as a duration since an epoch, but it does not have to be. The system could implement it as a date+time structure. But it is abstract, so we don't care about that.

The comparison is intended to be used in conjunction with the current time. It could also be used to determine relative expiry times between certificates, if it was used as a check prior to an update.

The reason I didn't suggest comparison to the current time as a single API is due to the complexity of the result (don't have current time, timestamp is invalid/unable to be represented by this system, time is less/equal/greater). Also it's possible to map these concepts to existing APIs if they're separate.

So these API's are primitives to be used in concert for the higher level operation, similarly to how the crypto API's are primitives.