Threat Model
This page outlines the threats Veylent is designed to resist and the assumptions under which those protections hold.
Assets Under Protection
- Document integrity -- The signed document must not be modifiable after signing without detection
- Signer identity -- The signer's personal data must remain private except to QR holders
- Signing timestamp -- The time of signing must be provably anchored
- Signature binding -- It must be infeasible to transfer a signature from one document to another
Threats & Protections
Document Tampering
Threat: An attacker modifies the document content after signing.
Protection: Each signer's sealed record holds the SHA-256 of the file exactly as they saved it, and its fingerprint is anchored on-chain. Desktop verification cuts the file at each signer's layer, re-hashes it and compares. A change to any signed byte fails every signature that covers it (document-mismatch), and anything appended after the last signature is reported as changed-after-signing.
Limitation: A QR scan confirms who signed and when, but never sees the document, so it can't detect changes. Checking a copy requires the desktop app.
Signature Forgery
Threat: An attacker creates a fake signature on a document they did not sign.
Protection: Creating a valid signature requires submitting a transaction through the smart contract. The attacker would need to either compromise the API relay credentials, or deploy their own contract (which would have a different address, detectable by verifiers).
Signer Data Exposure
Threat: The server operator reads signer personal data.
Protection: Signer data is encrypted before leaving the desktop app. The API stores only the ciphertext. The decryption key exists only in the QR code's URL fragment, which is never transmitted to the server.
Assumption: The API server code does not log or exfiltrate QR URLs. This is verifiable through code audit (the codebase is open source).
Replay Attack
Threat: An attacker takes a valid signature from document A and attaches it to document B.
Protection: The sealed record holds the hash of document A's signed bytes, so document B fails the document-hash check. The QR code is inside the fingerprinted layer, so copying it onto B doesn't carry A's hash with it. A random salt ensures that even identical documents produce different records.
Man-in-the-Middle (API)
Threat: An attacker intercepts the relay request and substitutes a different hash.
Protection: The composite hash is deterministic -- the app can recompute it independently and verify the on-chain record matches.
QR Code Substitution
Threat: An attacker replaces the QR code in a signed PDF with one pointing to a different signature.
Protection: The QR code is part of the signer's fingerprinted layer. Replacing it inside that layer changes the document hash (document-mismatch); drawing a new one in a later layer is reported as changed-after-signing.
Limitation: A QR scan only checks the signature the code points to. Someone holding a printout with a pasted-in QR code sees that other signature's details, so check the file itself in the desktop app.
Record Substitution
Threat: The server operator, or an attacker with database access, swaps a signature's sealed record for different signer details.
Protection: Both the scan page and desktop verification require the decrypted record to hash to the composite hash on chain and to name the scanned anchor ID. A substituted record fails with "Doesn't match the blockchain" (record-mismatch on the desktop), and its details aren't shown.
Assumptions
- The cryptographic primitives are sound -- SHA-256 collision resistance and AES-128 confidentiality hold
- The blockchain is immutable -- Standard assumption for established chains
- The signer's machine is not compromised -- A compromised machine could sign arbitrary documents
- The API server relays transactions honestly -- Verifiable through code audit and post-anchor verification
- HTTPS is used in production -- Prevents eavesdropping on encrypted payloads in transit