integrate with kernel keyring

[gzm55]

Hi, can we support to integrate the step-ca with kernel keyring on linux? Specifically, we can use the password via a key description as the cryptsetup tool does. Such as:

step-ca --password-description user:cert-password --provisioner-password-description user:admin-password

In addition, we should also use a thread-keyring to hold the password copy instead of a memory variable for reloading the configuration.

And last, if kernel supports, we could implement an x509 keyctl KMS using kernel keyctl_pkey_sign syscalls.

[tashian]

Hi @gzm55,

This would be a nice feature to have. You may be able to get by using bash command substitution to call keyctl, but you wouldn't get the benefit of hot reloading of the configuration.

So far, we've chosen to add support for HSMs and cloud KMS that can work from any platform, before adding OS-specific options like the Linux kernel keyring or the macOS Keychain.

I'm a developer advocate at smallstep. I'd love to hear how it's going for you with step-ca, and I'd be curious to hear a bit more about your use case for this proposal (and the SSH ACME idea you proposed)? Feel free to reach out at carl at smallstep.com

[gzm55]

Hi @tashian , we're trying step-ca for managing ssh login, k8s cert, sudo auth, etc., in our private cloud that cannot easily reach the public cloud KMS, yet not prepare a physical security room for the hardware HSM. we would like to control the attack surface asap, while the step-ca should very likely run on a linux machine, the keyring is a better choice to avoid the hdd side channel attack than password file, and easier to use than luks fs.

[gzm55]

in addition, bash substitution method works now, and the password file seems not be reloaded on reloading the config.

[maraino]

What do you think it makes more sense, support for --password-file from the keyring, or just grabing the keys from the keyring, keep them only in memory, (or even request it every time we need it if the performance is not a problem) and use those keys for signing operations.

[gzm55]

prefer the third one in the sense of security, but 2 is ok if #434 is fixed

1. current way, bash substitution password-file, works but the daemon config need a wrapper shims
2. native cache password from keyring, should be easily implement, but the swap memory is still in risk, and issue CA should prevent its process memory from being swapped to disk #434 mention this risk
3. only fetch the password from keyring on signing, and erase the cache asap. need much work, almost resistant to user level memory dump
4. kernel HSM, sign in kernel space. only supports x509, but the attacker have to work around the selinux to load kernel modules to dump this part memory.