Feature request: Hardware key support

1

Any plan for restic to add support for Challenge Response from a hardware key, such as a Yubikey?

Similar to keepassxc.

2

Not at this point, no: https://github.com/restic/restic/issues/3315#issuecomment-815590801

1 Like
3

It seems the closest solution is:

—password-command=“pass restic_password”

with restic_password GPG encrypted, and GPG key in Yubikey.

  • How much a password is exposed to the operating system using this approach?

  • How does this approach compare with direct support for hardware key in restic?

I don’t know how —password-command is implemented in Go to see how it handles the password.

4

Not really the answers you’re looking for but:

1 Like
5

Thank you, that was useful.

After this code is executed:

if opts.PasswordCommand != “” {
args, err := backend.SplitShellStrings(opts.PasswordCommand)
if err != nil {
return “”, err
}
cmd := exec.Command(args[0], args[1:]…)
cmd.Stderr = os.Stderr
output, err := cmd.Output()
if err != nil {
return “”, err
}
return (strings.TrimSpace(string(output))), nil

it’s unclear which OS processes (and their child processes) and restic variables have access to return value of this code and for how long.

I guess restic holds password, after calling this function, in RAM? Or calls this function on demand (password will not be held in ram)?

I suppose password is securely erased from RAM once the operation is finished?

Hard to see. I am not a Go programmer.

6

It’s just restic and the child process AFAICI. As you can see restic executes the process and sucks in the output from it. Other processes than these shouldn’t have access to the data, but someone will have to verify that to be sure.

Yes, it will hold it in RAM. Even if it’s just for a brief moment, it’s still held in RAM, so there’s no such thing as not holding it in RAM. How would you expect restic to read something from another process and not hold it in memory at some point?

Probably depends a lot on the operating system and how it manages its memory.

2 Likes
7

Concerning your question, restic could read it from a hardware security module or an encrypted file on hard disk (with password on HSM. OS or a third party app such as gpg-agent will retrieve the plaintext password and send to restic whenever restic needs it, without holding anything in ram).

But it may not be perhaps practical, since restic should need the password for every blob and needs to constantly communicate with HSM or a third party agent.

8

Regardless from where restic reads the password, it still needs to hold it in some memory, right?

1 Like
9

No, as I said, restic needs the password, but doesn’t care where it’s held.

You can hold it in TPM, for instance. Restic will communicate with TPM instead of RAM in real-time.

10

If it supported that type of setup, which is what your initial question was about, but not when you read it in.

11

Restic reads the password and uses it to decrypt the master key which is used for the encryption. So with this in mind I guess it could use a hardware device without having to communicate all the time.