GNOME Keyring Password Hashing and Suspend Locking

GNOME manages desktop secrets through the GNOME Keyring daemon, relying on cryptographic key derivation functions like PBKDF2 and standard ciphers like AES to safeguard credentials on disk. While GNOME integrates with system authentication during initial login, its handling of keyring locking during system suspension is designed around usability, meaning keyrings typically remain unlocked in system memory unless specifically configured otherwise.

Password Hashing and Key Derivation

GNOME Keyring does not store user secrets in plaintext. Instead, it maintains encrypted credential stores—most notably the login.keyring—located in the user's ~/.local/share/keyrings/ directory.

  • Key Derivation: When a user sets or updates a keyring password, GNOME Keyring uses a Password-Based Key Derivation Function (PBKDF2) paired with a cryptographic hash (typically SHA-256) and a pseudo-random salt. This process iteratively hashes the passphrase to derive a strong symmetric encryption key, significantly increasing the computational cost of brute-force attacks against stored keyring files.
  • Symmetric Encryption: The derived key is used to encrypt the stored credentials using the Advanced Encryption Standard (AES) cipher, typically in Cipher Block Chaining (CBC) or GCM mode depending on the underlying cryptographic backend (libgcrypt).
  • PAM Integration: During a standard system login, the Pluggable Authentication Module pam_gnome_keyring captures the user's login password and uses it to automatically derive the decryption key, unlocking the default keyring without requiring a secondary prompt.

Keyring Locking on System Suspension

When a GNOME system enters a suspended state (such as suspend-to-RAM), the desktop environment prioritizes background functionality over automatic cryptographic locking.

Default Suspension Behavior

By default, GNOME Keyring does not lock itself when the system suspends or when the screen locks. Once unlocked via PAM or manual user entry, the master keys and decrypted secrets persist in the gnome-keyring-daemon process memory. This architectural choice prevents connectivity failures upon waking; network services (such as NetworkManager reconnecting to Wi-Fi) and background applications (such as mail clients and instant messengers) can immediately access required tokens without prompting the user for redundant passwords before or immediately after the lock screen is cleared.

Memory Protection Mechanisms

Although secrets remain in memory during sleep:

  • Memory Locking (mlock): The daemon uses the mlock() system call on platforms where permissions allow. This prevents sensitive memory segments containing master keys and cleartext credentials from being swapped to disk, protecting secrets if the swap partition is unencrypted during hibernation (suspend-to-disk).
  • Process Isolation: The memory remains accessible only to the specific user session and the root user, enforced by standard Linux discretionary and mandatory access controls (DAC and SELinux/AppArmor).

Enabling Locking on Suspend

For security-conscious environments, automatic locking can be implemented, though it requires administrative or user-level intervention:

  • Custom Systemd Hooks: Users can leverage systemd-logind event hooks. By placing a script in /usr/lib/systemd/system-sleep/ or listening to the D-Bus PrepareForSleep signal on org.freedesktop.login1.Manager, a script can execute commands (such as communicating with the daemon over D-Bus via secret-tool or dedicated APIs) to explicitly lock the keyrings before the system sleeps.
  • Timeout Inactivity: While the default keyring is tied to the login session, secondary custom keyrings created through the GNOME "Passwords and Keys" (Seahorse) interface can be manually configured to lock automatically after a period of inactivity or upon demand.