FIDO認証の進化とさらなる応用展開 (第3回FIDOアライアンス東京セミナー講演)

こんにちは、Yahoo! JAPAN 研究所の五味です。

プライバシー・セキュリティ分野の研究開発の一環で、次世代認証技術に関する業界団体 FIDO (ファイド) アライアンス に参加し、グローバルな企業の方々と共に技術仕様の策定や技術の応用展開に取り組んでいます。FIDOアライアンスの 第1回東京セミナー に関しては、既に、約2年前のブログ「アイデンティティ管理とその動向」にてご紹介していました。

今回は、12月8日に虎ノ門ヒルズフォーラムでFIDOアライアンスにより開催されました第3回東京セミナーでの私の講演内容に関してご紹介いたします。 タイトルは「FIDO認証の進化とさらなる応用展開」で、FIDOアライアンスが技術仕様を策定してきた成果である「FIDO認証」を振り返りつつ、進化した技術仕様を確認し、ビジネス適用の側面からFIDO認証を活用したソリューションの可能性や展望を説明します。

認証モデル

図1は、リモート認証モデルとローカル認証モデルという2つの認証モデルの違いを示しています。

ここで、リモート認証とは、Webアプリケーションにおけるパスワードを使った認証が典型的ですが、ユーザーが認証サーバーに対してネットワークを通じて認証する場合の認証モデルを意味します。リモート認証モデルでは、ユーザーを認証する際、ユーザーが入力したID (IDentifier、識別子) とパスワードは、ネットワーク上を流れ、サーバーに送付されます。認証サーバーは、典型的には、「識別」(ユーザーの提示するIDから、ユーザーが誰であると主張しているのか知ること) と「検証」(先のIDと紐付けて認証サーバーに事前に登録済みのパスワードと、ユーザーが入力したパスワードが合致するか照合すること)という2つの機能を備えます。

一方、FIDO認証は、ローカル認証モデルを採用しています。すなわち、リモート認証モデルにおける認証の機能(識別と検証)が分離されて、検証機能がユーザーの保有するデバイス側に存在する形態になっています。ユーザーの検証を行うのが認証器 (authenticator)と呼ぶ機能であり、FIDO認証モデルにおいて重要な役割(ロール)を演じます。認証器は、安全な領域に格納されたユーザーに関するクレデンシャル (認証情報) を用います。ここで、クレデンシャルとは、ユーザーの検証に用いられる情報であり、指紋情報などの生体情報や秘密鍵が該当します (従来的にはパスワードも該当します)。この認証モデルにより、ユーザー検証の処理後、検証に成功したか否かという検証結果がネットワークを通じてサーバーに対して送付されることになります。クレデンシャル情報自体をサーバーに預ける必要がなく、また、ネットワークを流れることもないため、情報漏えいなどのセキュリティ上のリスクを低減できるという利点があります。

FIDO認証のコンセプト: 認証の部品化

上記ローカル認証モデルと同様に、FIDO認証の基本的な概念が「認証の部品化」です (図2)。これは、様々な認証器をまさに部品のように組み込むことによって認証システムを構築できるということを意味します。認証器には、認証手段や方式によらず、すなわち、生体認証でも所有物による認証であってもよく、ユーザー検証の結果がFIDO標準に準拠したメッセージを構成し、サーバーに送付されればFIDO認証を実装できることになります。

FIDO仕様 には、ユーザーの認証処理の体験に応じて、UAF (Universal Authentication Framework: パスワードなしに生体認証などを実施) 仕様とU2F (Universal 2nd Factor: パスワード認証の後、第2認証として所有物認証を実施)があります(昨年の弊社近藤のブログ「次世代認証プロトコルFIDOの動向」参照) が、いずれの仕様でも、また、後述の「Web認証」仕様においても、首尾一貫とした共通の認証モデルになっています。

なお、今回のセミナーに合わせて、FIDOアライアンスは、上記2つの仕様に関して、機能拡張したバージョン1.1版を公開したことをプレスリリースしました。

Web認証とCTAP

Web認証

Web認証とは、Webに関する標準化団体 W3C の Web Authentication Working Groupにおいて策定中のWeb用の認証技術仕様です。元々は、FIDO仕様の次期版(FIDO 2.0)として検討され、W3Cに提案されたドラフト仕様がベースになっています。この技術の概要は昨年2015年の 第2回東京セミナー の私の講演 「FIDO技術のさらなる広がり」 においても発表していましたし、そのドラフト版はW3Cから既に公開されており閲覧できます。今回、近々リリースできるにまでに至ったということで、その内容を説明していました (図3)。

図3は、Web認証において規定している「範囲限定のクレデンシャル (scoped credential)」 に関して図示しています。前述のとおり、従来のクレデンシャルとは、パスワードなどの認証に用いるための情報でしたが、W3Cにて策定されるWeb認証においては、FIDO認証モデルやコンセプトを踏襲し、クレデンシャルとしてのユーザーの秘密鍵が認証器に格納され、それに対応するユーザーの公開鍵がサーバーに格納されています。公開鍵はサーバーで管理するユーザーのIDと紐付けられて管理されています。この秘密鍵と公開鍵のペアは暗号学的に関連付けられたものですので、所定のユーザーに関して、認証器とサーバーの間だけに有効な静的なリンクが確立されていることになります。認証器は、ユーザー検証が成功した際にのみ、登録されたユーザーの秘密鍵にアクセスできるように管理します。すなわち、ユーザー検証が成功した場合にだけ、ユーザーと認証器の間のリンクが動的に確立することになります。以上の管理方法で、ユーザーを検証すると、ユーザーと認証器とサーバー間に、トラスト(信頼)関係が成立し、FIDO認証が実現します。そのため、ユーザー本人以外のユーザーに秘密鍵がアクセスされたり、所定のサーバー以外のサーバーと紐付けられたりすることはないというわけです。

上記のクレデンシャル(秘密鍵)を用いたトラスト関係の構築という点においては、従来のUAFとU2F仕様でもほぼ同様ですが、Web認証仕様は、改めてより汎用的に暗号学的なクレデンシャルを規定したことと、WebブラウザーからFIDO認証を実施できるように抽象的なAPI (図4) を規定したことが顕著な違いです。

Web認証APIは、認証器に格納されるクレデンシャルを作成することによって認証器を登録する処理(makeCredential())と、格納されたクレデンシャルにアクセスすることによって認証器を用いた認証をするための処理(getAssertion())を、ブラウザーのJavaScriptから呼び出して実施するためのインターフェースになっています。

Web認証処理と手順

図5は、Web認証APIを通じた認証器の登録処理を示しています。この処理は、次の図6で示す「認証器を用いたWeb認証」を実現するための前処理という位置づけです。図5に描かれている認証用の秘密鍵と公開鍵は、本登録処理の開始時には存在しませんが、ブラウザーのJavaScriptからクレデンシャル生成のための要求が投げられ (ステップ1)、ユーザー検証処理が成功 (ステップ2) した後、ステップ3にてユーザー用の秘密鍵と公開鍵のセットが生成され、それぞれ、認証器とサーバーに格納されます。

図5の認証器の登録処理が完了した状態、すなわち、ユーザーの認証器に該当する秘密鍵と公開鍵がそれぞれ認証器とサーバーに管理されている状態にて、図6のWeb認証処理を開始します。

手順は図5の登録処理とほぼ同様ですが、ブラウザーのJavaScriptを通じたクレデンシャルへのアクセス要求(ステップ1)を契機にして、ユーザー検証が成功すれば(ステップ2)、ユーザーの登録済みの認証用秘密鍵を用いて、ステップ1のアクセス要求に含まれるチャレンジ(サーバーが生成したランダムな文字列)に署名を付与し(ステップ3)、署名を含む検証結果の証明書(アサーション)データをサーバーに返信します(ステップ4)。サーバーは、受け取った署名を関連付けられて保管されている認証用公開鍵を用いて検証し(ステップ5)、問題がなければユーザーのIDが得られる(ステップ6)ことで、Web認証が完了します。

CTAP

上述のとおり、Web認証APIは、ブラウザーから多様な認証器を利用するための共通のインターフェースですが、スマートフォンなどのデバイスに内蔵された認証器や、USBキーなどの着脱する形式の認証器に加え、ユーザーのデバイスと物理的にも異なる外部の認証器、例えば、スマートフォンやスマートウォッチなどをサポートします。これを支えるのがCTAP (Client-To-Authenticator Protocol)であり、その名のとおり、クライアントと認証器の間のアプリケーションレベルでの通信によってWeb認証を実現するためのプロトコル(通信規約)です。CTAPは、Web認証仕様とは異なり、FIDOアライアンス独自で仕様策定が進められており、ドラフト版が公開されています。

CTAPにより、図2で示した認証器部品群の新たなラインナップとして、スマートフォンやスマートウォッチなどのデバイスが、1つの認証器として追加されたということになります(図7)。

これで、ユーザーは、自分のあらゆるデバイスで動作するアプリケーションの実行時に必要となる認証処理を、日頃使い慣れたスマートフォンに集約して認証できるようになります。すなわち、「スマホ認証器」により、認証に関するスケーラビリティ(拡張性)はさらに向上するであろうと考えられます。

「スマホ認証器」の出現に伴う、様々な認証器の形態とWeb認証APIとの関係を図8にて整理しました。

認証器は、ユーザーのデバイスに製品出荷時からハードウェア的にも備え付けられている内蔵認証器と、ユーザーデバイスとは物理的に分離している外部認証器とに大別できます。外部認証器は、さらに、USBキーなどユーザーデバイスに挿入するなどして利用する「着脱型」と、物理的に分離した状態のままでBluetoothやNFCなどの方式で通信することで利用する「無線型」に分けられます。この整理において、CTAPは、外部認証器における着脱型と無線型の双方に共通の通信プロトコルとなります(図8右側の2つの赤い矢印に該当)。

FIDO認証を用いた応用ソリューション

認証器の応用展開

1つ目は、認証器の応用展開です(図9)。既に図2と図7で示したとおり、認 証器には様々なバリエーションが考えられ、部品のようにシステムに組み込 んで利用してもらえる環境が整ってきています。ですから、既に認証技術を 保有する企業や研究機関の皆様は、その技術を実装した認証器を開発し、 FIDO® Certified (認定)を取得すると、世界中でより多くのユーザー様に使っていただくことができるのではないかと考えます。

なお、既存の(レガシーな)技術を認証器に実装し導入したという点において良い事例として、同セミナーにおける韓国のKICA (Korean Information Certification Authority) Dr. JJ. Kim氏の講演内容のユースケースを挙げました。韓国では電子政府サービスが普及しており、公的なPKIベースの証明書を利用する必要性があるそうです。そこで、その現状をふまえ、それらの証明書をベースにした認証を実装する認証器を開発したということでした。この際、FIDO認証のプロトコルを拡張するのみで改変することはなく実装していることもポイントです。このようなアプローチは、他の様々な場合でも適用できるのではないかと思われます。

FIDO認証とID連携

2つ目は、ID連携(Identity Federation)です (図10)。ID連携では、認証サーバー (Identity Provider, IdP: アイデンティティプロバイダー) で認証した後に、その認証結果である認証アサーションを発行して、(ユーザーの確認の下で) 連携するサービスプロバイダーに共有します。第1回東京セミナーの私の講演「FIDO技術の適用による安心・安全なサービスの実現」でもふれていましたが、FIDO認証とID連携は機能的には異なりますので、互いに補完するものとなっています。

FIDO認証によってシンプルで堅牢な認証が実現すると、その認証コンテキスト(どのような認証手段や強度で認証したかという情報)は、ID連携によって引き継がれ、連携するサービスプロバイダーに共有されます。これにより、ユーザーに対してシームレスで安全なサービスを提供できます。

FIDO認証は、厳密に言うと、ユーザーの検証を行ったというだけでなく、ユーザーが認証器のそばにいることや、ユーザーのコンテキスト(状況)・アイデンティティ(本人性)・取引(トランザクション)などの何らかに関して確認(合意)したということを証明する機構を備えていると言えます。この機構を利用すれば、実装した認証器の開発・応用と、その認証器で生成されたユーザーの証明情報を組み合わせて、インターネット規模でトラストなアプリケーションを提供することができると考えられます。このような観点から、今後、FIDO認証とID連携を組み合わせたシステム構築やソリューション展開が期待できます。

なお、ID連携に関して、Yahoo! JAPANは、「Yahoo! ID連携」を積極的に進めており、弊社倉林がブログ「Yahoo! JAPANのOpenID Certified Markの取得について」を公開していますので、合わせてご参照ください。

最後は、「オフラインでの本人確認」です (図11)。

オフラインでの本人確認

「オフライン」とは、ネットワークにデバイスが接続されている状態が「オンライン」であるのに対し、必ずしもネットワークに接続しない現実世界のことを指します。今まで述べていたFIDO認証や、上記2つのユースケースは、基本的にオンラインでの世界が想定されていました。それに対して、ユーザーのコンテキストをリアルタイムで取得し、その取得したデータを証明することができるというFIDO認証の機構に沿えば、FIDO認証をオフラインで利用するユースケースも十分にありえるはずという可能性を示してみました。

図11では、電子チケットのユースケースを示しています。一般に、オンラインにおいて認証し、チケットを購入したといっても、オフラインの現実世界では、「なりすまし」たユーザーが、チケットを購入した正規のユーザーの代わりに存在する可能性があります。このような場合の防止策として、イベントでの入場ゲートにおいて、チケット情報と共に、生体認証を用いたFIDO認証を行ったということを提示できれば、確かに正規のチケット購入者であるという本人確認が実装できるであろうと考えています。

まとめ

今回は、FIDOアライアンスの第3回東京セミナーにおける講演内容をご説明いたしました。 FIDO認証モデルは、部品化した認証器を用いたローカル認証を採用し、仕様を通して首尾一貫としていること、Web認証とCTAPでは、範囲限定の暗号学的クレデンシャルを規定し、ブラウザーを通じ多様な形態の認証器をサポートするWeb認証APIを提供すること、FIDO認証を用いたソリューションでは、認証器の応用展開、ID連携システムの拡張、オンラインに加えオフラインでもFIDO認証の応用が期待できること、などをご説明いたしました。

ちなみに、今回のセミナー開催と記者説明会のタイミングで、FIDOアライアンス内で公式にJAPAN WG (Working Group, 作業部会)が発足し、国内から参加するメンバーのコミュニケーションの相互支援や日本語による情報発信を進めていくというプレスリリースを発表しました。Yahoo! JAPANとしても、積極的に参加していきたいと考えております。ご興味のある方はぜひご参加いただけると幸いです。

関連記事

• 「安全・安心・便利」FIDO（ファイド）を使った パスワードレスログインとは
  （2019年2月20日　Yahoo! JAPANコーポレートブログ）