Lines Matching +full:hardware +full:- +full:protected
4 ----------
6 U2F is an open standard for two-factor authentication hardware, widely
9 cheapest way for users to achieve hardware-backed credential storage.
21 given key is backed by hardware. Finally the signature format includes
23 concurrent use of a private key, should it be extracted from hardware.
26 which takes an application ID - a URL-like string, typically "ssh:"
30 the hardware-backed private key, some flags and signed attestation
32 particular hardware instance.
34 It is common for U2F hardware to derive private keys from the key handle
35 in conjunction with a small per-device secret that is unique to the
36 hardware, thus requiring little on-device storage for an effectively
39 primarily use ECDSA signatures in the NIST-P256 field, though the FIDO2
42 Use of U2F security keys does not automatically imply multi-factor
44 single factor of authentication, even if protected by a PIN or biometric
45 authentication. To enable multi-factor authentication in ssh, please
50 -------------------
54 sk-ecdsa-sha2-nistp256@openssh.com
55 sk-ecdsa-sha2-nistp256-cert-v01@openssh.com
56 sk-ssh-ed25519@openssh.com
57 sk-ssh-ed25519-cert-v01@openssh.com
59 While each uses ecdsa-sha256-nistp256 as the underlying signature primitive,
62 the existing ecdsa-sha2-nistp* key types.
64 The format of a sk-ecdsa-sha2-nistp256@openssh.com public key is:
66 string "sk-ecdsa-sha2-nistp256@openssh.com"
69 string application (user-specified, but typically "ssh:")
73 string "sk-ecdsa-sha2-nistp256@openssh.com"
76 string application (user-specified, but typically "ssh:")
81 The format of a sk-ssh-ed25519@openssh.com public key is:
83 string "sk-ssh-ed25519@openssh.com"
85 string application (user-specified, but typically "ssh:")
89 string "sk-ssh-ed25519@openssh.com"
91 string application (user-specified, but typically "ssh:")
99 string "sk-ecdsa-sha2-nistp256-cert-v01@openssh.com"
118 string "sk-ssh-ed25519-cert-v01@openssh.com"
136 string type (e.g. "sk-ssh-ed25519-cert-v01@openssh.com")
143 During key generation, the hardware also returns attestation information
145 hardware-backed. Unfortunately, the protocol required for this proof is
146 not privacy-preserving and may be used to identify U2F tokens with at
151 Attestation information is useful for out-of-band key and certificate
153 by trusted hardware before it will issue a certificate. To support this
157 string "ssh-sk-attest-v01"
167 string "ssh-sk-attest-v00"
177 ------------------
193 The signature returned from U2F hardware takes the following format:
199 For use in the SSH protocol, we wish to avoid server-side parsing of ASN.1
200 format data in the pre-authentication attack surface. Therefore, the
204 string "sk-ecdsa-sha2-nistp256@openssh.com"
217 string "sk-ssh-ed25519@openssh.com"
223 -------------------
229 "webauthn-sk-ecdsa-sha2-nistp256@openssh.com" signature algorithm.
231 The wire encoding for a webauthn-sk-ecdsa-sha2-nistp256@openssh.com
232 signature is similar to the sk-ecdsa-sha2-nistp256@openssh.com format:
234 string "webauthn-sk-ecdsa-sha2-nistp256@openssh.com"
243 the JSON-like structure signed by the browser and "extensions" are any
246 [1] https://www.w3.org/TR/webauthn-2/
248 ssh-agent protocol extensions
249 -----------------------------
251 ssh-agent requires a protocol extension to support U2F keys. At
252 present the closest analogue to Security Keys in ssh-agent are PKCS#11
255 to add PKCS#11 keys to ssh-agent does not include any way to send the
264 string sk-provider@openssh.com
267 This constraint-based approach does not present any compatibility
271 -------------------
276 regress testing. For this reason, OpenSSH shall support a dynamically-
281 numbers listed in sk-api.h. Included in the defined numbers is a
285 miscellaneous options may be passed to the middleware as a NULL-
303 overriding OpenSSH's default of using an all-zero username.
306 ssh-pkcs11-helper to provide address-space containment of the
307 middleware from ssh-agent.