What a certificate proves
A job certificate is a signed record that shows what happened in one job. An assessor, a privacy officer or a risk committee can check the certificate on their own machine, with no Hangar account.
Hangar signs one job certificate at the end of each slot or sandbox session. The certificate shows which image ran, when, on which instance, and how the job ended. A data certificate is the signed record of everything that happened to one upload. The reader can check either certificate without an account and without trusting the servers of Hangar.
This page is for the reader of a certificate. The page says what each part of a certificate shows and how the reader checks each part.
Who issues the certificate
TALOS Defence Pty Ltd (ABN 24 696 691 906) issues and signs every certificate. Hangar is the service and the website. The certificate says so on its face.
What the certificate states
| On the certificate | What it records |
|---|---|
| Organisation | The customer's legal name and ABN, and the account that booked |
| What ran | For each job: the image name, the image digest that the name resolved to and when, the command, the names of the environment variables given to the job, and how the job ended (completed, ended abnormally, cancelled or not started), with the reason when there is one |
| What it ran on | The instance type and id, the number of GPUs, each GPU's UUID and serial from the reset query, the AWS Region and zone, and the capacity block |
| When | The start and end of the slot in Melbourne local time (AEST or AEDT) and in UTC |
| Data in and out | The digest and size of each file that went in and each file that came out |
| Movements | Each move of the customer's data: received, staged, mounted, written, downloaded, deleted, each with its time and place |
| Reset and wipe | The records of the GPU reset and the instance wipe before the job, and the reset path: a fresh instance for the slot, or the same instance reset and rebooted in place between jobs |
| Attestation kind | An AWS Nitro attestation of the instance, or a test attestation from the Hangar test pool |
| Attestation, release and audit | The digest of the instance attestation, the digest of the Hangar release that ran the slot, and the digest of that day's AWS audit log |
| Clock error | How far the clock that timed every record could be from true time |
| Operated by | Who at TALOS Defence operated the slot |
| Places | Each place where the job's data was stored, processed or staged, and where the records are, by AWS Region and zone. The statement of where the data was comes from these places |
| Region policy | The Region policy that the job ran under, where the policy came from (the organisation or the job), the cell that signed the certificate, the home cell of the organisation, and why the job ran in its Region |
The certificate contains digests, names and sizes. The certificate never contains the customer's files.
A sandbox session certificate
A sandbox session certificate records one session in a sandbox. The certificate adds these facts:
| On the certificate | What it records |
|---|---|
| Instance | The Graviton instance type and id, the shape (memory per vCPU) and the vCPU count |
| Image release | The digest of the sandbox image release that the session ran |
| Companions | Each companion container by name and image digest. Companions ran inside the session's own instance |
| Allowlist | The digest of the list of destinations that the gateway let the session reach |
| Gateway | How many connections the gateway handled, and how many the gateway refused |
| Credentials | Each credential that the gateway attached, by secret name and destination. The value never appears |
| Approvals | Each decision on a proposal: approved or declined, by a named person or by the account's Lock, with the time |
| Reset | Each step of the published reset (instance terminated, session security group checked, credentials revoked, gateway CA destroyed, secrets detached), with the time and the digest of the provider's response |
The verifier prints each companion, the gateway's refusals and each reset step as a visible line under the result. The verifier checks the allowlist digest, the approvals and every reset response against the signed records in the certificate.
How each statement is backed
- Every statement is a signed record. Hangar writes a record for each booking, movement, reset, wipe and job when the event happens, before the database changes. The certificate contains those records. A check confirms that every digest on the certificate's page appears in one of the records.
- Two signatures on everything. The log head, the certificate and each record have an ML-DSA-87 signature (the post-quantum standard FIPS 204) and an ECDSA P-256 signature. Both signatures must be valid.
- Keys you can check. The signatures trace to TALOS Defence's published root keys through a daily key that the root vouches for. The published key set is on the Hangar site and on TALOS Defence's own site.
- Records in order. Each record names the record before it. If someone removes, reorders or changes a record, the link breaks at a named point.
- A public log. Hangar puts every record from every customer into one append-only log. The certificate contains a proof that each of its records is in the log. The proof uses a log head that Hangar publishes every minute. If the log later dropped or changed an entry, the log could not prove that it still matches the published heads. Anyone who keeps a copy of the heads can see the change.
- One exact encoding. The certificate has one byte form. If you change one byte anywhere, the check fails at a named step.
How to check a certificate
- Get the published key set from the Hangar site or from TALOS Defence's site.
- Open the verifier at the Hangar site's verify page, or run
hangar verify <certificate>in a terminal. - The verifier runs eleven checks in order and prints each check with one sentence: decoding, the key set, the daily keys, the certificate signature, the record signatures, the record chain, the log proofs, the log head, the times, the facts, and the published log heads.
- The result reads "Valid" only when every required check passes. The verifier names the first failed check and marks the checks after it "not run".
- Two facts appear as notices directly under the result when they apply. "Test attestation" shows for a certificate from the test pool. "Reset by reboot in place" shows when Hangar rebooted the instance between jobs instead of replacing the instance. Read the notices with the result.
The browser verifier is the terminal verifier's code, compiled for the browser. After the page has loaded, the browser verifier works with the network off. You can save the page and run the page on a machine with no connection. The verifier is free and open source.
What the reader concludes
The certificate states facts about one slot: what ran, on which hardware, when, with which data, where the data went and when Hangar deleted the data. Hangar signs and logs each fact. The certificate gives an assessor the evidence for those facts in a form that the assessor can check without asking Hangar.
The assessor decides what the facts mean for their framework, their classification rules and their obligations. The certificate supplies the facts, and the conclusion belongs to the assessor.