先日、YubiOn FIDO Logonに企業向け認証器管理機能が実装されました。この機能を簡単に説明すると、セキュリティキーのシリアル番号を使って認証器の管理が出来る機能です。この機能を実現するために、FIDO2の「EnterpriseAttestation」と呼ばれる仕様を利用しています。ただ、こちらの仕様はFIDO仕様として制定されているものの、あまり一般的なものではないため、ブログなどでも踏み込んだ解説などは見かけないように思います。拙筆ながら、私の方でわかっている情報をまとめておこうかと思います。
なお、今回の記事は、主に技術者向けの内容となっております。FIDO Logonの機能について知りたい場合は前回のブログ記事を見ていただいた方が良いかと思います。こちらの記事ではFIDO Logonとは（あまり）関係なく、EnterpriseAttestationという仕様についての解説をしていきます。極力FIDO認証技術を知らない方でも読めるようにしているつもりですが、FIDO認証技術や電子署名技術をご存知の方がより理解が深まるかと思います。
■EnterpriseAttestation仕様策定の背景
FIDO認証の基本的な仕様として、複数のクレデンシャル（認証情報）で利用された認証器が同一個体なのかどうかを判別する事は出来ません。例えば、サイトAとサイトBで同じセキュリティキーを用いた場合、あるいはサイトA内でアカウントXとアカウントYに同じセキュリティキーを用いた場合など、これらのクレデンシャルが同一個体の認証器のものかどうかはクレデンシャルの内容を全て照らし合わせたとしてもわからない仕組みになっています。(*1) これは主にプライバシーの観点から「追跡」を避けるための仕組みです。安易にこれらの同一性がわかってしまうと、例えば利用者がサイトAでのみ開示したはずの情報が、同じ会社が運営するサイトBでも都合よく使われてしまうといった問題が発生する可能性があります。
このような問題に配慮した結果、FIDO認証に利用したデバイスの個体識別情報は認証を行うサービス側（Relying Party、RP）にもわからなくなっています。この仕組みは、個人利用の場面ではプライバシー保護という観点でとても良いものだと思います。一方で、認証を管理したい企業が利用する場合では、都合が悪い点も存在します。以下のような場面があった場合、これまでのFIDO認証では対応する事が出来ませんでした。
社員Xが認証器を紛失したので貸与していた認証器を利用できないようにしたい。なので、社員Xに貸与した認証器のクレデンシャルを特定したい。
システムAしか利用権限がないはずの社員XがこっそりシステムBも使っているらしい、という内部通報があった。システムBで利用されているクレデンシャルの中で、社員Xに貸与している認証器のクレデンシャルがどれか特定したい。
社員Xが、会社から貸与した認証器以外の個人所有認証器を使っていたらしい。社員Xは先日退社し、貸与していた認証器は返却していたが、社員Xが個人所有している認証器を使って社内システムにアクセスできてしまう。社内システムに対しては個人所有の認証器を使えないように（≒会社貸与の認証器しか使えないように）したい。
もちろん、「社員Xのアカウントをきちんと管理して止めればいい」という考え方もあります。私も理想的にはアカウントはきちんと人単位で管理されるべきだと思いますが、現実的には、例えば共用アカウントで認証器を使っていたり、業務の都合で別の社員のアカウントに認証器を登録していたり、社内SEの皆さんが頭を抱えている実運用も存在するかと思います。(*2) そういった悪い運用をしていないか管理者が確認する、という観点でも、企業管理下では「クレデンシャルに対応する実デバイスはどれか」がわかる事がメリットになりえます。
(*1)同一「種類」の認証器かどうか（例えばどのベンダーの何という製品か）はクレデンシャル作成時のオプションによっては判別可能です。
(*2)更に現実的な話としては、FIDO認証を用いて共用アカウントを使うよりも、「複数人が共用アカウントのIDとパスワードを知っている」という形が多いかと思いますが…。
■EnterpriseAttestationの概要
一方ではデバイスの個体識別を「出来ない」ようにする要求があり、もう一方ではデバイスの個体識別を「出来る」ようにする要求がある、という相反する要求に対して、FIDOが示した解決策が「EnterpriseAttestation」です。これは、認証器の設定によって、限られた範囲でデバイスの個体識別を可能にするための仕様です。
出来るだけ簡単にEnterpriseAttestationを説明したいと思いますが、その部分だけを切り出して説明してもわかりにくい部分だと思いますので、FIDO認証の全体の流れから説明していきたいと思います。EnterpriseAttestationの説明に必要ない部分は説明を省いておりますので、FIDO認証の全てを紹介しているわけではない点はご了承ください。
・FIDO認証
まず、FIDO認証はざっくりと言うと、makeCredentialと呼ばれる「登録（クレデンシャル作成）」の部分と、getAssertionと呼ばれる「認証」の部分に分かれます。これらの処理は公開鍵暗号を用いた電子署名の技術に基づいており、「秘密鍵」と「公開鍵」と呼ばれる2種類の鍵を用いて処理を行います。セキュリティキー内部に保存された「秘密鍵」で「署名」を行い、認証を行うサーバー側で保存している「公開鍵」で「署名」が正しいかどうかを判別する事が出来ます。
EnterpriseAttestationはmakeCredentialの部分に実装されていますので、今回はこちらを重点的に取り扱っていきます。makeCredentialでは、認証器内で秘密鍵と公開鍵のペアを作成し、公開鍵をサーバー側に渡します。また、ペアの作成と同時に、サーバーから渡された「チャレンジ」と呼ばれる文字列(*3)に秘密鍵で署名を行い、署名結果をサーバーに渡します。サーバー側では、署名対象のチャレンジが直前にサーバーから発行されたものである事、署名が正しい事を確認して(*4)、問題が無ければ公開鍵を今後の認証で用いるために保存しておきます。
これがFIDO認証の基本的な概念です。getAssertionの場合も大きな流れは変わらず、「秘密鍵と公開鍵のペアを作成」する部分を飛ばして、登録時に作成された秘密鍵を用いて「チャレンジ」に対して署名を行う(*3)、サーバー側ではその署名の確認を行う、という流れになります。(*4)
(*3)正確には、チャレンジを含む各種情報が内包されたJSON（clientData）に対して署名を行います。
(*4)あくまで概念の理解のために最低限の記述にしています。実際には「本当にクレデンシャルを登録・認証しようとしたRPに対して行われた操作か」「登録・認証をしようとした時に本人確認（PIN・指紋など）が行われたか」など、様々な情報の検証が必要です。
・AttestationStatement
実はここまでの説明は本当にFIDO認証の基本的な概念だけで、まだEnterpriseAttestationに繋がる部分の話が出てきていません。EnterpriseAttestationを理解するために、まずは「AttestationStatement」の説明が必要です。
AttestationStatementは、認証器の信頼性を保証する仕組みです。この仕組みを用いると、登録された認証器がFIDOアライアンスの認定した正規の認証器である事を保証する事が可能になります。そうする事で、悪意のある（例えば秘密鍵をあえて漏洩させるような）認証器であったり、悪意は無くとも脆弱性のある認証器などを拒否する事が可能です。
ここからはデータ構造を見ながら説明した方がわかりやすいかと思いますので、まずはmakeCredentialを行った際に取得できるデータの構造を以下に示します。
この中で、attStmtの部分がAttestationStatementと呼ばれる部分で、この中には署名(sig)と証明書(x5c)が含まれています。ここの署名は、authenticatorDataとclientDataHashと呼ばれる項目に対して行われています。わかりやすく言うと、authenticatorDataとclientDataHash（≒チャレンジ）がその認証器によって出力された、という事が、署名と証明書によって確認できます。
ここまでの話ではまだ、「この認証器によってauthenticatorDataとclientDataHashが出力された」事が保証されているだけで、「この認証器がFIDOアライアンス認定された認証器である」という事は保証されていません。それを保証するために、FIDOアライアンスによってMDS（Metadata Service）というサービスが公開されています。このMDSからは、セキュリティキーの各ベンダーが提供している認証器の様々な情報（例えばモデル名など）が取得できるのですが、その中に「attestationRootCertificates」と呼ばれる項目があります。こちらがルート証明書となっており、attStmtから取得できる証明書がattestationRootCertificatesと証明書チェーンを形成している事を確認する事で、その認証器の証明書がベンダーによって生成された＝認証器がベンダーによって提供されたものと保証される事になります。
なお、ここでattStmtから取得できるアテステーション証明書は、認証器の個体ごとに異なるものではなく、複数の認証器個体で同一のものになっています。実際にどういう単位で同じアテステーション証明書を用いているかはセキュリティキーベンダーの実装によるかと思いますが、製品のモデル単位であったり、ファームウェアバージョン単位であったりするのではないかと思われます。私自身の例で言うと、私物のYubiKey Bioと、同時期に会社から支給されたYubiKey Bioではアテステーション証明書が同一の物でした。
・EnterpriseAttestation
EnterpriseAttestationは、前項で説明したアテステーション証明書の部分にほんの少しだけ工夫をしたものになります。前項の最後で、アテステーション証明書は複数の認証器で同一である、という旨の説明をしましたが、EnterpriseAttestationの場合は、この部分が認証器ごとに異なる証明書になっており、登録に使われた認証器がどの個体であるかがわかる仕組みになっています。
実際のWebAuthnの仕様書では、EnterpriseAttestationを要求した際の挙動が以下のように記述されています。
This value indicates that the Relying Party wants to receive an attestation statement that may include uniquely identifying information.
この値は、依頼当事者（Relying Party、RP）が、一意に識別される情報を含む可能性のある証明書を受け取りたい事を示しています。
「一意に識別される情報」としか書かれていませんので、実装としては一意に識別できれば何でもいいのではないかと思われますが、現実的にはシリアル番号などが取得できる場合が多いのではないかと思います。実際に我々が今回の開発に際してYubico様から頂いたEnterpriseAttestation対応YubiKeyでは、x509証明書のsubject項目に、識別名（DistinguishedName、DN）の形式でシリアル番号が格納されていました。
この辺り、証明書の中でどのようにシリアル番号などが設定されるかはベンダーによって異なるのではないかと思います。FIDO Logonでは現状はYubico様の認証器でのみ動作を確認しており、subject項目をDNとして分解したうえで、CN(commonName)項目を正規表現でパースして認証器IDを取得していますが、別のベンダーの場合はまた別のパース方法を準備する必要があると考えています。
・WEB上でのEnterpriseAttestationの実装
WEB上で実際にEnterpriseAttestationを用いる場合、WebAuthnのnavigator.credentials.createメソッドのパラメータ「attestation」に「enterprise」を指定します。要求が正しく処理された場合、先ほどの項で述べた通り、attStmtの証明書としてEnterpriseAttestationの証明書が設定されたattestationObjectが返却されます。(*5)
(*5)細かい事を言えばメソッドの戻り値はPublicKeyCredentialで、その中のresponseメンバがAuthenticatorAttestationResponseで、その中にattestationObjectが設定されています。
■その他補足事項
EnterpriseAttestationを用いる際に必要な事などについていくつか記載していきます。
・EnterpriseAttestation対応セキュリティキーの入手
我々はFIDO Logonの企業向け認証器管理機能開発にあたってYubico様とやり取りを行い、開発用のYubiKeyを用意して頂きましたが、実際に企業で運用する際には（Yubico様に限らず）ベンダーとの連携が必要となります。この辺りはCTAP2の仕様に以下の記載があります。
An enterprise attestation is an attestation that may include uniquely identifying information. This is intended for controlled deployments within an enterprise where the organization wishes to tie registrations to specific authenticators.
EnterpriseAttestationは一意の識別情報を含むAttestationです。これは、組織が登録を特定の認証器と関連付けることを望む、企業内の管理された配備を意図しています。
The expectation is that enterprises will work directly with their authenticator vendor(s) in order to source their enterprise attestation capable authenticators.
企業は、EnterpriseAttestationが可能な認証器を調達するために、認証器ベンダーと 直接協力することが期待されます。
FIDOアライアンスの意図としては、あくまでEnterpriseAttestationが有効な認証器は導入する企業で管理されるべきで、導入する企業は認証器ベンダーと協力すべきである、という認識なのではないかと思います。少なくともEnterpriseAttestation対応の認証器は一般に流通させるようなものではない、という認識です。まだそういった話を認証器ベンダーの方と直接話したわけではないのですが、ここで説明したようなソフトウェア技術についての話に限らず、実際の認証器の運用体制（認証器の入手プロセス、紛失した際の連絡体制など）についても相談して決めていくことになると思われます。仕様策定の背景でも述べた通り、FIDOの仕様としては認証器の追跡は出来ない、というのが基本スタンスですので、この辺りはセキュリティキーベンダー側も慎重に対応していく事になるのではないでしょうか。
・EnterpriseAttestationが利用できるRPの範囲について
EnterpriseAttestationに対応した認証器を入手したとしても、無制限にどのRPに対しても一意の識別情報を提供するわけではありません。どのRPに対して一意の識別情報を提供するかを定めておく必要があるのですが、その方法が2種類あります。
Vendor-facilitated enterprise attestation
「認証器ベンダーによるEnterpriseAttestation」の意味です。具体的には、利用可能なRPのIDを認証器に書き込んだ状態で認証器を出荷する形式となります。先ほどの項で、認証器ベンダーと協力する、という話をしましたが、その際に利用するRPの情報も共有し、認証器の提供時点でどのRPを用いるかを確定させておく必要があります。
Platform-managed enterprise attestation
「プラットフォーム管理のEnterpriseAttestation」の意味です。こちらは認証器にRPのIDを書き込むのではなく、プラットフォーム（例えばブラウザ）などの設定として利用可能なRPのIDを指定しておく方法です。2025年2月13日現在では、（私が確認している範囲では）Google Chromeのみがこの方法に対応しています。(*6)
Vendor-facilitatedの場合は認証器に利用可能なRP IDを設定し、Platform-managedの場合はブラウザに利用可能なRP IDを設定する形になります。
なお、CTAPを自前で実装しているYubiOn FIDO Logonについては、現時点ではRP IDはfl.yubion.comに固定ですので、Platform-managedの形式を取っています。今後のお客様の方針次第ではVendor-facilitatedの形も選べるように（＝認証器側にfl.yubion.comのRP IDが設定されていなければ登録不可）しようかと考えています。
(*6)ChromeブラウザのEnterpriseAttestation設定（ chrome://flags/#web-authentication-permit-enterprise-attestation )の項目で、テキストボックス内にRP IDを指定します。複数指定する場合はカンマ区切りで指定します。
・ブラウザ・OSの対応状況（主にWindows上での話）
EnterpriseAttestationが利用可能な環境についても、あまりまとまった情報がWEB上には無いように思います。我々の方で把握できている情報をまとめておきますが、Windowsに偏った情報である事はご了承ください。
OSの制約
Windows10系統は不可、Windows11系統のみ可(*7)
これはWindows10系統でOSに実装されているWebAuthnAPI(*8)のバージョンが古く、EnterpriseAttestationに対応していないためです。Windowsの場合、ブラウザでのセキュリティキーの利用は全てWindowsのWebAuthnAPI呼び出しで実装されているため、どのブラウザを使ってもこの制約が適用されます。なお、WindowsServerの場合、2022以前のものがWindows10系統となり、WindowsServer2025のみWindows11系統となります。
リモートデスクトップ時のWebAuthnリダイレクトを用いる場合、EnterpriseAttestationを利用するには接続元・接続先共にWindows11系統である必要があります。
ブラウザの制約
Google Chromeの場合
Google Chromeの場合は、ブラウザによる制約は特にありません。ただし、ブラウザの設定で、EnterpriseAttestation設定（ chrome://flags/#web-authentication-permit-enterprise-attestation )を有効化しておく必要があります。また、Platform-managed enterprise attestationを用いる場合は利用可能なRP IDも設定しておく必要があります。
Edgeの場合
Edgeの場合、Chromeと違ってEnterpriseAttestation設定がブラウザ設定内に見当たりません。ただ、ブラウザ上でのWebAuthenticationAPI呼び出し時に「attestation」に「enterprise」を指定した場合、WindowsのWebAuthnAPIが出力する提供情報ダイアログに明確に「シリアル番号」が追加される事から、おそらくVendor-facilitated enterprise attestationには対応しているものと思われます。（弊社で入手している認証器はRP IDの設定をしていないため、確認までは取れておりません）
FireFoxの場合
FireFoxでは2025年2月時点でEnterpriseAttestationは利用できません。
その他
Macの場合、ChromeについてはWindowsと同様に設定をする事で利用可能です。Safariについては17系統のものだとattestation=enterpriseが解釈できなかった（attestation=noneと同様の挙動）のに対して、18.3だと（RP IDの設定をしていないEnterpriseAttestation対応キーで）attestation=directと同等の動きをしたため、Vendor-facilitated enterprise attestationには対応している可能性はありそうです。ただ、リリースノートなどには記述が見つからないため正確なところは不明です。
(*7)YubiOn FIDO Logonのアプリケーション上（設定ツール・ログオン画面）からの認証器登録は、CTAP通信を自前で実装しているため、Windows10系統でもEnterpriseAttestationが利用可能です。ただし、リモートデスクトップ接続からの認証器登録の場合はWindowsのWebAuthnAPIを利用しているため、接続元・接続先共にWindows11系統である必要があります。
(*8)WEB上のWebAuthenticationAPIと名前が紛らわしいのですが、Windows上のWin32APIの事です。
■まとめ
長々と文章を書いてきましたが、実装技術的な面での要点は以下の通りです。
navigator.credentials.createメソッド呼び出し時の「attestation」パラメータに「enterprise」を指定する。
上記呼び出しを行った結果、対応した認証器であればAttestationStatementの証明書がデバイス個別の証明書になる。
証明書チェーンなどの仕組みは通常のAttestationStatementと同様。
ベンダーの実装によるが、証明書内にシリアル番号が保存されている。（Yubico社の場合は証明書のsubject内）
ただ、実装技術よりも運用面の方が色々考えるべき事が多いように思います。
運用方針・体制の検討
導入までの手順をどのように実行していくか。
導入後、どのような業務フローで管理を行っていくか。
認証器を使用するサービス・システムの選択
一般的なサービスについてはEnterpriseAttestation対応のものは多くはないと思われるが、どのようなサービスで認証器を用いるか。
社内開発システムで導入する場合は追加の実装が必要。
EnterpriseAttestationを保存しておくだけであれば簡単な実装となるが、シリアル番号を元にクレデンシャルを管理する機能などを追加する場合は機能の検討が必要と思われる。
Vendor-facilitatedにするか、Platform-managedにするか（あるいは併用するか）。
利用可能環境の確認（OS・ブラウザ）
Chromeの場合はブラウザ設定を一括変更する必要がある。
非対応環境への対処を考える必要がある。
名前が示す通り企業向けの機能で、ここまでの説明でもあった通り「企業内での管理された配備」を前提とした機能ですので、導入しました、で終わるような話ではありません。ですが、きちんと運用・管理体制を構築し、日々その体制を改善していく事が出来る企業様にとっては、運用の助けになる良い機能だと思います。
FIDO Logonでは今回EnterpriseAttestation対応認証器を用いた機能を実装しましたが、もちろん同機能に非対応のセキュリティキーやスマートフォンでも端末のセキュリティを向上させることは可能です。無料版として、有料版と同等の機能を3ヶ月間お試し頂けますので、まずは是非試して頂ければと思います。
EnterpriseAttestation対応認証器の導入をご検討の場合は、お手数ですがお問い合わせいただければ幸いです。
■関連リンク
[YubiOn FIDO Logon]
[YubiOn FIDO Logon概要ページ]