What “verify” means when no server can answer
Online, verifying someone usually means asking a server: is this password right, is this account still active? With no connection, that question has nobody to go to, so offline authentication has to rely on things the verifier already holds. It helps to split “verify” into four separate questions:
- Is this the same key I saw before, or one I was told to trust?
- Is the holder of that key present now, rather than replaying an old message?
- Does someone I trust vouch for this key, for example by saying it belongs to a named account or employee?
- Is that vouching still current, or has it been withdrawn?
Cryptography answers the first three locally. The fourth depends on how recent your information is.
Establishing trust before you go offline
Every offline check starts from something arranged in advance. There are three usual starting points, and they can be combined.
A key you already know. The SSH architecture in RFC 4251 describes a client that keeps a local database linking each host name to its public key. It needs no centrally run infrastructure and no third party. The open question is how that first key got there, which is the subject of when trust on first use is safe.
A key someone vouches for. In the second model RFC 4251 describes, a certification authority signs the binding between a name and a key, and the client only needs to hold the authority’s key. RFC 5280 notes that because a certificate’s signature and validity period can be checked independently by the client, certificates can be passed over untrusted channels and cached on the device. This is the idea behind an issuer-signed credential: the issuer does its work while online, and the verifier checks the result later without contacting it.
A key confirmed through another channel. RFC 4251 also suggests comparing a short fingerprint of the key by telephone or another channel. Scanning a QR code shown on the other person’s screen does the same job in person.
A related approach removes one step. With a self-certifying identifier, the identifier is derived from the public key itself, so anyone can recompute it and check that a presented key matches. That proves the key and the identifier belong together. It does not say whose key it is.
Proving the key holder is present
Holding someone’s public key is not enough, because anything they signed earlier can be copied and sent again. The verifier needs proof that the key holder is taking part right now.
Challenge-response authentication provides that. NIST SP 800-63B-4 describes it as the verifier sending a random value or nonce, which the claimant combines with a secret, for example by applying a private-key operation, and returns. The verifier checks the response with the public key. Because the challenge is new each time, NIST notes that a recorded response from an earlier exchange will not contain the right value and is rejected.
Between two phones, this exchange can run over any local link, such as Bluetooth LE or a local network. Nothing in it needs the internet. Ed25519 is one signature scheme used for this; RFC 8032 gives it 32-byte public keys and 64-byte signatures.
What an offline check cannot tell you
Offline verification has limits that no choice of algorithm removes.
- Revocation you have not heard about. RFC 5280 explains that a certificate revocation list only reaches relying parties when the next list is issued, and that when revocation information is late or unavailable, the assurance in the certificate is reduced. A verifier that has been offline for a week knows only what it knew a week ago.
- Whether the claims are true. The W3C Verifiable Credentials Data Model states that verifying a credential does not mean evaluating whether its claims are true. A signature proves who said something, not that it is correct.
- What the person is allowed to do. Knowing which key you are talking to is a different question from what that key may do. The Offline Protocol security docs make this point for their own device identity: devices verify each other with no connectivity using Ed25519 identity keys bound to their off1 addresses, and that verification does not establish a person’s role or permission to act on equipment. The application has to enrol identities and enforce its own authorisation.
A practical checklist
When you design an offline check, write down the answer to each of these:
- Which keys or issuer keys does the verifier hold, and how did they get there?
- How does the verifier get fresh status information, and how old is it allowed to be?
- Does every check include a fresh challenge, so that an old response cannot be replayed?
- What happens when a check fails: refuse, or allow with a warning and a record?
- Which decisions need a person or an online system, because a stale answer would cost too much?
Offline verification is strong at answering “is this the key I expect, and is its holder here now”. It is weak at answering “has anything changed since I last synced”. A good design is clear about which of those two questions each decision depends on.