Skip to content

Security: CredenceOrg/Credence-Backend

Security

docs/security.md

Security Architecture

Encrypted Evidence Storage

Dispute and slash evidence submitted to the platform often contain sensitive user data. To ensure privacy, security, and integrity, all evidence is encrypted at rest before being saved to the database or object storage.

Encryption Standard

  • Algorithm: AES-256-GCM (Galois/Counter Mode).
  • Key Management: Managed via environment variables (EVIDENCE_ENCRYPTION_KEY). It must be exactly 32 bytes.
  • Integrity Validation: GCM provides an authentication tag (authTag). During decryption, this tag ensures the data has not been tampered with or corrupted in the storage layer.

Access Control (RBAC)

Access to decrypted evidence is strictly limited using Role-Based Access Control.

  • USER: Denied access to view encrypted evidence blobs.
  • ARBITRATOR: Granted access to retrieve and decrypt evidence for reviewing active disputes.
  • GOVERNANCE: Granted access to retrieve and decrypt evidence for auditing, slashing events, and platform management.

Evidence Audit Trail

All sensitive evidence actions are written to the immutable audit stream:

  • EVIDENCE_UPLOADED when evidence is stored
  • EVIDENCE_ACCESSED when evidence is decrypted and returned

Each event includes actor metadata, action name, timestamp, and evidence resource id, enabling compliance queries by actor, resource, and time range.

There aren’t any published security advisories