FIDO2-CRED(1)

πŸ’– FIDO2-CRED πŸ’–

okay bestie, listen UP, because this one is a whole manual page β€” it's from the General Commands Manual, it's called fido2-cred, and it is literally the main character of FIDO2 credentials. πŸŽ€


✨ NAME ✨

fido2-cred β€” make/verify a FIDO2 credential


🌸 SYNOPSIS 🌸

fido2-cred -M [-bdhqruvw] [-t option] [-a mode] [-c cred_protect]
           [-i input_file] [-o output_file] device [type]
fido2-cred -V [-dhv] [-c cred_protect] [-i input_file] [-o output_file]
           [type]

πŸ¦‹ DESCRIPTION πŸ¦‹

So, fido2-cred makes or verifies a FIDO2 credential. That's the whole vibe. πŸ’…

A credential type can be one of these four, and no, they're not interchangeable, they're each their own little icon:

  • es256 β€” denoting ECDSA over NIST P-256 with SHA-256
  • es384 β€” denoting ECDSA over NIST P-384 with SHA-384
  • rs256 β€” denoting 2048-bit RSA with PKCS#1.5 padding and SHA-256
  • eddsa β€” denoting EDDSA over Curve25519 with SHA-512

If type is not specified, es256 is assumed. defaults, she's serving 🫢

When making a credential, the authenticator may require the user to authenticate with a PIN. If the -q option is not specified, fido2-cred will prompt the user for the PIN. If a tty is available, fido2-cred will use it to obtain the PIN. Otherwise, stdin is used.

The input of fido2-cred is defined by the parameters of the credential to be made/verified. Peep the β€œINPUT FORMAT” section for the deets. πŸ‘€

The output of fido2-cred is defined by the result of the selected operation. That's the β€œOUTPUT FORMAT” section, go look. ✨

If a credential is successfully created or verified, fido2-cred exits 0. Otherwise, fido2-cred exits 1. that's it, that's the whole pass/fail system, no cap 😭

The options are as follows:


πŸ’… OPTIONS πŸ’…

  • -M β€” Tells fido2-cred to make a new credential on device. ✨
  • -V β€” Tells fido2-cred to verify a credential. πŸ”
  • -b β€” Request the credential's β€œlargeBlobKey”, a 32-byte symmetric key associated with the generated credential.
  • -a mode β€” When making a credential, request enterprise attestation. Please refer to <fido/param.h> for the set of possible values. (yes bestie, go read the header, I'm not making stuff up 🫢)
  • -c cred_protect β€” If making a credential, set the credential's protection level to cred_protect, where cred_protect is the credential's protection level in decimal notation. Please refer to <fido/param.h> for the set of possible values. If verifying a credential, check whether the credential's protection level was signed by the authenticator as cred_protect. πŸ”
  • -d β€” Causes fido2-cred to emit debugging output on stderr. messy but informative πŸ’€
  • -h β€” If making a credential, enable the FIDO2 hmac-secret extension. If verifying a credential, check whether the extension data bit was signed by the authenticator. πŸ“
  • -i input_file β€” Tells fido2-cred to read the parameters of the credential from input_file instead of stdin.
  • -o output_file β€” Tells fido2-cred to write output on output_file instead of stdout.
  • -q β€” Tells fido2-cred to be quiet. If a PIN is required and -q is specified, fido2-cred will fail. 🀫 no PIN prompt for you, it just gives up
  • -r β€” Create a resident credential. Resident credentials are called β€œdiscoverable credentials” in CTAP 2.1. (name drop! πŸ‘‘)
  • -t option β€” Toggles a key/value option, where option is a string of the form β€œkey=value”. The options supported at present are:
    • uv=true|false β€” Asks the authenticator for user verification to be enabled or disabled.
    • pin=true|false β€” Tells fido2-cred whether to prompt for a PIN and request user verification.

The -t option may be specified multiple times. stack 'em πŸ’…

  • -u β€” Create a U2F credential. By default, fido2-cred will use FIDO2 if supported by the authenticator, and fallback to U2F otherwise.
  • -v β€” If making a credential, request user verification. If verifying a credential, check whether the user verification bit was signed by the authenticator.
  • -w β€” Tells fido2-cred that the first line of input when making a credential shall be interpreted as unhashed client data. This is required by Windows Hello, which calculates the client data hash internally. (windows hello doing its own little thing, iconic honestly 🌈)

🧚 INPUT FORMAT 🧚

The input of fido2-cred consists of base64 blobs and UTF-8 strings separated by newline characters ('\n').

When making a credential, fido2-cred expects its input to consist of:

  1. client data hash (base64 blob);
  2. relying party id (UTF-8 string);
  3. user name (UTF-8 string);
  4. user id (base64 blob).

When verifying a credential, fido2-cred expects its input to consist of:

  1. client data hash (base64 blob);
  2. relying party id (UTF-8 string);
  3. credential format (UTF-8 string);
  4. CBOR encoded authenticator data (base64 blob);
  5. credential id (base64 blob);
  6. attestation signature (base64 blob);
  7. attestation certificate (optional, base64 blob).
⚠️ UTF-8 strings passed to fido2-cred must not contain embedded newline or NUL characters. fr fr, it will not vibe with those.

🌈 OUTPUT FORMAT 🌈

The output of fido2-cred consists of base64 blobs, UTF-8 strings, and PEM-encoded public keys separated by newline characters ('\n').

Upon the successful generation of a credential, fido2-cred outputs:

  1. client data hash (base64 blob);
  2. relying party id (UTF-8 string);
  3. credential format (UTF-8 string);
  4. CBOR encoded authenticator data (base64 blob);
  5. credential id (base64 blob);
  6. attestation signature (base64 blob);
  7. attestation certificate, if present (base64 blob).
  8. the credential's associated 32-byte symmetric key (β€œlargeBlobKey”), if present (base64 blob).

Upon the successful verification of a credential, fido2-cred outputs:

  1. credential id (base64 blob);
  2. PEM-encoded credential key. πŸ”‘

πŸ”₯ EXAMPLES πŸ”₯

Create a new es256 credential on /dev/hidraw5, verify it, and save the id and the public key of the credential in cred:

$ echo credential challenge | openssl sha256 -binary | base64 > cred_param
$ echo relying party >> cred_param
$ echo user name >> cred_param
$ dd if=/dev/urandom bs=1 count=32 | base64 >> cred_param
$ fido2-cred -M -i cred_param /dev/hidraw5 | fido2-cred -V -o cred

like, look at her. making a credential and verifying it in one pipe. ate. πŸ’…βœ¨


πŸ‘‘ SEE ALSO πŸ‘‘

fido2-assert(1), fido2-token(1)


πŸ’€ CAVEATS πŸ’€

Please note that fido2-cred handles Basic Attestation and Self Attestation transparently. In the case of Basic Attestation, the validity of the authenticator's attestation certificate is not verified.

🚨 bestie that's a real one β€” it's transparent about it, but it does not check that certificate's validity. know that going in.

okay that's the whole page, you're so welcome 🫢 this was Debian, dated December 8, 2025 β€” go make some credentials, you got this, mwah πŸ’–

πŸ“¦ where this page comes from