For Institutions
Independent proofs of integrity and provenance for digital archives.
Authentic Memory produces independently verifiable cryptographic proofs of integrity existence and institutional provenance for digital archival material. Each proof remains valid regardless of Authentic Memory's continued operation.
Integration is designed and implemented in line with existing preservation infrastructure. A designated Signing Officer reviews each batch in a browser portal and signs it with a hardware key. Source files remain on institutional storage throughout.
Signing Portal Today
Good morning, Dr. Maier.
Forty-seven records are ready for your signature. The batch was prepared this morning by your ingest pipeline.
The premise is that records preserved today should remain recognisably authentic decades from now, at a point when distinguishing originals from synthesised material may be considerably harder than it is today. Cryptographic anchoring — applied while authenticity can still be readily established — is a practical, infrastructure-level response, designed to outlast any single operator of the registry.
How the work is divided.
When a batch is ready, an email arrives. The Signing Officer opens it, glances over the records, touches the contact on the hardware key, and closes the browser. Anchoring continues in the background. Within the hour, a confirmation is in the inbox. That is the full extent of the institutional interaction.
Prepared on the institution's behalf
- Reads new records from the preservation system, read-only
- Reuses existing SHA-256 fixity records, or computes them locally
- Assembles each proof with institutional metadata
- Constructs the Merkle tree, queues the batch, prepares the signing screen
- Submits the signed batch to OpenTimestamps for Bitcoin anchoring
- Verifies the institutional DID document hourly
- Issues a quarterly status report by email
Asked of the institution
- One initial cooperation conversation
- A one-time setup wizard, around fifteen minutes
- A single touch on the hardware key, per batch
No software to install. No passwords to manage. Per-record review is not part of the workflow at scale; the institutional act is to acknowledge that what was extracted from the source system is what is being anchored.
An interactive walkthrough.
Two short walkthroughs that follow the actual portal. The first covers a routine monthly signing session — what the portal serves most often. The second covers the one-time setup that happens once when an institution joins. The YubiKey to the right is the action prop: when a step asks for a touch, touch the gold contact.
Signing Portal Waiting for your touch
Click the gold contact to sign.
The portal supports a Primary and a Backup Signing Officer; either can authorise a batch, and every signature is attributed internally to the specific officer and key that produced it. Exception paths (reporting a problem with a batch, marking a key as lost) are handled in dedicated dialogs and stay out of the routine view.
The institutional signing keys.
Each participating institution receives two YubiKey 5 NFC hardware tokens. The primary is held by the Primary Signing Officer; the backup is stored in institutional safekeeping. Both carry an Ed25519 signing key generated on the device itself.
The private key cannot be extracted. Signing requires physical possession and a deliberate touch; Authentic Memory has no access to private keys at any stage. Login alone, whether via passkey or magic link, grants only viewing access — any action with cryptographic consequence requires a fresh YubiKey presentation. An attacker with access to email can read, but cannot sign.
Primary 7B2F·9C81
In routine use
Backup 7B2F·9C82
In institutional safekeeping
- Key generation
- On-device, inside the secure element
- PIN protection
- Set by the institution; verified on chip
- Touch confirmation
- Required for every operation
- Rotation
- Every three years; prior signatures stay valid
If Authentic Memory ceases to operate.
Authentic Memory's continued operation is not load-bearing for the validity of anchored records. End to end, the institution holds everything required to maintain, verify, and continue proof issuance independently. The archive of past batches lives with the institution.
Archive Every batch ever anchored under the institutional key. Each line links to its proof bundle.
2026
Ongoing operation
- 20 May Batch 2026-19 47 rec. #936,512
- 04 May Batch 2026-18 47 rec. #932,108
- 22 Apr Batch 2026-17b Reported 14 rec. — —
- 20 Apr Batch 2026-17 186 rec. #924,891
2025
Initial anchoring
- 28 Feb Initial collection — Sample Memorial Archive 12,847 rec. #878,201
A "Reported" batch indicates a problem flagged by the Signing Officer before anchoring. It is paused for review until our operations team responds.
- The hardware signing keys
- Both YubiKeys remain in institutional possession. They can continue to be used for further signing operations with or without us.
- The GAMI Proof Records
- Standardised JSON files, one per anchored item, containing the file hash, the institutional signature, the Merkle path, and the OpenTimestamps proof. Verification requires only the GPR file and publicly accessible Bitcoin data.
- The institutional DID document
- Published on the institution's own domain, containing the public key. Third parties verify signatures directly against this document.
- The open-source tooling
- All scripts used during hashing, GPR construction, and verification are published under open licences. Institutional IT can inspect, audit, and run the toolchain independently.
- A mirrorable public registry
- The public index is mirrorable. Independent copies may be operated by any party, so discoverability is not bound to Authentic Memory alone.
Integration with existing preservation systems.
Authentic Memory operates as a post-ingestion layer within OAIS-conformant workflows (ISO 14721). It reads outputs that the preservation system already produces — file hashes, descriptive metadata, provenance records — strictly in read-only mode. No schema changes, plugins, or modifications are required. The integration design is documented and agreed with the institution before implementation begins.
- Archivematica
- Reads SHA-256 hashes from METS files and the PREMIS event log; incorporates the provenance chain.
- Preservica
- Queries content objects through the read-only REST API. Retrieves fixity records and descriptive metadata.
- ArchivesSpace · AToM
- Reads finding-aid metadata via REST API or database export.
- Filesystem · NAS
- Walks the directory tree, computes SHA-256 hashes, reads metadata from sidecar files or CSV manifests.
- Custom systems
- A generic adapter framework. Any system capable of exporting paths, hashes, and metadata can feed Authentic Memory without modification.
Where the preservation system already computes SHA-256 checksums during ingest, existing fixity records are reused. PREMIS provenance chains, where available, are incorporated as Tier 2 evidence within the GPR.
Public verification.
External verification is handled by a separate public verifier at verify.authenticmemory.org. Anyone can submit a hash, a GPR file, or a record identifier and see the institution's name, the timestamp, the Bitcoin block reference, and the Merkle root. The Signing Officer's name is never exposed publicly — the institution is the entity that signs; the officer is its representative. The institution decides which record-level metadata is shown alongside the proof.
About this record
Provided by the institution · not part of the cryptographic proof
A recorded oral history interview produced by the institution. The participant speaks about her early years in the postwar period. Recorded in the institution's interview room as part of its ongoing collection programme.
- Recorded
- 12 March 2024
- Duration
- 6 min 14 s
- Language
- German · English subtitles
- Collection
- Oral history series
- The full record page also offers: What does "verified" mean — Show cryptographic details (hash, signature, Merkle root, DID) — Verify this yourself (offline, from open standards).
Cost.
Fees cover integration, collection processing, and ongoing anchoring. They are not a licence to use the proofs, which are permanent and unconditional once anchored. The pricing is structured for compatibility with public-sector grant programmes (DFG, BKM, EU Horizon, foundation funding); cost and impact breakdowns for funding applications are provided on request.
-
Initial anchoring
One-time, on entry
-
from €12,000
Integration design and implementation. Hardware tokens and institutional onboarding. Full collection processing and GPR construction. Anchoring of the complete initial batch. Three months of technical support.
-
Ongoing anchoring
Annual, recurring
-
from €2,000 per year
GPR construction for newly ingested material. Continued anchoring of new batches. Signing Portal access. Index hosting and registry listing. Technical support and version updates.
Final figures depend on collection size and the complexity of existing systems. Anchored records carry no ongoing cost; the annual fee is not required for prior proofs to remain valid.
Frequently asked.
What does the institution need to do to operate this?
▾
Designate a Primary and a Backup Signing Officer — typically senior archivists, collection managers, or the director. They hold the hardware keys and authorise each batch when notified. The role requires no technical background. IT involvement is limited to the initial integration, which Authentic Memory designs and implements.
How do you obtain the file hashes if the files never leave us?
▾
Hashes are read directly from the preservation system, which in most cases has already computed them during ingest. Where they are not pre-computed, the tooling runs locally on institutional infrastructure or on a server you provide, and computes them in place. Source files are never transmitted; only 64-character hash strings and structured metadata reach Authentic Memory.
How does this relate to the GDPR and the Bundesarchivgesetz?
▾
Hashes are one-way cryptographic fingerprints; they do not contain or reveal personal data that may be present inside source files. Source material is never transmitted to Authentic Memory or stored on its infrastructure. The arrangement is compatible with the Bundesarchivgesetz duty to safeguard authenticity and integrity, and with the GDPR principles of data minimisation and purpose limitation. A data-processing agreement (Art. 28 GDPR) is signed where any indirectly identifying metadata is involved.
What happens if a YubiKey is lost or a Signing Officer leaves?
▾
Previously anchored records are not affected: each GPR carries the signature made under the key at the time of signing, and its validity rests on the OpenTimestamps timestamp regardless of the key's current status. For future signing, a new device is shipped, registered, and added to the DID document. Officer transitions are handled by Authentic Memory directly as a conversation, not as a software flow.
Does this change our preservation workflow or archival management system?
▾
No. Authentic Memory is a post-ingestion layer that reads outputs already produced by the preservation system. It does not write to or modify the archival management system, and the preservation workflow itself is unchanged. Standard data structures of Archivematica, Preservica, ArchivesSpace, AToM, and unmanaged filesystems are supported; custom adapter development is available for other systems.
What if Authentic Memory ceases to operate?
▾
Anchored GPRs remain valid and verifiable. The blockchain anchor is maintained by the Bitcoin network and is independent of any single organisation. The institution holds the GPR files, the open-source tooling, the signing keys, and the DID document needed for independent verification. Verification can be reproduced offline using published standards. Discoverability through the index is the only function bound to Authentic Memory, and the index is mirrorable.
Beginning a pilot.
The first step is a 30-minute conversation. We discuss collection size, existing systems, and scope. No commitment is required to open the conversation; where the fit is clear, work proceeds to integration design and onboarding.
info@authenticmemory.org · Authentic Memory gUG · Munich
-
Week 1
Initial assessment
A 30-minute conversation followed by a written summary: scope, existing systems, integration approach.
-
Weeks 2–3
Integration and onboarding
Hardware keys issued and registered. Integration configured against the preservation system. Both Signing Officers briefed.
-
Week 4
Test batch
A defined subset anchored end-to-end against a written acceptance protocol.
-
Ongoing
Operational
Regular batch cycles at the chosen cadence. New material is anchored on the schedule set by the institution.