[Bug 3355] New: no-touch-required flag not restored from hardware token

[bugzilla-daemon at mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=3355

            Bug ID: 3355
           Summary: no-touch-required flag not restored from hardware
                    token
           Product: Portable OpenSSH
           Version: 8.4p1
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: ssh-keygen
          Assignee: unassigned-bugs at mindrot.org
          Reporter: snegrea at gmail.com

no-touch-required flag is not set by ssh utilities when a key is
restored from hardware tokens and defaults to always requiring user
presence. Even when ed25519_sk or ecdsa-sk keys are generated with
no-touch-required active, the process or restoring the key on another
computer or using the key without downloading will result in always
requiring touch because the flag is not properly restored.

This incorrect behavior is consistent for ed25519_sk and ecdsa-sk keys.
I have tested and replicated the issue with SoloKey or Yubikey hardware
tokens.


After looking at the openssh code it seems that the flag below is never
properly used when reading or restoring a key from hardware tokens: 

sk-api.h
  #define SSH_SK_USER_PRESENCE_REQD   0x01


Here is lists of steps to fully reproduce the issue:

Step 1. Generate a new ed25519_sk. This new key will be stored in
.ssh/id_ed25519_sk. Please note the `no-touch-required` and `resident`
parameters on the key generation.

$ ssh-keygen -vvvv -t ed25519-sk -O no-touch-required -O resident -O
application=ssh:test

Step 2. Confirm the generated key has `no-touch-required` option
enabled with ssh-keygen. In the output below, please note sk_flags
0x20. This is the correct value for a key generated with resident and
no-touch-required additional flags.

$ ssh-keygen -v -y -f id_ed25519_sk
sk-ssh-ed25519 at openssh.com
AAAAGnNrLXNzaC1lZDI1NTE5QG9wZW5zc2guY29tAAAAIF7VJC49NC4UjXCS9H4PhmH5Jfnh+TLKOHfttd9mL3h4AAAACHNzaDp0ZXN0
my at desktop
debug1: sk_application: "ssh:test", sk_flags 0x20


Step 3. Configure the server with to accept the new key by adding it at
the end of `.ssh/authorized_keys`; `no-touch-required` option is
required on the server.

no-touch-required sk-ecdsa-sha2-nistp256 at openssh.com A....


Step 4. Attempt to connect to the server with newly setup key, please
note that no-touch-required works as expected, and the key is loaded by
default from ssh-agent which has the correct flags. The client will
connect to the server without requiring a hardware token touch.

$ ssh -vvvv user at server 


Step 5. Delete the key files from the disk of the client

$ cd .ssh
$ rm id_ed25519_sk
$ rm id_ed25519_sk.pub

Step 6. Clean ssh-agent from any loaded certificates

$ ssh-add -D

Step 7. List the keys loaded by ssh-agent to ensure the key generated
at step 1 is no longer available to ssh-agent

$ ssh-add -L

Step 8. Attempt again to connect to the server after removing the key.
This should fail because the key is now deleted from disk and memory.
At this time the key only exists on the hardware token but not
available at all to ssh utilities on the client machine.

$ ssh -vvvv user at server
.... fails to authenticate .....



So far everything works as expected with regards to no-touch-required,
however the next few steps will show the problem. There are two ways to
reproduce the issue. First attempt will use the keys from memory
without downloading them on disk. 


Step 9. Load the key from the hardware token into ssh-agent without
downloading the key to disk.

$ ssh-add -K
Enter PIN for authenticator: 
Resident identity added: ED25519-SK SHA256:

Step 10. List the keys loaded by ssh-agent to ensure the key generated
at step 1 is now available again to ssh-agent.

$ ssh-add -L

Step 11. Try to connect to the server again, the authentication works
but a touch is required because they key was not restored properly from
the hardware token. 

$ ssh user at server 
.... touch required .....


Alternatively, here is one more way to reproduce the issue. The first 8
steps are identical, but this time download the file on disk from the
hardware token.

Step 9. Download the key files from the hardware token to local disk in
.ssh folder

$ cd .ssh
$ ssh-keygen -K
Enter PIN for authenticator: 
You may need to touch your authenticator to authorize key download.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Saved ED25519-SK key ssh:test to id_ed25519_sk_rk_test

Step 10. Rename the downloaded keys to default file names expected by
ssh-agent

$ mv id_ed25519_sk_rk_test id_ed25519_sk
$ mv id_ed25519_sk_rk_test.pub id_ed25519_sk.pub

Step 11. Connect to server again, a touch is required because they key
was not restored properly from the hardware token. 

$ ssh user at server 
.... touch required .....

Step 12. Review the downloaded key from hardware token to confirm it
lost `no-touch-required` flag. In the output below, please note
sk_flags 0x21, which means the key lost no-touch-required flag from the
initial configuration during the restore process.

$ ssh-keygen -vvvv -y -f id_ed25519_sk
sk-ssh-ed25519 at openssh.com AA.......... ssh:test
debug1: sk_application: "ssh:test", sk_flags 0x21



For these tests, I used standard Ubuntu 21.04 installations with no
modifications on both server and client. This includes running
distribution standard ssh packages.

$ uname -a
Linux 5.11.0-34-generic #36-Ubuntu SMP Thu Aug 26 19:22:09 UTC 2021
x86_64 x86_64 x86_64 GNU/Linux

$ ssh -V
OpenSSH_8.4p1 Ubuntu-5ubuntu1.1, OpenSSL 1.1.1j  16 Feb 2021

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 21.04
Release:        21.04
Codename:       hirsute



For additional details please review this thread:
https://github.com/solokeys/solo/issues/374#issuecomment-912943294

-- 
You are receiving this mail because:
You are watching the assignee of the bug.