OpenSSH has added support for FIDO/U2F hardware security keys in the latest release, enabling users to add an extra layer of security during the authentication process for sensitive sessions.
Hardware security tokens once were reserved mainly for high-value accounts or operations and were expensive and clunky. But the emergence of open standards such as universal second factor (U2F) and inexpensive hardware keys such as Solo Keys and YubiKeys has made the higher level of security accessible and practical for many more people and services. A wide range of services and websites now support the use of U2F keys for authentication, and adoption of security keys in the enterprise has been accelerating, as well.
In OpenSSH 8.2, users can generate an OpenSSH key that is backed by either a USB or NFC key. The software also supports the use of resident keys, a specific format in which the private portion of the key pair is stored in memory on the hardware token.
“FIDO/U2F OpenSSH keys consist of two parts: a ‘key handle’ part stored in the private key file on disk, and a per-device private key that is unique to each FIDO/U2F token and that cannot be exported from the token hardware. These are combined by the hardware at authentication time to derive the real key that is used to sign authentication challenges,” the OpenSSH release notes say.
“For tokens that are required to move between computers, it can be cumbersome to have to move the private key file first. To avoid this requirement, tokens implementing the newer FIDO2 standard support ‘resident keys’, where it is possible to effectively retrieve the key handle part of the key from the hardware. OpenSSH supports this feature, allowing resident keys to be generated using the ssh-keygen "-O resident" flag. This will produce a public/private key pair as usual, but it will be possible to retrieve the private key part from the token later.”
As a response to the recent publication of a chosen-prefix attack on the SHA-1 hash algorithm, the OpenSSH developers plan to remove support for the algorithm in an upcoming release.
“It is now possible to perform chosen-prefix attacks against the SHA-1 hash algorithm for less than USD$50K. For this reason, we will be disabling the ‘ssh-rsa’ public key signature algorithm that depends on SHA-1 by default in a near-future release,” the release notes say.
“This algorithm is unfortunately still used widely despite the existence of better alternatives, being the only remaining public key signature algorithm specified by the original SSH RFCs. A future release of OpenSSH will enable UpdateHostKeys by default to allow the client to automatically migrate to better algorithms. Users may consider enabling this option manually.”
One of the risks from the SHA-1 attack published in January is an attacker creating a forged but valid signature on a certificate. This could allow the attacker to impersonate a website or service in a way that would look legitimate to a browser.
“The OpenSSH certificate format includes a CA-specified (typically random) nonce value near the start of the certificate that should make exploitation of chosen-prefix collisions in this context challenging, as the attacker does not have full control over the prefix that actually gets signed. Nonetheless, SHA1 is now a demonstrably broken algorithm and further improvements in attacks are highly likely,” the OpenSSH notes say.