For Institutions

Independent proofs of integrity and provenance for digital archives.

GAMI produces cryptographic proofs of integrity and institutional provenance for digital archival material. Each proof is independently verifiable and does not depend on GAMI, on any single registry, or on continued access to institutional systems.

Integration is designed and implemented by GAMI in line with existing preservation infrastructure. The institution's role is limited to review and authorisation: 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.

0

Files transferred to GAMI. Only SHA-256 fingerprints and structured metadata leave institutional infrastructure.

Lifetime of an anchored proof. Verification does not depend on GAMI's continued operation.

Read-only

GAMI does not write to the preservation system. No schema changes, plugins, or workflow modifications.

Open

Tooling, verification logic, and the GPR specification are published under open licences and available for independent audit.

Anchoring lifecycle

Two phases: initial anchoring and continuous operation.

Anchoring proceeds in two phases. The first establishes proofs for the existing collection in full. The second processes newly ingested material on a schedule set by the institution. The signing workflow is identical in both.

Phase 1 — One-time Initial collection anchoring

Archive system

Archivematica · Preservica · Filesystem · Custom

Unchanged

GAMI integration

Reads hashes and metadata. Read-only access, no modifications.

GAMI

GPR construction

Hashes, metadata, and institutional fields assembled automatically

GAMI

Review and sign

Signing Officer reviews the batch and signs with the hardware key

You

Blockchain anchoring

Signed GPRs anchored to Bitcoin via OpenTimestamps

GAMI
Phase 2 — Ongoing New ingestion batches, on the institution's schedule

New material ingested

Material enters the archive through standard ingestion. Existing workflows remain unchanged.

Unchanged

GPRs queued automatically

The integration detects new records and prepares GPR drafts, which accumulate until the next signing session.

GAMI

Review and sign

At an interval set by the institution — daily, weekly, or monthly — the Signing Officer reviews and signs the pending batch.

You

The signing step is identical in both phases. The portal presents what requires review; the hardware key authorises it.

Signing portal

A browser-based interface for review and authorisation.

The portal requires no installation, account credentials, or local software. A time-limited, institution-specific link is delivered to the Signing Officer by email. The portal presents records by identifier, filename, and cryptographic fingerprint, and accepts the hardware-key signature that authorises the batch.

Awaiting authorisation

sign.authenticmemory.org / dachau / 2024-09
GAMI Signing Portal
KZ-Gedenkstätte Dachau

Batch · 2024-09

47 records pending

Awaiting Signature
ID File Hash
DM/24/451 Testimony_Naor.mp4 a3f8d2…
DM/24/452 Barracks_1945.tif b91e4a…
DM/24/453 Release_1948.pdf c04d83…
+ 44 more records

Sign batch

Insert the YubiKey and touch the contact to authorise all 47 records.

Waiting for touch…
  1. 1 Insert YubiKey into USB port
  2. 2 Enter PIN when prompted
  3. 3 Touch the contact

The private key never leaves the device. The chip returns only a 64-byte signature.

Anchoring confirmed

sign.authenticmemory.org / dachau / 2024-09
GAMI Signing Portal
KZ-Gedenkstätte Dachau

Batch 2024-09 anchored

47 records signed and anchored to the Bitcoin blockchain

Institution KZ-Gedenkstätte Dachau
Signed by key did:web:kz-gedenkstaette-dachau.de#key-2025
Signed at 2024-11-08 · 14:22:07 UTC
Bitcoin block #924,891 — 2024-11-08 14:31 UTC
Merkle root sha256:d4e9f1a7…3c820b4

The records are now permanently verifiable. No further action is required. GPR files have been added to the GAMI index and returned to institutional storage.

Institutional signing key

The signing key is held only by the institution.

Each participating institution receives a hardware security key (YubiKey 5 NFC) carrying its Ed25519 signing key. The key is generated on the device during onboarding and cannot be extracted. GAMI has no access to private keys at any stage; this is enforced by the device, not by policy.

Signing requires physical possession of the device and the PIN set by the institution. Each signing operation also requires a deliberate touch of the device. Remote or automated signing is therefore not possible, including in the event of a compromise of institutional systems.

  • Key generation On-device. The private key is generated inside the secure element and cannot be extracted.
  • PIN protection Set by the institution during onboarding. GAMI does not hold or transmit it.
  • Touch confirmation Required for every signing operation.
  • Key rotation A new key pair can be generated on a replacement device. Prior GPRs remain valid under the original key.
TOUCH ACTIVE

YubiKey 5 NFC. The device is issued to the institution and remains in its possession. Its only function is signing GAMI proof batches.

FIPS 140-2 Level 2Ed25519 (RFC 8032)PIV / CCID interfaceUSB-A + NFCNo drivers required

Integration

Integration with existing preservation systems.

GAMI operates as a post-ingestion layer within OAIS-conformant workflows (ISO 14721). It reads outputs the preservation system already produces — file hashes, descriptive metadata, provenance records — strictly in read-only mode. No schema changes, plugins, or modifications to archival management systems are required. The integration design is documented and agreed with the institution before implementation begins.

System Type Integration approach
Archivematica Open-source digital preservation (OAIS) Reads SHA-256 hashes from METS files and the PREMIS event log; incorporates the provenance chain. Direct read access to the AIP structure; no API required.
Preservica Commercial digital preservation (OAIS) Queries content objects through the read-only REST API. Retrieves fixity records and descriptive metadata.
ArchivesSpace / AToM Archival management Reads finding-aid metadata via REST API or database export. Descriptive fields are mapped to the GPR metadata schema.
Filesystem / NAS Unmanaged file storage Walks the directory tree, computes SHA-256 hashes, and reads metadata from sidecar files or CSV manifests supplied by the institution.
Custom systems Institution-specific A generic adapter framework. Any system capable of exporting file paths, hashes, and metadata as CSV or JSON can feed GAMI without modification.

Where the preservation system already computes SHA-256 checksums during ingest, no additional hashing is required; GAMI reuses existing fixity records. PREMIS provenance chains, where available, are incorporated as Tier 2 evidence within the GPR.

What the institution holds

At the conclusion of initial anchoring, the following are held by the institution. Each is independent of GAMI's continued operation.

Hardware signing key (YubiKey)

The device issued during onboarding. It carries the Ed25519 signing key and remains in institutional possession. It can be used for independent signing operations with or without GAMI.

GAMI Proof Records (GPRs)

A standardised JSON proof file for each anchored item, containing the file hash, the institutional signature, the Merkle path, and the OpenTimestamps blockchain proof. Verification requires only the GPR file and publicly accessible Bitcoin blockchain data.

Institutional DID document

A W3C Decentralised Identifier (did:web) document published on the institution's own domain, containing the public key. Third parties can verify institutional signatures directly against this document. GAMI maintains a timestamped archival copy as a fallback.

Open-source tooling

All scripts used during anchoring — hashing, GPR construction, verification — are published under open licences. Institutional IT can inspect, audit, and run the toolchain independently.

Registry listing

The institution appears in the public GAMI index, with proof records discoverable through the verification interface. The index is mirrorable; independent copies may be operated by any institution, so discoverability does not depend on GAMI alone.

Investment

Cost recovery, not commercial licensing.

GAMI operates on a cost-recovery basis. Fees cover integration, collection processing, and ongoing anchoring. They are not a licence to use the proofs, which are permanent and unconditional. During the pilot phase, initial costs are partially covered by grants and foundation support; the structure below applies to operational partnerships.

Initial anchoring

One-time

from €12,000

  • Integration design and implementation
  • YubiKey hardware and institutional onboarding
  • Full collection processing and GPR construction
  • Blockchain anchoring of the complete initial batch
  • Three months of technical support post-launch

The final figure depends on collection size and the complexity of existing systems. Institutions whose preservation systems already produce SHA-256 checksums incur lower processing costs.

Ongoing anchoring

Annual

from €2,000 /year

  • Ingestion-triggered GPR construction for new material
  • Continued blockchain anchoring of new batches
  • Signing Portal access and maintenance
  • Index hosting and public registry listing
  • Technical support and version updates

The primary cost driver is the annual volume of newly ingested material. Institutions anchoring fewer than 5,000 new records per year are served at the base rate.

Anchored records carry no ongoing cost.

Once a GPR is anchored to the Bitcoin blockchain, the proof is self-contained. Its validity does not depend on GAMI. Institutions are not obliged to renew the annual service; all proofs issued before any discontinuation remain valid and independently verifiable.

Questions

What does the institution need to do to operate this?

The institution designates a Signing Officer — typically a senior archivist, collection manager, or director — who holds the hardware key and reviews batches in the portal when notified. The role requires no technical background. Beyond the Signing Officer, IT involvement is limited to the initial integration, which is designed and implemented by GAMI.

How does GAMI obtain the file hashes if the files never leave institutional infrastructure?

Hashes are read directly from the preservation system, which in most cases has already computed them during ingest. Where they are not pre-computed, GAMI's tooling runs locally on institutional infrastructure or on a server provided by the institution and computes them in place. Source files are never transmitted; only 64-character hash strings and associated metadata are sent to GAMI. The integration approach is agreed and documented before work begins.

Can GPRs be constructed locally at the institution rather than on GAMI's infrastructure?

Yes. The GPR construction pipeline is open source and can run locally on institution-controlled infrastructure. GAMI can deploy and configure the tooling within the institutional environment; GPR drafts are then transmitted only at the signing stage. This model is available on request and suits institutions with strict data-governance requirements.

What happens if the YubiKey is lost or the Signing Officer leaves?

Loss or retirement of a key does not affect previously anchored records. 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, the institution generates a new key pair on a replacement device, publishes the updated public key in its DID document, and continues anchoring. A backup Signing Officer with a secondary device is recommended from the outset.

Does this require changes to the preservation workflow or archival management system?

No. GAMI is a post-ingestion layer that reads outputs already produced by the preservation system. It does not write to, modify, or integrate with the archival management system, and the preservation workflow itself is unchanged. Integration has been validated with Archivematica, Preservica, ArchivesSpace, AToM, and unmanaged filesystems; custom adapter development is available for other systems.

What does the ongoing anchoring cycle look like in practice?

As new material is ingested through the standard workflow, the integration detects new records and prepares GPR drafts. Drafts accumulate until the next signing session. At an interval set by the institution — daily, weekly, or monthly — the Signing Officer receives an email, opens the portal, reviews the batch, and signs with the hardware key. The interaction typically takes a few minutes. Blockchain anchoring proceeds automatically; confirmation appears in the portal, and GPR files are returned for local storage.

What happens if GAMI 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 key, and the DID document needed for independent verification, and the verification process can be reproduced offline using published standards. The GAMI index supports discoverability, not validity — the relationship is comparable to that between a library catalogue and the documents it describes.

Is the pilot phase funded, and how does the transition to a paid partnership work?

Pilot costs are partially or fully covered by GAMI through grant and foundation funding. The structure of ongoing costs is discussed openly during the pilot. Institutions whose circumstances do not support the standard fee structure — in particular smaller memorial sites and archives with constrained operating budgets — are encouraged to raise this in the initial conversation. Co-funded arrangements, joint grant applications, and adjusted terms are available where appropriate.

Beginning a pilot

An initial conversation establishes collection size, existing systems, and scope. Where the fit is clear, work proceeds to integration design and onboarding. No commitment is required to open the conversation.

Week 1 Initial assessment Collection scope, existing systems, integration approach.
Week 2–3 Integration and onboarding Hardware key issued. Integration configured and tested. Signing Officer briefed.
Week 4 Test batch A defined subset anchored end-to-end. Both teams verify the workflow.
Ongoing Operational Regular batch cycles at the chosen interval. New material anchored on schedule.

info@authenticmemory.org · Authentic Memory gUG · Munich, Germany