[systemd-devel] [PATCH] add keyscript support to cryptsetup

Mike Kazantsev mk.fraggod at gmail.com
Mon Jul 30 00:40:51 PDT 2012

On Wed, 11 Jul 2012 09:29:55 +0200
David Härdeman <david at hardeman.nu> wrote:

> > Note that if compat is really that important it should be possible to
> > write an agent that can invoke keyscripts like this. If you did that you
> > would gain, among other things the ability to query for passwords at the
> > same time via different methods. With a bit of C code it should be
> > fairly easy to hack up an agent that just invokes a keyscript.
> The biggest question in my mind right now is how the "keyscript" password
> agent should be implemented and how it should interact with the other
> agents.
> Imagine the scenario where crypsetup wants to set up a partition using a
> binary key from a smartcard, which in turn requires a PIN to be entered:
> 1) Following the current logic, the systemd cryptsetup binary would ask
> for the key to the partition using /run/systemd/ask-password/ask.foo. (That
> file could potentially be extended to add something like an "Options="
> field where we could provide additional information about the password
> request to the agents).
> 2a) The "keyscript" agent would read the ask.foo file and determine that
> it can provide the requested key from a smartcard (I assume this knowledge
> comes from some config file)
> 2b) At the same time, the other agents provide normal password input
> prompt(s) to the user (e.g. on the tty)...which are pointless since a
> binary key is expected.
> 3) Soon afterwards, the "keyscript" agent in turn uses
> /run/systemd/ask-password/ask.bar to request the PIN for the smartcard.
> 4) The user would be confronted with two passphrase prompts. One
> (pointless) one to provide a binary key using the keyboard, and one (real)
> prompt for the PIN to the smartcard.
> I'm not sure what kind of changes to the password agent scheme you're
> envisioning to accommodate a scheme like this?

With systemd password agent, I think it can be solved in the following

1) /run/systemd/ask-password/ask.foo is created and
systemd-ask-password-console pops up a prompt for it.

2) At the same time, systemd-smartcard-password agent detects the
created file and reads it, then check for a smartcard device, waiting
for it to appear.

3) If/when proper smartcard device appears (and is recognized by
middleware), it unlinks /run/systemd/ask-password/ask.foo and prompts
for PIN.

4) systemd-ask-password-console detects query-file removal and hides
it's prompt, leaving only query for PIN.

5) If PIN provided to systemd-smartcard-password is incorrect (or
smartcard disappears, or user times out), it provides systemd with
empty password (emulating it being incorrect) or "request cancelled"

Does it make any sense?

> >> 3) systemd specific solution
> >> 
> >> Converting keyscript= scripts to password agents introduce a strong
> >> dependency on systemd. I realize that you don't consider it to be a
> >> problem but I'm guessing it wouldn't be acceptable to Debian (where
> >> systemd is not mandatory).
> > 
> > Well, it's currently a Debian-init scripts specific solution...
> Yep, but it's a useful solution. Right now you have no way of supporting
> e.g. smartcards or other interesting sources of key material which might
> come along down the line. Such functionality should be supported (not
> necessarily by using keyscript= of course).

While probably exactly not what you seek, but I've actually implemented
smartcard / systemd / cryptsetup glue about a year ago.

It doesn't work purely on systemd-level though, as dracut had to get
the key first, and I didn't have systemd in it at that moment.

To get the key for LUKS slot, udev rule is generated by dracut (if
proper cmdline flag was present), which runs a script once smartcard
is detected, which extracts the key (as necessary) and just puts it
into /run/initramfs (with strict root-only permissions).

After that, both dracut (with a bit patched "crypt" module) and custom
systemd password agent try to satisfy password requests (for
popping-up encrypted lvm partitions) from that cache-file.

Specal .service removes that file After=local-fs.target.

Not sure if this description is useful to you, but that's one (still
working flawlessly, btw, though maybe by accident) way to support that

Agent implementation can be found here:

A post describing the process in (maybe) a bit more detail:

> Regards,
> David

Mike Kazantsev // fraggod.net

More information about the systemd-devel mailing list