Security
Security
Encryption, identity, revocation, and review boundaries.
MeshKit's security model starts with a narrow promise: content is encrypted before provider storage, and providers should not need plaintext to store, retrieve, persist, or route encrypted data.
The rest of the security story depends on identities, provider metadata, runtime key storage, policy checks, and application behavior.
Guarantees MeshKit Is Designed For
- Encrypt content before writing provider bytes.
- Verify CID-addressed bytes before decrypting.
- Fail closed when a share is expired, revoked, policy-denied, vault-bound, or missing capability requirements.
- Keep provider tokens, private keys, and capability secrets out of normal return values.
- Surface classified failures as
MeshKitErrorwhere possible.
Non-Goals And Limits
- MeshKit cannot protect plaintext after your app decrypts and exposes it.
- Revocation cannot erase content already copied or cached outside MeshKit.
- A CID is normally for encrypted envelope bytes, not plaintext.
- A stock IPFS node does not provide MeshKit metadata routes.
- Mobile key vault support does not automatically mean non-exportable hardware-backed cryptographic operations.
- Current public crypto claims should not be described as FIPS-certified, HPKE, or post-quantum.
Security Reading Path
- Envelope encryption
- Threat model
- Identity and sharing
- Revocation
- Mobile key vaults
- FIPS and PQC roadmap
- Security reviews
Production Review Checklist
- Are provider tokens and private keys kept out of source control and logs?
- Does production use a real provider boundary rather than
local-dev? - Does the provider include MeshKit metadata support?
- Are identity creation, contact verification, and recovery documented?
- Are share revocation and already-decrypted plaintext limits documented to users?
- Are live-provider validation outputs saved as evidence?
- Are telemetry and support bundles redacted?