1342228a51
- F12: Device Authentication section now names the relicario-server crate and its two subcommands (generate-hook, verify-commit), and notes that signed commits without the server-side hook provide authorship only — any pusher can still land an unsigned commit. - F11: drop the "optional before v0.4.0" version line (v0.4.0 was never tagged; v0.5.0 is the first release with the hook) and replace with a one-liner: registration is optional but recommended for shared vaults. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
74 lines
2.5 KiB
Markdown
74 lines
2.5 KiB
Markdown
# Relicario Security Model
|
|
|
|
## Cryptographic Protection
|
|
|
|
Relicario uses two-factor vault decryption:
|
|
1. **Passphrase** — user-memorized, zxcvbn score ≥3 required
|
|
2. **Reference image** — JPEG carrying 256-bit secret via DCT steganography
|
|
|
|
Key derivation: Argon2id (64 MiB memory, 3 iterations, 4 parallelism)
|
|
Encryption: XChaCha20-Poly1305 (192-bit nonce, 256-bit key)
|
|
|
|
## Manifest Integrity
|
|
|
|
The manifest (`manifest.enc`) is encrypted with AEAD, which provides:
|
|
|
|
- **Confidentiality**: Contents unreadable without master key
|
|
- **Integrity**: Any modification detected and rejected on decrypt
|
|
- **Authenticity**: Only master key holders can create valid ciphertexts
|
|
|
|
### What AEAD Does NOT Protect
|
|
|
|
- **Item deletion**: An attacker with write access can delete `.enc` files
|
|
or git-revert commits. The manifest decrypts successfully but won't
|
|
contain the deleted items.
|
|
|
|
- **Rollback attacks**: An attacker can replace `manifest.enc` with an
|
|
older valid version. AEAD accepts any ciphertext created with the key.
|
|
|
|
### Mitigation
|
|
|
|
Item deletion and rollback are detectable via **git history**:
|
|
|
|
```bash
|
|
git log --oneline items/
|
|
```
|
|
|
|
For environments where git history could be rewritten (force-push):
|
|
|
|
1. Enable device authentication (commit signing + pre-receive hook)
|
|
2. Use a git server that rejects non-fast-forward pushes
|
|
3. Regular backups with `relicario backup export`
|
|
|
|
## Device Authentication
|
|
|
|
When enabled, device authentication provides:
|
|
|
|
- **Commit authorship**: All commits signed by registered device keys
|
|
- **Push access control**: Deploy keys managed via Gitea API
|
|
- **Instant revocation**: One command cuts off both signing and push
|
|
|
|
Enforcement requires deploying the `relicario-server` pre-receive hook
|
|
on the vault remote. The crate provides two subcommands:
|
|
|
|
- `relicario-server generate-hook` — emits the hook script to install at
|
|
`<repo>/hooks/pre-receive`
|
|
- `relicario-server verify-commit <sha>` — checks one commit's signature
|
|
against `.relicario/devices.json` and `.relicario/revoked.json` as of
|
|
that commit; the hook calls this for every pushed ref
|
|
|
|
Without the server hook, signed commits provide authorship metadata only
|
|
— any process with push access can land an unsigned commit, since
|
|
verification is otherwise advisory.
|
|
|
|
See `docs/superpowers/specs/2026-05-02-device-authentication-design.md`.
|
|
|
|
## Access Control
|
|
|
|
Without device authentication, access control is transport-layer only:
|
|
|
|
- **CLI**: SSH key authentication to git remote
|
|
- **Extension**: Git credentials in browser storage
|
|
|
|
Device registration is optional but recommended for shared vaults.
|