FiloSottile / FiloSottile/typage

Supporting FIDO2 credentials without UV

Open
#54 1 comment 0 reactions 0 assignees View on GitHub
Dominant language
TypeScript
Stars
481
Forks
29
Avg merge
9m
Merged PRs (30d)
6

Description

Hello,

I have a suggestion for a feature (that is already mentioned [in the code](https://github.com/FiloSottile/typage/blob/647b5bb0e3981e04eb09f45bac007f586087f298/fido2prf/cmd/age-plugin-fido2prf/main.go#L15)).

It would be nice to support fido2-based encryption without User Verification. Some devices don't support UV and can't be used with the fido2prf plugin right now.

## Proposal 1

We could just allow the user to enter an empty PIN. This is already the behaviour at credential creation time.
Should be simple to implement, but not great ux in my opinion.

## Proposal 2

We could make a getInfo() request and check for the presence of the "clientPIN" option.
Again quite simple to implement, but would not allow much flexibility.

## Proposal 3

The hmac-secret extension selects between one of two secrets (`CredRandomWithoutUV` and `CredRandomWithUV`) based on the status of UV. For this reason, it is important that all operations on a given identity use consistent parameters. We could encode an additional UV flag in the identity string to guarantee this consistency and honour user preferences. This is, for instance, what systemd-cryptsetup does in LUKS headers.

We would have to :
* At identity generation time, make a decision about UV based on user inputs and device capabilities/defaults:
* Take a flag on the command line for selecting between preferred/required/default UV.
* Look at the output of `getInfo()` to detect support for client PIN (and builtin-UV?).
* Encode the decision of using UV or not in the identity string.
* At encryption/decryption time, apply the policy encoded in the identity:
* If no UV desired, don't ask for PIN and set the UV option to false to discourage builtin-UV.
* If UV is desired, ask for a PIN code (or not, if the token uses builtin-UV?).
* Bonus: don't ask for user PIN for `makeCredential()` if not required.

## Bottom word

Supporting FIDO2 tokens without clientPIN would not require much changes, but a more complete implementation could be achieved by just adding one bit of data to the identity strings.

I have done a few experiments on my side and have already some working code, would be happy to open a PR.

Thanks for your work!

Contributor guide

Open the contributing guide

Research direction

Start with fido2prf/cmd/age-plugin-fido2prf/main.go, especially the referenced credential and UV handling. Trace identity generation plus encryption and decryption flows, then decide how the proposed UV policy and identity encoding should remain consistent. Done means supported tokens without clientPIN can perform the intended operations without breaking existing identities.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
cryptography, security
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.