Skip to content

Security

Bernd Schoolmann edited this page Feb 9, 2024 · 2 revisions

Locking behaviour

The 3 states for a vault are: Logged Out, Locked(No Key), Locked(With Key), and Unlocked. When you boot your system, the vault state is locked (no key). On the first time accessing the vault in this state, your pin is required, and it goes to "Unlocked. When your vault gets locked now, it is in locked (with key). In either locked (with key) or unlocked, first your biometrics/user password will be verified. If that does not work, your pin will be asked.

Locking happens when:

  • Your system is idle for 15 minutes
  • Your screen gets locked
  • You manually lock it

On the CLI/SSH, the calling application (terminal/vscode/etc.) is remembered and granted access for a while. This is bound to the calling applications, so any other application running under the same user would still have to authenticate.

Threat model

[WIP]

The threat model considers passive attackers against disk and memory, and very simple active attackers.

To prevent credential access from a copy of the filesystem, any config files are encrypted. The encryption key is derived from the pin using argon2 with a comparatively high config, such that is is prohibitively expensive to crack on consumer hardware (and, depending on the pin, even on non-consumer hardware clusters).

To prevent memory dumps, all encryption keys are stored in memguard enclaves, which use OS features and constantly rotating encryption to make memory dumps non-trivial. For more details on this scheme and the security implications, please visit the memguard wiki.

Furthermore, operating system features are used to prevent attaching debuggers, or dumping memory.

This does not protect against active attackers, especially if they are root users

For simple active attackers, biometric / pin access for credentials prevents easily dumping the vault / using the credentials.