FIDOテクニカルノート:FIDO U2F v1.2の詳細

8月 31, 2017

ユーリー・アッカーマン・シニア FIDOアライアンス認定エンジニア

FIDOアライアンスは、FIDO U2Fバージョン1.2仕様のリリースを発表します。

過去 2 つのバージョン以降、構造の変更、改善、更新、および新しいセキュリティ機能が行われました。以下では、これらの変更点について詳しく説明します。変更の概要については、「FIDO U2F v1.2: 変更の概要」を参照してください。

JSのAPI

インターフェイス u2f {

ボイドレジスタ(

DOMString
appId
、

順序<RegisterRequest>
registerRequests
、

順序<RegisteredKey>
registeredKeys
、

function(RegisterResponseまたはError)
コールバック
、

オプションのunsigned long? opt_timeoutSeconds

);

ボイド記号 (

DOMString
appId
、

DOMストリング
チャレンジ
、

順序<RegisteredKey>
registeredKeys
、

function(SignResponseまたはError)
コールバック
、

オプションのunsigned long? opt_timeoutSeconds

);

};

高レベルの JS API が更新されました。以前は、個別に設定する必要がありました。RegisterRequest」と「SignRequest」” appId と challenge. JS API v1.2 では、appld が u2f.registerです。

/* U2Fv1.0 ———- */

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

let registerRequests = […];

let signRequests = […];

for(registerRequestsのregReqをしましょう){

regReq.appId = appId;

}

for(signRequestsのsignReqをlet 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 が再定義されたもう 1 つの方法は、認証要求辞書です。タイプ ” の以前の辞書SignRequest」は「RegisteredKey」辞書に置き換えられました。

/* U2Fv1.0 ———- */

dictionary SignRequest { // 古い

DOMString バージョン。

DOMString チャレンジ;

DOMString keyHandleです。

DOMString appIdです。

};

/* U2Fv1.2 ———- */

dictionary RegisteredKey { // 新規

DOMString バージョン。

DOMString keyHandleです。

トランスポート。トランスポート;

DOMString? appIdです。

};

この変更により、チャレンジは辞書から削除され、u2f.sign コマンドの 2 番目の引数になりました 1 つ目は appId で、u2f.register コマンドと同じです。

/* U2Fv1.0 ———- */

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

let signRequests = […];

for(registerRequestsのregReqをしましょう){

regReq.appId = appId;

}

u2f.sign(signRequests、() => {

…

})

/* U2Fv1.2 ———- */

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

チャレンジ=”YJjw3jBh6RiMPKY0lMWq8GXm0Qap”;しましょう

let registeredKeys = […];

u2f.sign(appId、チャレンジ、registeredKeys、() => {

…

})

下位互換性のために、クライアントは引き続き SignRequest を処理できます。同じことが RP にも当てはまり、RP は SignResponse の処理を続行できます。

もう一つの追加機能は「トランスポート” 配列です。 RP は、特定のキーハンドルを使用するトランスポートをクライアントに示すことができます。これは、 トランスポート 列挙:

列挙型トランスポート{

“bt”, // Bluetooth クラシック (Bluetooth BR/EDR)

“ble”, // Bluetooth Low Energy (Bluetooth スマート)

“nfc”, // 近距離無線通信

“usb”, // USB HID

“usb-internal” // 取り外し不可能な USB HID (内蔵)

};

これは、指定されたトランスポートによって指定されたプロンプトをクライアントが参照できる UI/UX に特に役立ちます。

トランスポート検出については、「Authenticator Transport Extension」セクションで説明します。

MessagePort API は、独自の要求定義ディクショナリ IDL を取得しました。

辞書 U2fRequest {

DOMString 型。

DOMString? appIdです。

符号なし長い? timeoutSecondsです。

符号なし長い? requestIdです。

};

これは “U2fRegisterRequest” と “U2fSignRequest“ に拡張されます

辞書 U2fRegisterRequest :
U2fRequest
{

DOMString 型 = ‘u2f_register_request’;

順序<RegisterRequest> registerRequestsです。

順序<RegisteredKey> registeredKeysです。

};

辞書U2fSignRequest:U2fRequest

{

DOMString

型
= ‘u2f_sign_request’;

DOMString

チャレンジ
;

順序<
RegisteredKey (登録キー)

>

registeredKeys
です。

};

ご覧のとおり、U2F JS API に発生する変更は、MessagePort API にも対応して行われます。

/* U2Fv1.0 ———- */

var port = <ブラウザ固有の方法で> U2F MessagePort を取得します。

port.addEventListener(‘message’, responseHandler);

port.postMessage({

‘タイプ’: ‘u2f_register_request’、

‘registerRequests’: [<RegisterRequest インスタンス>, …],

‘signRequests’: [<既知のトークン 1> の SignRequest …],

‘timeoutSeconds’:30、

‘requestId’: <unique integer> // オプション

});

/* U2Fv1.2 ———- */

var port = <ブラウザ固有の方法で> U2F MessagePort を取得します。

port.addEventListener(‘message’, responseHandler);

port.postMessage({

‘タイプ’: ‘u2f_register_request’、

‘appId’: <アプリケーションID>、

‘registerRequests’: [<RegisterRequest インスタンス>, …],

‘registeredKeys’: [<既知のトークン 1> の RegisteredKey, …],

‘timeoutSeconds’:30、

‘requestId’: <unique integer> // オプション

});]

オーセンティケータートランスポート拡張機能

登録時に、オーセンティケータはバッチキーを使用してチャレンジに署名し、X.509証明書を使用して公開キーを提供します。ベンダーは X.509 を追加できるようになりましたこれがU2Fオーセンティケーター証明書であることを識別するFIDO OIDと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 Transport Extensionが定義されています

— FIDO U2F証明書の拡張

id-fido-u2f-ce-transports オブジェクト識別子 :: = { id-fido-u2f-ce 1 }

fidoU2FTransports拡張機能:: = {

構文付き FIDOU2FTransports ID id-fido-u2f-ce-transports

}

FIDOU2FTransports :: = ビット文字列 {

ブルートゥースラジオ(0),– Bluetoothクラシック

bluetoothLowEnergyRadio(1)、

uSB(2)、

nFC(3)、

uSBインターナショナル(4)

}

未加工のメッセージ形式

このアップデートの最も重要な機能の1つは、サイレント・オーセンティケーターのサポートが追加されていることです。この機能により、 アプリケーションプロトコルデータユニット (APDU) が新しい署名パラメータを受け取りました dont-enforce-user-presence-and-sign(0x08) . これで、クライアントはユーザープレゼンスを強制せずに署名を要求できます。これは、認証モードのような「ベアラートークン」にサイレントモードを使用するFIDOベースのフェデレーションソリューションに特に役立ちます。 FIDOベースのソリューションの主な利点は、漏れに対する耐性です。 FIDOプロトコルはデジタル署名に基づいており、秘密鍵は通常、安全なエンクレーブに格納されるため、フェデレーションIDは認証器を回復不能なベアラートークンとして使用できるため、クライアント側でXSSやマルウェアについて心配する必要はありません。