Platform · Security
Security architecture.
TrueSign is engineered around an explicit threat model and a small set of well-understood cryptographic primitives. There are no proprietary algorithms in the trust path.
Cryptographic primitives
Standardized, auditable, replaceable.
Every primitive in the signing path is standardized by NIST or the IETF and independently auditable. The protocol is versioned to allow controlled migration.
Signing
Ed25519 (RFC 8032) and ECDSA P-256 over canonical intent. Hybrid post-quantum signatures (ML-DSA) on opt-in basis.
Hashing
SHA-256 (FIPS 180-4) and SHA-384 for canonical intent and receipt construction.
Transport
TLS 1.3 with mTLS for institutional callers. Certificate pinning for SDK clients.
Attestation
iOS App Attest, Android Key Attestation, Windows TPM 2.0 attestation, HSM vendor attestation.
Key custody
Non-exportable private keys held inside Secure Enclave, StrongBox, TPM 2.0, or FIPS 140-3 Level 3 HSM.
Receipt
Detached signature over canonical intent + verifier policy hash + ledger commitment. Verifiable without TrueSign infrastructure.
Threat model
Explicit defenses.
| Threat | TrueSign control |
|---|---|
| Compromised host OS | Private key material is non-exportable from hardware. Host compromise cannot exfiltrate signing keys. |
| Phishing / social engineering | Approval is bound to canonical intent. The user confirms a specific transaction, not a session token or OTP. |
| SIM swap / number-port attack | TrueSign does not depend on telephone identifiers, SMS, or voice channels for authorization. |
| Replay and substitution | Canonical intent includes nonces, time bounds, and policy context hashes. Receipts are non-replayable across counterparties. |
| Insider tampering | Append-only hash-chained ledger plus optional external notarization. Tampering is detectable end-to-end. |