Allow pam_systemd_homed to be forced to ask for FIDO2 pin

[arianvp]

Is your feature request related to a problem? Please describe.
I'm currently using https://github.com/Yubico/pam-u2f so that I can use my yubikey to login to my computer without a password; but with the PIN of my yubikey instead.

However, I also want to use homed for portable home diretories. However from the code I understand this would mean that I would have two FIDO credentials and I will be prompted for test of user presence twice. Once to authenticate with pam-u2f and once to unlock the LUKS2 container in pam_systemd_homed

homed also supports this functionality; However with pam-u2f I can configure that i'm always prompted for a pin (as it sets uv = true when creating and asserting the token). homed currently seems to hardcode uv = false which means I do not get prompted for my pin when unlocking my user account. I don't find this sufficiently secure and would like to configure this.

Describe the solution you'd like
Because we have all the code for FIDO2 in homed anyway; optionally allow pam_systemd_homed to authenticate the user with just the FIDO2 token (and not password). This would mean basically duplicating pam-u2f's behaviour into systemd-homed

This would mean not just using the FIDO2 credential for it's hmac-secret but also check the signature it generates using the public key stored in UserRecord

You want to set UV = true on the FIDO2 credential functions; such that the FIDO2 token always prompts for a pin. This is currently not possible in homed as uv = false is hardcoded the osurce code. In pam-u2f this can be configured in the PAM configuration by setting userverification=1. For systemd
I suggest we add an additional field to UserRecord depicting whether we want user verification (that's a pin or biometric) when using the FIDO2 key. It sounds like this is something you want to configure per user; not per host; so it makes sense for me to have this setting live in the UserRecord instead of in /etc/pam.d.

More precisely:

• add a flag --fido2-user-verification to homectl that will set a boolean flag on UserRecord
• Add a field to UserRecord to store the boolean
• homed should honour this flag when making calls to libfido2; e.g. fido2_assert_*

Describe alternatives you've considered
Press (annoyingliy) my yubikey twice during login. Not great; but not terrible.

[arianvp]

Reading the homed docs more precisely. It already seems to implement logging in without password. And I don't need both pam-u2f and homed; except for being able to configure userverification = 1. I will rename the issue.

Is my assumption correct that currently in homed you can unlock a user account without a password by just pressing the yubikey (Without a pin prompt?)

I edited the issue to reflect my request more clearly in that case. Namely to be able to configure homed to always prompt for a pin

[arianvp]

Note to self:

This would require a call to fido_check_flags or fido_assert_verify after fido_get_assert

as some FIDO devices do not prompt for a PIN when uv = true but instead perform a biometric verification, it is not enough to witness a pin prompt to be sure user verification happened.

Instead in both the pin and the biometric case, the authenticator sets the UV = 1 flag in authdata in its response; which we can then check with fido_check_flags to see if it matches our expectation as a caller.

[poettering]

I am a bit confused by this? Wh would you use pam-u2f with pam_systemd_home? The latter does fido2 auth for you anyway, so why have another layer of auth in there? What am I missing?

[arianvp]

You're correct to be confused. See my second message. Originally I thought homed was only concerned with unlocking the LUKS partition, not with authentication, so I stacked pam-u2f on top of homed. Then I realised (as you just noted) that homed also does authentication so it doesn't make sense to have both. I can just use homed.

I edited the original issue later and I crossed out all the sections that refer to pam-u2f and changed the title too later. I am now just using pam_systemd_homed but I want to configure it in a way that it will always prompt for pin. This was possible when I still used pam-u2f, but pam_systemd_homed doesn't have a way to configure this. I probably should've just closed this issue and open a new one; instead of repurposing this one. Sorry for the confusion..

Now the issue is just asking for "always ask for user verification" by setting uv = 1 on when doing credential operations.
So that I can have the same protection level I had with pam-u2f as with pam_systemd_homed. (Namely; that unlocking my machine doesn't just require tapping my yubikey)

[arianvp]

I'd imagine the patch to look something along the lines like this (modulo any additional changes needed to homectl to actually set this field on the user record, and changs to dbus interface to propagate the new error scenario, we should also set uv = true during credential creation so we're sure that the device supports PIN/biometrics. ).

userVerificationRequired would be a public (or priveleged) field on the UserRecord indicating that the user can only be unlocked when a user verification is performed on the authenticator (either a pin prompt on computer, or Biometric gesture on the device)

--- a/src/home/homework-fido2.c
+++ b/src/home/homework-fido2.c
@@ -86,6 +86,11 @@ static int fido2_use_specific_token(
                 return log_error_errno(SYNTHETIC_ERRNO(EIO),
                                        "Failed to add FIDO2 assertion credential ID: %s", fido_strerr(r));
 
+        r = fido_assert_set_uv(a, h->fido2_user_verification_required <= 0 ? FIDO_OPT_FALSE : FIDO_OPT_TRUE);
+        if (r != FIDO_OK)
+                return log_error_errno(SYNTHETIC_ERRNO(EIO),
+                                       "Failed to set FIDO2 assertion user verification: %s", fido_strerr(r));
+
         r = fido_assert_set_up(a, h->fido2_user_presence_permitted <= 0 ? FIDO_OPT_FALSE : FIDO_OPT_TRUE);
         if (r != FIDO_OK)
                 return log_error_errno(SYNTHETIC_ERRNO(EIO),
 
@@ -131,6 +136,10 @@ static int fido2_use_specific_token(
                                        "Failed to ask token for assertion: %s", fido_strerr(r));
         }
+        // TODO: I think we can even leave this check out completely. This is usually only checked on the server
+        // when using FIDO2 in a web context; together with checking the signature that signs the content of authdata
+        // to make sure some man in the middle isn't lying to us about verification actually being performed
+        // However, local communication with CTAP device is cryptographically protected (through ECDH) so we're sure
+        // nobody modified the uv request in transit. So this code is almost certainly reduntant. Could just leave it out
+        // we should be able to trust the CTAP device to perform user verification when uv = 1.   
+        if(a->uv == FIDO_OPT_TRUE && a->stmt[0].authdata.flags & CTAP_AUTHDATA_USER_VERIFIED == 0) {
+          return log_error_errno(SYNTHETIC_ERRNO(EOANO), "We require user verification, but it wasn't performed");
+        }
+
         hmac = fido_assert_hmac_secret_ptr(a, 0);
         if (!hmac)
                 return log_error_errno(SYNTHETIC_ERRNO(EIO), "Failed to retrieve HMAC secret.");
diff --git a/src/shared/user-record.c b/src/shared/user-record.c
index 4149205b8a..3a67d18a3c 100644
--- a/src/shared/user-record.c
+++ b/src/shared/user-record.c
@@ -1529,6 +1529,7 @@ int user_record_load(UserRecord *h, JsonVariant *v, UserRecordLoadFlags load_fla
                 { "pkcs11TokenUri",             JSON_VARIANT_ARRAY,         dispatch_pkcs11_uri_array,            offsetof(UserRecord, pkcs11_token_uri),              0         },
                 { "fido2HmacCredential",        JSON_VARIANT_ARRAY,         dispatch_fido2_hmac_credential_array, 0,                                                   0         },
                 { "recoveryKeyType",            JSON_VARIANT_ARRAY,         json_dispatch_strv,                   offsetof(UserRecord, recovery_key_type),             0         },
+                { "fido2UserVerificationRequired", JSON_VARIANT_BOOLEAN,   json_dispatch_tristate,                offsetof(UserRecord, fido2_user_verification_required), 0      },
 
                 { "secret",                     JSON_VARIANT_OBJECT,        dispatch_secret,                      0,                                                   0         },
                 { "privileged",                 JSON_VARIANT_OBJECT,        dispatch_privileged,                  0,                                                   0         },
diff --git a/src/shared/user-record.h b/src/shared/user-record.h


diff --git a/src/shared/user-record.h b/src/shared/user-record.h
index 357c246ea5..349f09b928 100644
--- a/src/shared/user-record.h
+++ b/src/shared/user-record.h
@@ -339,6 +339,7 @@ typedef struct UserRecord {
         Fido2HmacSalt *fido2_hmac_salt;
         size_t n_fido2_hmac_salt;
         int fido2_user_presence_permitted;
+        int fido2_user_verification_required;
 
         char **recovery_key_type;
         RecoveryKey *recovery_key;

[poettering]

So far we just relied on the tokens default settings for this, and didn't set the bools explicitly under the assumption if people want to tweak that they'd reconfigure the token (that said I am not even sure the usual tokens allow such reconfiguration), and not systemd-homed.

Making this explicitly configurable definitely makes sense (though I am pretty sure we should continue to support a mode were we leave the token's default in tact, and that probably should stay the default in our behaviour too).

Anyway, happy to review/merge a patch adding this....

[poettering]

homed also supports this functionality; However with pam-u2f I can configure that i'm always prompted for a pin (as it sets uv = true when creating and asserting the token). homed currently seems to hardcode uv = false which means I do not get prompted for my pin when unlocking my user account. I don't find this sufficiently secure and would like to configure this.

As already mentioned, we don't hardcode uv = false. We leave it unset, which according to docs means token default is used (i.e. FIDO_OPT_OMIT, see https://developers.yubico.com/libfido2/Manuals/fido_assert_set_uv.html)

[arianvp]

So far we just relied on the tokens default settings for this, and didn't set the bools explicitly under the assumption if people want to tweak that they'd reconfigure the token (that said I am not even sure the usual tokens allow such reconfiguration), and not systemd-homed.

Problem is that FIDO2 / CTAP2 is mostly stateless. This means that most tokens do not support changing defaults eventhough they do support user verification.

(Though CTAP 2.1 will come with a credProtect extension that allows you to change the default on a per-credential basis during creation)

FIDO2 mostly expects the caller to set up expectations explicitly. The token itself doesn't store any state; and everything (the hmac-secret, the keypair, pin verification handshake, and the credential id) is usually derived directly from the parameters and an internal secret stored in the token using a key derivation function. Exception to this are resident credentials; but those are not the default as storage on these tokens is very limited usually.

The default behaviour of leaving uv = OMIT is thus kind of vendor-specific and ill-defined. It corresponds with setting userVerificaiton: preferred in the browser. Because of this confusing behaviour e.g. Chrome will throw an error when you leave uv undefined these days with the following explanation:

https://chromium.googlesource.com/chromium/src/+/master/content/browser/webauth/uv_preferred.md

It's thus recommended to set uv explicitly true from what I understand if you want to have a PIN prompt. I thus think it makes sense to expose this as an option to the user.

openssh recently landed a similar patch: openssh/openssh-portable@9b8ad93

I'll work on a patch for this.

I think we'll just mimmick the browser's behaviour here and implement it as a tri-state.

that is. If the key isn't present in the user record at all; keep the current behaviour and use FIDO_OPT_OMIT. This means we keep full backward compatibility with the current scheme. If the key is present and false, set it to FIDO_OPT_FALSE. If the key is present and true, set it to FIDO_OPT_TRUE

[arianvp]

Turns out my view works from a Webauthn standpoint; but not from a CTAP2 standpoint. It turns out my comment is not valid as PIN is not controlled with the uv parameter but with the clientPin parameter in CTAP ...

I think this makes this entire discussion more confusing than useful. I'll close it for now. But would be nice to get @martelletto 's feedback on how to achieve the desired behaviour

[martelletto]

With 03de19f, it should be a matter of passing a PIN to fido_dev_get_assert() and calling fido_assert_verify() on a fido_assert_t where UV has been set to true. Calling fido_assert_verify() typically involves creating a separate fido_assert_t with the expected authentication parameters (user verification and user presence settings), and populating it with the data signed by the authenticator. An example can be found here. To do this, we would need to store the credential's public key somewhere.