Skip to content

MS_FIDO2

Jump to bottom
nishi_74322014 edited this page Aug 4, 2026 · 1 revision

FIDO2

概要

経緯

  • 2015 年 11 月 19 日、WWW 技術の標準化団体である W3C に
    FIDO 2.0 の Web API 仕様を提案した。

  • FIDO 2.0 は、FIDO 1.0の拡張ではなく、

    • UAF と U2F を統合（補完し置換する）し、
      OS やブラウザといったプラットフォームのサポートに最適化する、
      プラットフォーム（ブラウザや OS）によるネイティブサポートのための仕様。
    • OS やブラウザの API が定義され、FIDO Client といった
      中継のためのレイヤが無くなったため、
      依拠当事者（Relying Party）から直接リクエストができる、
      見かけ上 U2F に近いシンプルな構成になった。

ざっくり

  • パスワードや OTP に代わる新しい認証
  • 秘密鍵で署名（＝登録）をして、公開鍵で検証（＝認証）

秘密鍵で署名（＝登録）

  • 依拠当事者（Relying Party）から認証器の登録を要求する。
  • 署名のための秘密鍵は認証器内で生成される。
  • 依拠当事者から生成された情報に署名を行う
    （rpId: RP の識別子、userId / name: ユーザ情報、challenge: 乱数）。
  • 公開鍵と署名を依拠当事者に登録する。

公開鍵で検証（＝認証）

  • 本人確認、否認防止の目的がある。

補足（用語）: 仕様上の呼称は次のとおり。混同しやすい。

局面 仕様上の語 WebAuthn の API
登録 Attestation navigator.credentials.create()
認証 Assertion navigator.credentials.get()

Attestation は「この認証器はどういう製品か」を証明するもので、 認証（Assertion）とは目的が違う。

2つの仕様

以下の 2 つの仕様から成る。

Webプラットフォーム API仕様（WebAuthn）

Web Authentication API（MS_WebAuthenticationAPI.md）

  • Web API（抽象的な API を通じたメッセージの通信）仕様

    • ブラウザでの普及を想定し、標準化団体 W3C へ本仕様を提案
    • 秘密鍵を使用して認証器のコンテキストに関する情報に署名。

  • 以下の 3 つの仕様から成る。

    • Web API for accessing FIDO 2.0 credentials
    • Key Attestation Format
    • Signature Format

デバイス間連携仕様（CTAP: Client To Authenticator Protocol）

シータップ。

  • PC、スマホなどのデバイス組込みではない認証器に対応するための
    通信プロトコルの規定。

  • EAP: External Authenticator Protocol
    USB / Bluetooth / NFC トランスポートバインディングを規定

    • プラットフォームと外部認証器間の通信プロトコルを規定。
    • 具体的な通信路（USB / Bluetooth / NFC など）の適用が可能。

  • CTAP1、CTAP2

    • CTAP1 : FIDO1 U2F のスペック
    • CTAP2 : FIDO2 のスペック

補足: CTAP2 のメッセージは CBOR でエンコードされる。 CBOR が「標準仕様の中で使われる」典型例である。 署名は COSE（MS_COSE.md）の形式を取る。

デバイス

U2Fセキュリティ・キーの使用

U2F セキュリティ・キーを使用している場合、

  • FIDO2 は後方互換性を提供する（ただし、認証器の実装に依る）。
  • UAF の機能を実行できるが、プロトコルは異なる。
  • Web Authentication API（別名 WebAuthn）でも使用できる。

platform or cross-platform 認証器

認証器 = Authenticator

種別 内容
platform Authenticator OS 組み込み機能（Windows Hello + Microsoft Passport（MS_WindowsHello.md））
cross-platform Authenticator セキュリティ・キー

登場人物のまとめ

ユーザ

  • ユーザ同意 — ユーザが求めている内容に同意すること
  • ユーザ・ハンドル
    • 依拠当事者（Relying Party）によって識別されるユーザ ID
    • 64 バイトの最大サイズを持つ不透明バイトシーケンス
    • 信用証明書の数を制御するために依拠当事者によって使用される
      （ユーザ・ハンドル + RP ID で信用証明書が一意に決まる）

補足（重要）: ユーザ・ハンドルに メール アドレスやユーザ名などの個人情報を入れてはならない。 認証器（特にセキュリティ キー）に保存され、 PIN を知らない第三者にも列挙されうるためである。 ランダムな不透明値を使い、 表示用の名前は displayName に入れる。

依拠当事者（Relying Party）

  • アーキテクチャによる違い

    • 認証器を Platform API 経由で使用する Client アプリケーション
    • 認証器を Web Authentication API 経由で使用する Web アプリケーション

  • Client or Server

    • RP Client
      指紋認証 USB デバイス、虹彩認証対応スマホなどの認証器から、
      登録（Attestation）、認証（Assertion）の結果を、標準化された API で受け取る。
    • RP Server
      • 登録（Attestation）、認証（Assertion）の結果を、RP Client から受け取る。
      • IdP/STS に実装して、クレームベース認証 を
        使用して Web アプリケーションと認証連携してもイイ。

補足: RP ID はオリジンではなくドメインである （例: example.com）。 ここで登録した鍵は、 そのドメインとサブドメインからしか使えない。 RP ID の設計を誤ると、 後からドメイン構成を変えたときに全ユーザの再登録が必要になるため、 最初に慎重に決めること。

なお、この「RP ID に鍵が縛られる」性質こそが、 FIDO のフィッシング耐性の実体である。

認証器（Authenticator）

  • Platform API 経由で利用する認証器
  • Web Authentication API 経由で利用する認証器

FIDO認証器も参照。

実装上の要点

補足: RP Server 側の検証で必須の項目を挙げておく。 JWT と同様、署名検証だけでは足りない。

項目 確認内容
challenge 自分が発行した値と一致するか（リプレイ防止）
origin 期待するオリジンか（フィッシング防止の要）
rpIdHash RP ID の SHA-256 と一致するか
type webauthn.create / webauthn.get が適切か
フラグ UP（ユーザ存在）/ UV（ユーザ検証）が要件を満たすか
signCount 増加しているか（クローン検知。同期パスキーでは 0 固定）

.NET では Fido2NetLib（Fido2.AspNet）が代表的な実装である。 自前で CBOR / COSE をパースするのは避けること。

補足（最新化）: FIDO2 の資格情報を複数デバイスで同期する パスキーが主流になったことで、実装の前提が一部変わった。

  • signCount は同期パスキーでは増えない（0 のまま）ため、 これを根拠にクローンを弾く実装は誤検知する
  • Attestation はプライバシー上の理由で none を返すプラットフォームが多く、 デバイスの機種を検証する運用は成立しにくい
  • 一方で Conditional UI（フォームに候補を出す）により、 ユーザ体験は大きく改善した

詳細は FIDO の補足を参照。

参考

Tags: IT国際標準, 認証基盤, セキュリティ

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally