FIDO 技术说明：详细了解 FIDO U2F v1.2

31 8 月, 2017

尤里·阿克曼（Yuriy Ackermann），高级 FIDO联盟认证工程师

FIDO 联盟很高兴地宣布发布 FIDO U2F 1.2 版规范。

自前两个版本以来，进行了结构性更改、改进、更新和新的安全功能。下面，我们详细介绍一下这些变化。有关更改的摘要版本，请转到“FIDO U2F v1.2：更改概述”。

JS 接口

接口 u2f {

无效寄存器（

DOMString
appId
，

序列<RegisterRequest>
register请求
，

序列<RegisteredKey>
registeredKeys
，

function（RegisterResponse 或 Error）
回调
，

可选无符号长？ opt_timeoutSeconds

);

无效符号（

DOMString
appId
，

DOMString 挑战，

序列<RegisteredKey>
registeredKeys
，

function（SignResponse 或 Error）
回调
，

可选无符号长？ opt_timeoutSeconds

);

};

高级 JS API 已更新。以前，您必须单独设置，每个”RegisterRequest“和”SignRequest”“ appId 和质询。在 JS API v1.2 中，appld 作为第一个参数传递 u2f.register。

/* —– U2Fv1.0 —– */

let appId = “
https://example.com
”;

let registerRequests = […];

let signRequests = […];

for （let regReq of registerRequests） {

regReq.appId = appId;

}

for （let signReq of signRequests） {

signReq.appId = appId;

}

u2f.register（registerRequests， signRequests，（） => {

…

})

/* —– U2Fv1.2—– */

let appId = “
https://example.com
”;

let registerRequests = […];

let signRequests = […];

u2f.register（appId， registerRequests， signRequests，（） => {

…

})

重新定义 v1.2 的另一种方式是身份验证请求字典。以前的字典类型为 ”SignRequest“已替换为”RegisteredKey“字典。

/* —– U2Fv1.0 —– */

dictionary SignRequest { // OLD

DOMString 版本;

DOMString 挑战;

DOMString keyHandle;

DOMString appId;

};

/* —– U2Fv1.2 —– */

dictionary RegisteredKey { // 新建

DOMString 版本;

DOMString keyHandle;

运输？运输;

DOM发送？ appId;

};

通过此更改，质询已从字典中删除，现在是 u2f.sign 命令的第二个参数，第一个参数是 appId，与 u2f.register 命令相同。

/* —– U2Fv1.0 —– */

let appId = “
https://example.com
”;

let signRequests = […];

for （let regReq of registerRequests） {

regReq.appId = appId;

}

u2f.sign（signRequests，（） => {

…

})

/* —– U2Fv1.2 —– */

let appId = “
https://example.com
”;

let challenge = “YJjw3jBh6RiMPKY0lMWq8GXm0Qap”;

let registeredKeys = […];

u2f.sign（appId， challenge， registeredKeys，（） => {

…

})

为了向后兼容，客户端仍可以处理 SignRequest。 这同样适用于 RP，RP 可以继续处理 SignResponse。

另一个附加功能是“传输“数组。 RP 可以向客户端指示哪个传输特定密钥句柄使用。它通过使用传输枚举：

枚举传输 {

“bt”， // 经典蓝牙（蓝牙 BR/EDR）

“ble”， // 低功耗蓝牙（Bluetooth Smart）

“NFC”， // 近场通信

“usb”， // USB HID

“usb-internal” // 不可拆卸的 USB HID（内置）

};

这对于 UI/UX 特别有用，在 UI/UX 中，客户端可以引用指示的传输指定的提示。

我们将在“身份验证器传输扩展”部分讨论传输检测。

MessagePort API 获得了自己的请求定义字典 IDL。

字典 U2fRequest {

DOMString 类型;

DOM发送？ appId;

未签名的长？ timeoutSeconds;

未签名的长？ requestId;

};

这扩展到“U2fRegisterRequest”和“U2fSignRequest”

字典 U2fRegisterRequest ：
U2fRequest
{

DOMString 类型 = ‘u2f_register_request’;

序列<RegisterRequest> registerRequests;

序列<RegisteredKey> registeredKeys;

};

字典 U2fSignRequest ：

U2fRequest

{

DOMString

类型
= ‘u2f_sign_request’;

DOMString 挑战;

序列<
注册密钥

>

registeredKeys
;

};

正如你所看到的，U2F JS API 发生的变化也相应地发生在 MessagePort API 上。

/* —– U2Fv1.0 —– */

var port = <以浏览器特定的方式>获取 U2F MessagePort;

port.addEventListener（’消息’， responseHandler）;

port.postMessage（{

‘type’： ‘u2f_register_request’，

‘registerRequests’： [<RegisterRequest 实例>， …]，

‘signRequests’： [<已知令牌 1> 的 SignRequest， …]，

‘timeoutSeconds’：30，

‘requestId’： <unique integer> // 可选

});

/* —– U2Fv1.2 —– */

var port = <以浏览器特定的方式>获取 U2F MessagePort;

port.addEventListener（’消息’， responseHandler）;

port.postMessage（{

‘type’： ‘u2f_register_request’，

“appId”： <应用程序 ID>、

‘registerRequests’： [<RegisterRequest 实例>， …]，

‘registeredKeys’： [<已知令牌 1> 的 registeredKey， …]，

‘timeoutSeconds’：30，

‘requestId’： <unique integer> // 可选

});]

身份验证器传输扩展

在注册期间，身份验证器使用批处理密钥对质询进行签名，并为其公钥提供 X.509 证书。供应商现在可以添加 X.509 FIDO OID 和 U2F 证书扩展，用于标识这是 U2F 身份验证器证书：

— FIDO联盟的OID

id-fido 对象标识符：：= 1.3.6.1.4.1.45724

— FIDO U2F 协议 OID

id-fido-u2f 对象标识符：：= { id-fido 2 }

— FIDO U2F 证书扩展弧

id-fido-u2f-ce 对象标识符：：= { id-fido-u2f 1 }

为了标识身份验证器的类型，该规范定义了 U2F 传输扩展

— FIDO U2F 证书扩展

id-fido-u2f-ce-transports 对象标识符：：= { id-fido-u2f-ce 1 }

fidoU2FTransports 扩展：：= {

WITH 语法 FIDOU2FTransports ID id-fido-u2f-ce-transports

}

FIDOU2FTransports ：：= 位字符串 {

蓝牙收音机（0）,– 蓝牙经典

蓝牙低功耗收音机（1），

uSB（2），

nFC（3），

uSB内部（4）

}

原始消息格式

此更新最重要的功能之一是添加了静默身份验证器支持。有了这个功能， 应用程序协议数据单元 （APDU）收到新的签名参数 don’t-enforce-user-presence-and-sign（0x08） . 现在，客户端可以在不强制执行用户状态的情况下请求签名。这对于将静默模式用于“持有者令牌”（如身份验证模式）的基于 FIDO 的联合解决方案特别有用。基于 FIDO 的解决方案的主要优势是泄漏恢复能力。由于 FIDO 协议基于数字签名，并且私钥通常存储在安全飞地中，因此联合身份可以将身份验证器用作不可恢复的持有者令牌，因此不必担心客户端的 XSS 和恶意软件。