ADR-0003: Root Key Management and Storage Strategy
- Status: accepted
- Date: 2024-11-03
- Tags: Security, Storage, Encryption
Context
We need a secure strategy for managing the root key that SPIKE Nexus uses. This key is critical for the system’s security and requires:
- Secure storage
- High availability
- Disaster recovery capabilities
- Protection against unauthorized access
- Balance between security and operational needs
Decision
We will implement a multi-layered approach for root key management:
1. Runtime Storage:
- Root key will be stored in memory only as plain text
- This applies to both SPIKE Nexus and SPIKE Keeper components
2. Persistent Storage:
- Root key will be stored in PostgreSQL database
- The stored version will be:
- Salted
- Encrypted
- Protected by admin user’s password
Consequences
Positive
- Enhanced security through memory-only plain text storage
- Reduced attack surface as plain text key never touches disk
- Recovery possible through encrypted backup in PostgreSQL
- Admin password dependency ensures authorized access only
- Salting provides protection against rainbow table attacks
- Separation of concerns between runtime and persistent storage
Negative
- Memory-only storage means key is lost on service restart
- Dependency on admin user’s password for recovery
- Need to manage salt generation and storage
- Potential performance impact from encryption/decryption operations
- Risk of key loss if both admin password and memory contents are lost
- Additional complexity in key recovery procedures
Security Considerations
- Memory must be properly zeroed when key is no longer needed
- PostgreSQL access must be properly secured
- Admin password strength becomes critical for system security
- Salt management and storage must be handled securely
- Encryption algorithm and key derivation function must be carefully chosen
Implementation Notes
1. Memory Storage:
- Implement secure memory handling
- Use secure string implementations where available
2. PostgreSQL Storage:
- Use strong encryption algorithm (e.g., AES-256)
- Implement secure key derivation from admin password
- Ensure proper salt generation and storage
References
- ADR-0021: SPIKE Keeper as a Stateless Shard Holder
- ADR-0020: Switch to Zola for Documentation System
- ADR-0019: Plugin-Based Storage Backend Architecture
- ADR-0018: Administrative Access to SPIKE
- ADR-0017: Synchronous Persistence for SPIKE Secrets Store
- ADR-0016: Memory-First Secrets Store
- ADR-0015: Use Singular Form for File and Package Naming
- ADR-0014: Maintaining SQLite as SPIKE’s Primary Storage Backend
- ADR-0013: S3-Compatible Storage as SPIKE’s Backing Store
- ADR-0012: HTTP Methods for SPIKE API
- ADR-0011: PostgreSQL as SPIKE’s Backing Store
- ADR-0010: Session Token Storage Strategy for SPIKE Nexus
- ADR-0009: Multi-Administrator Support System
- ADR-0008: Administrative Access Control System
- ADR-0007: Root Key Lifecycle and Management Strategy
- ADR-0006: Trust Boundary Definition and Security Assumptions
- ADR-0005: Use SPIFFE mTLS for Inter-Component Authentication and Communication
- ADR-0004: SPIKE Keeper Minimalist Design Approach
- ADR-0003: Root Key Management and Storage Strategy
- ADR-0002: Use Docsify for Documentation System
- ADR-0001: Display Secrets in Plain Text in SPIKE Pilot Admin CLI