3 ms·
As a side note, design of offline systems that would generally be online is an interesting problem. For example, Onity/TESA door locks store an incrementing cou
by jcrawfordor 11y ago
As a side note, design of offline systems that would generally be online is an interesting problem. For example, Onity/TESA door locks store an incrementing counter for determining the validity of keys. If you need to revoke a key, you make a new key with a higher counter value and insert it in each lock. When the lock sees a larger number, it increments its internal counter, and the old key will then have too small of a number and not work.
What's even trickier is when you want thorough logging. Clipper terminals report back card usage information when they update on value adds. Some locks struggle with this - for Onity locks, retrieving user history requires connecting a bulky diagnostic device to the lock. An interesting solution is that used by Cyberlock. In that system, an audit log is stored in the key itself and the key has a short expiry, forcing the holder to frequently reprogram it, during which the log is retrieved. The locks must still store a log too in case of disappearing keys, but it allows for fairly accurate logging without frequently having to visit every lock.