Platform security
Trust by construction.
Six independent layers between user data and any attacker — cryptographic floor, identity scope, provable authorship, validator quorum, replayable audit, public disclosure. None of them is "trust us"; each is verifiable from outside AEVION.
01
Quantum Shield — cryptographic floor
Master keys split via Shamir's Secret Sharing (k of n). Ed25519 signatures everywhere. Key derivation designed to remain credible after the post-quantum transition.
02
Identity — single account, scoped permissions
One AEVION account drives 27 modules. JWT bearer with short lifetime + refresh; passkey-ready stack. Private data is never exposed through the public Trust Graph.
03
Authorship — provable, on-chain timestamps
QRight registers SHA-256 + HMAC + Quantum Shield hash before any third party can see the work. Proof can be presented offline; verification is open at /verify.
04
Validators — public quorum, no opaque jury
Planet routes submissions to independent validators. Verdicts are co-signed and published on-chain — anyone can re-check the quorum without trusting AEVION.
05
Audit — Merkle-tree trails, replayable
Every privileged action is appended to a Merkle-tree audit log. Receipts are exportable as Ed25519-signed PDFs and verifiable from any device, including offline.
06
Disclosure — RFC 9116 security.txt
Vulnerability reports and responsible disclosure are accepted at the standard /.well-known/security.txt contact. Acknowledgments live on the public changelog.
Compliance map
We ride the standards bodies, not predict them. Each module is wired to an existing legal framework.
eIDAS
EU electronic signatures
QSign signature framework + Bureau certificates
ESIGN Act
US e-signature law
QSign signatures recognised across US jurisdictions
Berne
International copyright
QRight authorship → recognised across 181 signatories
WIPO + TRIPS
Global IP frameworks
Bureau certificates cite both standards on issuance
GDPR
EU data protection
Minimal data, right-to-erase, audit log on access
KZ Digital Sig
Kazakhstan e-signature law
Native first-class — QSign aligned from day 1
Frequently asked questions
Where is the data stored, and who can access it?
Authorship and payment data live in encrypted PostgreSQL with row-level access control. Master keys never leave Quantum Shield (k-of-n shards across independent stores). No employee has unilateral access — all privileged actions are logged to a Merkle-tree audit trail.
What happens if a private key is compromised?
Quantum Shield key recovery: rotate the affected shards (any K of N is enough to reconstruct), revoke the compromised public key in QSign, re-sign the affected receipts, broadcast revocation through the Planet validator network. Authorship timestamps remain valid because they're separate from the user signing key.
Are you ready for post-quantum?
The signature stack today is Ed25519, the same as Signal, GitHub and most major secure platforms. Quantum Shield's KDF is post-quantum-ready — key derivation can swap to a PQ-safe primitive (e.g. ML-KEM) without re-issuing existing receipts. Dilithium preview is already in the QSign repository.
How do you handle vulnerability reports?
Send to yahiin1978@gmail.com with subject 'AEVION security' or use the /.well-known/security.txt contact. Acknowledgment within 24 hours, fix coordination per CVD norms, public credit on /changelog once mitigated.
Do you publish a SOC 2 / ISO 27001 report?
Not yet — at MVP scale we ship the controls before paying for the audit. The control map (encryption at rest, least-privilege access, audit trails, incident response) is implemented and documented for under-NDA review.
Reach the security team
yahiin1978@gmail.com — subject "AEVION security", ack within 24h.
Disclosure file: /.well-known/security.txt · Vulnerability acknowledgments: /changelog.