Signature Integrity at SignVerse
Why a document signed on SignVerse can be trusted — and defended.
1.What "integrity" means for an e-signature
A signature is only as strong as the evidence behind it. For a signed document to hold up — in an internal dispute, a customer disagreement, or a courtroom — you need to be able to show four things:
- What exactly was signed (and that it hasn't changed since),
- Who signed it (and how their identity was verified),
- How the ceremony happened (when, in what order, from where),
- That the record itself is trustworthy (it cannot have been quietly edited after the fact).
SignVerse is engineered so that each of these has independent, verifiable evidence.
2.Verified signing ceremonies
- One-time codes delivered by the recipient's configured channel, with short expiry, attempt limits, and lockouts.
- Access passwords with brute-force lockout (failed attempts freeze the ceremony temporarily).
- Delivery preferences per recipient — verification mode, code channel, and allowed signature formats are set per recipient and recorded.
- In-person and mobile ceremonies are first-class: QR handoff to a phone uses a short-lived, two-step-claim token so only the intended device can pick up the session.
Every step — viewed, started, verified, signed, declined, delegated — is written to the audit trail as it happens.
3.The tamper-evidence chain
At every material stage of a document's life — original upload, fields locked for signing, each individual signer's completion, any revision or amendment, and final completion — SignVerse computes a cryptographic snapshot (SHA-256) covering:
- the document's content state,
- the exact field layout and each signer's entered values,
- the full recipient assignment,
- the signature itself,
- and the hash of the previous snapshot.
That last element is what makes the record a chain: every snapshot is mathematically bound to everything that came before it. Change any value, signature, or ordering after the fact — even one byte — and the chain no longer verifies. SignVerse can re-derive and verify the entire chain on demand, and the chain's head hash travels with the document.
4.Cryptographic seals
- The head of the tamper-evidence chain is bound into a seal bundle.
- The platform signs that bundle with a detached CMS/PKCS#7 digital signature (ES256), with the signing key's identity — key ID, fingerprint, and public certificate — recorded in a key registry so the seal is attributable and verifiable independently of SignVerse.
- Optionally, an external trust provider adds an independent attestation (its own transaction ID and attestation hash), giving you a second, third-party witness to the evidence.
SignVerse also supports embedded PAdES-LTV sealing (long-term validation inside the PDF itself, with the certificate chain, OCSP/CRL responses, and timestamp embedded in the Document Security Store) alongside the detached platform seal. The detached seal remains — it binds the tamper-evidence chain, which PAdES itself does not know about — so both witnesses are always available.
5.Signature forensics
SignVerse goes beyond "a box was drawn" — every captured signature is analyzed by a deterministic forensic engine:
- Behavioral analysis of the signing motion (velocity and stroke dynamics) flags robotic or synthetic input.
- Biometric consistency compares each signature against a rolling baseline built from that signer's previous signatures.
- Context checks include multi-factor verification presence, geographic consistency between claimed location and network origin, and risky (disposable) email domains.
Each check contributes a fixed, published-in-code penalty weight to a 0–100 score — there is no machine-learning black box, so every score can be explained, reproduced, and defended. Scores band into Highly Authenticated, Compliance Warning, and Forensic Fraud Alert; a fraud-alert score automatically quarantines the envelope.
6.Quarantine: humans decide, auditably
A quarantined envelope cannot quietly proceed. It enters a review workflow where an authorized reviewer (permission-gated) examines the forensic evidence and decides: approve, reject, or require re-signing. The decision, the reviewer's identity, and the forensic context are permanently recorded. The forensic ledger itself is append-only — one immutable row per signature, including the full penalty detail.
7.An audit trail that can't be edited
The audit trail is append-only by construction: application code contains no path that updates or deletes an audit record. It captures the envelope lifecycle, every ceremony step, verification events (never the codes themselves), seal creation, quarantine decisions, and administrative actions — each with a timestamp and the true actor (a person's email, an API client's ID — never one masquerading as the other). Personal data inside audit details is masked.
8.Signing links that behave like evidence
- Links carry 256-bit random tokens — unguessable, with no sequential or internal IDs.
- Tokens are stored only as hashes, so even a database breach yields no usable links.
- When a document is revised, prior links are tombstoned: a recipient with a stale link sees an honest "older version" notice (and cannot sign the wrong version), while a probing attacker learns nothing.
- Completed-document downloads use dedicated tokens with expiry, revocation, and download-count limits.
9.The evidence pack, end to end
For any completed document, SignVerse can produce: the sealed document, the verified tamper-evidence chain, the full ceremony audit trail, per-signature forensic scores with their explanations, and the seal's key identity and any third-party attestation. Together these support the core requirements of electronic-signature frameworks such as ESIGN/UETA and the principles of eIDAS advanced signatures — the signature is uniquely linked to the signer, capable of identifying them, and bound to the document such that any subsequent change is detectable.