Security & Trust
The full architecture on one page: the sealing process, node architecture, threat model and deployment. This page is written for technical evaluators.
01SEALING PROCESS
MÜHÜRLEME SÜRECİWhat happens when a file is sealed?
Four steps. Each one is an independent layer; losing one never brings down the rest.
Encrypted on the device
The file is end-to-end encrypted with a hybrid scheme before it ever leaves your device. Only you hold the key.
The server wraps it
The server wraps every chunk in an additional envelope whose keys are established with ML-KEM-768. This step never requires plaintext; only encrypted data reaches the server.
Chunked, spread across nodes
The file is split into chunks of up to 5 MB. Every storage node adds its own unique AES-256-GCM layer.
Committed to the ledger
Permissions and the audit trail are recorded in a cryptographically verifiable, append-only audit ledger. This permissioned ledger has no relationship with cryptocurrency or tokens.
02DEFENCE IN DEPTH
SAVUNMA DERİNLİĞİReal nodes blend into the crowd.
Storage nodes hide among decoy nodes that behave identically on the network. An outside observer has no practical way to tell the real nodes from the decoys.
INDISTINGUISHABLE.
03ASSUME BREACH
VARSAYIM: İHLALWhat if the worst happens?
We start the design from "the breach happened," not "it won't." Six scenarios, one outcome.
All network traffic is intercepted.
Encryption starts on the device; only ciphertext ever travels the wire.
RESULT: CIPHERTEXTRoot access on the servers is seized.
The server workflow never requires plaintext; what is seized is only ciphertext.
RESULT: CIPHERTEXTStorage nodes and AES keys are stolen.
Two independent layers remain below: the server envelope and device encryption.
RESULT: CIPHERTEXTAn authorised administrator turns malicious.
Content keys are never issued to administrator accounts; every attempt leaves a trace in the ledger.
RESULT: CIPHERTEXTA powered-off disk is physically stolen.
Not a single meaningful byte on the disk; the keys are elsewhere.
RESULT: CIPHERTEXTQuantum computers arrive.
Key establishment uses ML-KEM-768 (NIST FIPS 203), the post-quantum standard. The architecture is designed against "harvest now, decrypt later" attacks.
RESULT: CIPHERTEXT04ENCRYPTION, AUDIT & DISCLOSURE
ŞİFRELEME, DENETİM VE AÇIKLAMAEncryption and keys
Content is encrypted client-side and the keys are held under institutional control. The LpsKey is bound to the user; no content key is stored on the server side.
Audit integrity
The audit record lives in a cryptographically verifiable, append-only ledger. This permissioned ledger has no relationship with cryptocurrency or tokens.
Post-quantum implementation
Key establishment in the device and server layers uses ML-KEM-768 (NIST FIPS 203). The architecture is crypto-agile; algorithms can be replaced when needed.
Assurance and certifications
Certified to ISO 27001, ISO 9001, ISO 22301, ISO 20000-1 and SPICE. We work aligned with GDPR, NIST CSF 2.0 and NIS2.
Vulnerability disclosure
If you find a security issue, report it to security@lpschain.com. Reports receive a response within 72 hours; good-faith research is not pursued legally.