Yubico 宣佈推出 Lightning 的 U2F 界面...

YubicoCES 2019 上宣佈推出兩用版的 YubiKey,同時支援 USB-CLightning 接頭:「Yubico Launches the Security Key NFC and a Private Preview of the YubiKey for Lightning at CES 2019」。


目前是 Private Preview,開發者需要跟 Yubico 申請:

If you are a developer or service that would like to support strong hardware authentication on iOS, we invite you to work with us by applying to participate in the YubiKey for Lightning Program. Selected participants will have access to the private preview of YubiKey for Lightning and also the Yubico Mobile iOS SDK for Lightning.

不過看起來是硬體限制沒辦法朝 NFC 支援?另外如果蘋果下一代 iPhone 換掉變成 USB-C 就搞笑了...

便宜的 HSM


一個是 Yubico 推出的 YubiHSM 2:「YubiHSM 2 is here: Providing root of trust for servers and computing devices」。

另外一個是 Mozilla 在 2013 年提到的 CryptoStick,不過現在連過去看到的是 Nitrokey HSM:「Using CryptoStick as an HSM」。

兩個都是走 USB 1.1 Type A,運算效能都普普通通,感覺自己用比較合適?像是 GnuPG 加解密。拿給線上服務用的效能還是要夠好...

U2F Security Key 產品測試?

Adam Langley 的「Testing Security Keys」這篇測試了不少有支援 U2F Security Key 的產品,這邊作者是以 Linux 環境測試。

tl;dr:在 Linux 環境下,除了 Yubico 的產品沒問題外,其他的都有問題... (只是差在問題多與少而已)

Yubico 的沒找到問題:

Easy one first: I can find no flaws in Yubico's U2F Security Key.

VASCO SecureClick 的則是 vendor ID 與 product ID 會跑掉:

If you're using Linux and you configure udev to grant access to the vendor ID & product ID of the token as it appears normally, nothing will work because the vendor ID and product ID are different when it's active. The Chrome extension will get very confused about this.

Feitian ePass 的 ASN.1 DER 編碼是錯的:

ASN.1 DER is designed to be a “distinguished” encoding, i.e. there should be a unique serialisation for a given value and all other representations are invalid. As such, numbers are supposed to be encoded minimally, with no leading zeros (unless necessary to make a number positive). Feitian doesn't get that right with this security key: numbers that start with 9 leading zero bits have an invalid zero byte at the beginning. Presumably, numbers starting with 17 zero bits have two invalid zero bytes at the beginning and so on, but I wasn't able to press the button enough times to get such an example. Thus something like one in 256 signatures produced by this security key are invalid.

Thetis 根本沒照 spec 走,然後也有相同的 ASN.1 DER 編碼問題:

With this device, I can't test things like key handle mutability and whether the appID is being checked because of some odd behaviour. The response to the first Check is invalid, according to the spec: it returns status 0x9000 (“NO_ERROR”), when it should be 0x6985 or 0x6a80. After that, it starts rejecting all key handles (even valid ones) with 0x6a80 until it's unplugged and reinserted.

This device has the same non-minimal signature encoding issue as the Feitian ePass. Also, if you click too fast, this security key gets upset and rejects a few requests with status 0x6ffe.

U2F Zero 直接 crash 沒辦法測 XDDD:

A 1KiB ping message crashes this device (i.e. it stops responding to USB messages and needs to be unplugged and reinserted). Testing a corrupted key handle also crashes it and thus I wasn't able to run many tests.

KEY-ID (網站連 HTTPS 都沒上...) / HyperFIDO 也有編碼問題但更嚴重:

The Key-ID (and HyperFIDO devices, which have the same firmware, I think) have the same non-minimal encoding issue as the Feitian ePass, but also have a second ASN.1 flaw. In ASN.1 DER, if the most-significant bit of a number is set, that number is negative. If it's not supposed to be negative, then a zero pad byte is needed. I think what happened here is that, when testing the most-significant bit, the security key checks whether the first byte is > 0x80, but it should be checking whether it's >= 0x80. The upshot is the sometimes it produces signatures that contain negative numbers and are thus invalid.

所以還是乖乖用 GitHub 帳號買 Yubico 吧...