Cryptographic Practice Statement, version 1.0
This statement describes, in technical terms, how CaseGuardian™ fingerprints, signs, timestamps, encrypts and logs evidence. It applies to every entry whose record shows CPS version 1.0. It describes what the software does; it does not describe what any court will accept.
1. Entry fingerprint (integrity seal)
When an entry is saved, the app computes a SHA-256 fingerprint over a single text string built from the entry’s fields, joined with the | character. The result is stored as lowercase hexadecimal. Two layouts exist; each entry records which one it used (hash_version).
| Version 2 (current) | The literal v2, entry id, case id, type, title (trimmed), summary (trimmed), transcript (trimmed, empty if none), capture time (milliseconds since 1970, UTC), location, capture source, EXIF, previous entry’s fingerprint in the same case (empty for the first), and the attachment fingerprints sorted and joined with commas. |
|---|---|
| Location field | Latitude and longitude to 6 decimal places and the place label, joined with |. An empty string when no location was recorded. |
| EXIF field | The stored EXIF object serialized as JSON with keys sorted alphabetically at every level; null when absent. |
| Version 1 (earlier entries) | Entry id, case id, type, title, summary, transcript, capture time, attachment fingerprints in stored order. Version 1 entries are never recomputed under version 2. |
Because each version 2 entry includes the previous entry’s fingerprint, entries in a case form a chain: changing or removing an earlier entry changes every later fingerprint.
2. File fingerprints
Each attached file (photo, video, audio, document) gets its own SHA-256 fingerprint, which is included in the entry fingerprint above.
Important for anyone checking a file: in the CaseGuardian™ mobile app the file fingerprint is SHA-256 of the file’s standard base64 text (RFC 4648, with padding), not of its raw bytes. In a web browser it is SHA-256 of the raw bytes. To reproduce a mobile fingerprint with common tools:
base64 -w0 FILE | sha256sum # Linux base64 -i FILE | tr -d '\n' | shasum -a 256 # macOS
The verification page computes both forms in your browser.
3. Device signature
| Algorithm | Ed25519 |
|---|---|
| What is signed | The 32 bytes of the entry fingerprint (the hexadecimal decoded to bytes). |
| Key | Generated on the device and stored in the phone’s secure storage (iOS Keychain or Android Keystore-backed storage). It is a software key; it is not bound to a hardware security chip and CaseGuardian™ makes no hardware-attestation claim. The private key is never sent to CaseGuardian™. |
| Key id | The first 16 hexadecimal characters of SHA-256 of the public key. |
| Registration | The public key and key id are registered to the account; the registration is written to the custody log (section 6). |
| What a valid signature shows | That the registered device key signed that exact fingerprint. It does not identify the person holding the device. |
4. Timestamps
| OpenTimestamps (Bitcoin) | Each entry fingerprint is submitted through a CaseGuardian™ server relay to public OpenTimestamps calendars (a.pool.opentimestamps.org, b.pool.opentimestamps.org, alice.btc.calendar.opentimestamps.org). The relay keeps the user’s IP address out of calendar logs. The calendar later commits the fingerprint to a Bitcoin block. The resulting .ots proof shows the fingerprint existed at or before the time of that block, and can be checked with independent OpenTimestamps tools. |
|---|---|
| RFC 3161 (time-stamp authority) | The fingerprint is also sent to an RFC 3161 time-stamp authority: freetsa.org first, then DigiCert, then Sectigo, each tried only if the one before it does not return a token. The signed token is stored with the entry. |
| Device clock | The capture time in the fingerprint comes from the phone’s clock. The external timestamps bound it from above; nothing in this system bounds it from below. |
5. Encryption
| Master key | 256 bits, derived on the device as SHA-256 of a 120-bit recovery seed. The seed is shown to the user once as a 24-character recovery code (Crockford Base32). Neither the seed nor the master key is sent to CaseGuardian™. If the device and the recovery code are both lost, the data cannot be decrypted by anyone, including CaseGuardian™. |
|---|---|
| Case key | Each case has its own random 256-bit key, stored on the server only in wrapped form (AES-256 key wrap under the master key). |
| Content | Titles, summaries, transcripts and attached files are encrypted with AES-256-GCM before upload. Blob layout: 1-byte version, 12-byte nonce, ciphertext, 16-byte tag. Additional authenticated data: the entry id (UTF-8) followed by the crypto version byte. |
| Not encrypted | Location (coordinates and label), timestamps, fingerprints, signatures and other metadata needed for verification are stored without this encryption. |
6. Custody log
Changes to evidence records, and events such as shares and exports, are recorded in a server-side log that can only be added to. Each row stores a SHA-256 hash of the previous row, so removing or editing a row breaks the chain. Update and delete rights are withheld from every application role and a database trigger rejects any attempt. The chain head is committed to an external timestamp daily.
7. Share links
A share link carries its own key after the #k= mark. Browsers do not send that part of a link to any server, so CaseGuardian™ holds only encrypted content for a share. The recipient’s browser uses the key to unwrap the case key (AES-256 key wrap) and decrypt the content (AES-256-GCM, as in section 5). Links can require an access code; five wrong codes within 15 minutes lock the link for that period. Each time a link is opened the server logs the date and time, a truncated hash of the IP address and the browser type; it does not record who opened it.
8. Limits
This system can show that a file or record is unchanged since it was sealed, which device key signed it, and that it existed at or before an external timestamp. It cannot show who operated the device, that the device clock was correct, that an imported file is authentic before it was imported, or that any court will admit the evidence.