In brief
Hash chain, timestamp, signing key: the concepts in plain words. Who holds the key, how to back up the configuration, and how to hand the archive over when the box is replaced.
What does "signed archive" mean?
Saying the records are signed is easy. When an inspector or an expert witness asks "who signed them, and where is the key", the answer has to be easy too. This article gives that answer; concepts first, then practice.
Two mechanisms work together in a Hotspot-Box archive: the hash chain and the timestamp. The first proves the records are linked to each other; the second proves they existed at a given moment.
The hash chain: each day tied to the one before
A hash is a file's fingerprint. The SHA-256 algorithm turns any file into a 64-character string. Change a single character in the file and the fingerprint changes completely; and you cannot work back from the fingerprint to the file.
As each day closes, the box hashes that day's record files. It then hashes that digest together with the previous day's digest. Today's fingerprint is therefore tied to the whole of the past. Change a row from three months ago and that day's digest changes, the next day's digest changes, and the chain is broken all the way to today.
The chain starts on the day the box is installed. Earlier records are not signed retroactively; that is an honest limit, and you need to know your installation date.
The timestamp: "this digest existed on that day"
The hash chain proves integrity but not time. In theory, someone could generate an entire chain from scratch today and claim it is two years old. The timestamp closes that door.
RFC 3161 is the international standard for timestamps. The flow:
- The box sends the day's digest (only the digest, never the records) to a timestamp service.
- The service writes its own clock next to the digest and signs the pair with its own private key.
- The signed package, the timestamp token, returns to the box and is stored in the day's directory as the timestamp file.
The token is the signed form of "this fingerprint was presented to us at this date and time". The box cannot produce it on its own; the service's key is not in the box. That is why the timestamp is a witness independent of your business.
So who holds the key?
This is the commonly misunderstood point. The key that signs the timestamp belongs to the timestamp service, not to you. You do not hold it, back it up or risk losing it. The service protects its key and publishes its certificate.
What you hold is three things:
| What | Purpose | Where |
|---|---|---|
| Timestamp files (tokens) | Proof of time for each day | In the day's directory; in the SFTP copy |
| The service's certificate chain | Needed to verify the token | In the exported ZIP; can be obtained from the service again |
| The chain's latest digest | The point the next day links to | In the box; in the manifest files |
Verification needs no private key; the certificate is enough. That is why you can verify the archive years later, without the box or the service, using openssl ts -verify. The commands are in our article on the archive's contents.
What happens without internet?
If the timestamp service cannot be reached, the day still closes, the digest is still taken, and the timestamp request joins a queue. When connectivity returns, the queued days are timestamped in order. The panel shows the number of "pending days", and an alarm fires when the service is unreachable.
If pending days are above zero, there is a gap between the record date and the timestamp date. That gap is not hidden; the time inside the timestamp file is the real time it was obtained. If an outage lasts long, note it in your installation records.
Configuration backup: no key, but many settings
You hold no key, but there is something in the box that must be backed up: the configuration. It contains VLAN definitions, portal settings, login methods, SMS provider details, the SFTP target, alarm channels, roles and the retention period. If the box fails, re-entering all of this from memory takes hours and invites mistakes.
The practical rule:
- Take a configuration backup when installation is complete; your installer will show you where.
- Take another after every meaningful settings change.
- Store it somewhere separate from the archive copy, with restricted access; it contains provider credentials.
- Note the backup date and who took it.
When the box is replaced: the handover
The box reaches the end of its life, or you move to a larger model. Handing over the archive takes three steps:
- Secure the old archive. Run a full export from the panel including the final day. Confirm on the target server that the SFTP copy is current. Before switching the old box off, check that the final day's timestamp has been obtained.
- Build the new box from the configuration backup. VLAN, portal and provider settings come back. Create a separate directory for the new box on the SFTP target; do not overwrite the old one.
- Document the switch-over date. The new box's chain starts on the day it is installed. The old chain sits closed, with its final digest, in the exported ZIP. At an inspection you present the two periods side by side: the old ZIP with its verification report, and the new box's panel.
Wipe the old box's disk before disposing of it; it holds two years of records. Note the wipe as well.
In short
- The chain proves integrity, the timestamp proves time.
- The key that signs the timestamp is at the service; you hold the token and the certificate.
- No private key is needed to verify.
- What you back up is the configuration; it holds credentials, so store it separately.
- When the box is replaced, the old chain closes and a new one starts; document both.
The mechanism is identical on the box and the virtual machine edition; see the box and virtual appliance pages for details. Contact us with technical questions.