Security Model

The locked-state is not merely a feature but a mandatory security requirement in KERI implementations:

• Keystores MUST be encrypted by default upon creation
• Passcode authentication MUST be required for all keystore operations
• Implementations SHOULD auto-lock after configurable timeout periods
• Passcode strength requirements SHOULD be enforced (minimum length, complexity)

Encryption Standards

While the KERI specification does not mandate specific encryption algorithms, implementations typically use:

• AES-256 for symmetric encryption of the keystore
• PBKDF2 or Argon2 for passcode-based key derivation
• Authenticated encryption (e.g., AES-GCM) to prevent tampering

Operational Considerations

Session Management

Implementations must balance security with usability:

• Short-lived unlocked sessions: Minimize exposure window
• Explicit lock operations: Allow users to immediately return to locked-state
• Memory protection: Clear sensitive data from RAM when locking

Multi-Tenant Environments

In cloud-based KERI services like KERIA:

• Each agent maintains its own locked-state keystore
• Passcodes are never transmitted or stored in plaintext
• Keystore isolation prevents cross-tenant access

Recovery Scenarios

The locked-state model requires careful consideration of passcode loss:

• No backdoor: By design, lost passcodes mean permanent loss of access
• Backup strategies: Users should maintain secure backups of keystores
• Social recovery: Some implementations may support threshold-based recovery mechanisms

The locked-state represents a fundamental security primitive that ensures KERI's cryptographic material remains protected at rest, implementing defense-in-depth alongside the protocol's cryptographic guarantees.