次世代認証プロトコルFIDOの動向

はじめに

こんにちは、近藤裕介と申します。

みなさま、Yahoo! JAPANにログインしてサービス利用していますでしょうか？

Yahoo! JAPANに限らずログインが必要なウェブサービスやアプリケーションを利用して、ヘビーユーザーになってくると他人に見られたくないデータが増えたりなりすましされて困るようになりますよね。そうならないための対策としてパスワードを長く難しくしたり、2要素認証を設定したりする必要がありますが利便性が下がってしまいます。

そんなパスワードにまつわる課題を解決する、FIDOアライアンスの策定している認証プロトコルであるU2FとUAFの仕様が昨年12月に正式公開され、2015年にはいくつものサービスで採用されたニュースが話題になりました。

また先月開催されたFIDOセミナー2015においては、OSやブラウザー上への標準サポートに向けた新しいFIDO 2.0の仕様が紹介され、今後ますます動向が気になるプロトコルになってきました。

あらためてFIDOプロトコルであるU2FとUAFの概要について説明したいと思います。

U2FとUAFの概要

※FIDO Allianceより引用

U2Fは従来のパスワード＋ワンタイムパスコードに代表される「記憶認証」＋「所持認証」の組み合わせた2要素認証プロトコルです。
ワンタイムコード方式は端末に保存した共有鍵を利用して同期式で生成した数字を入力する手間があるうえにフィッシングの対する防御ができませんが、U2Fは認証器そのものを所持していることを提示するアクション（認証器上のボタンを押す動作）をとることで認証されるため、フィッシング耐性があってより簡単な体験で利用できるようになっています。 認証器自体もUSBタイプのものが比較的安く手軽に手に入れることができます。

UAFはパスワードレスな仕様で、「所持認証」＋「生体認証など」を利用した認証を提供するプロトコルです。端末上での生体認証などを加えることによって端末紛失時などより強固にデータを守ることができるようになります。iPhoneが普及している昨今では、いくつかのアプリでパスワード入力の代わりにTouchIDによる指紋認証を提供しているので、生体認証に慣れ親しんでいる人が多いと思いますが、そのほとんどはアプリのロック解除に利用していたり事前に入力したパスワード情報を保存しておき認証後に補完入力するような実装になっており、UAFとは根本的に異なるものです。また、端末で認証に使った生体情報がサーバー側へ送信しているような印象をお持ちの方もいるかと思いますが、生体情報は端末内のセキュアな領域に保存されており、通信経路にデータが流れるような仕組みではありません。

U2FとUAFはユーザー体験は大きく異なりますが、両者ともPKI(公開鍵基盤)がベース技術として使われています。FIDOは、端末に搭載されている指紋センサなどの認証器で認証した結果を端末側でつくった秘密鍵を使って署名をし、リモートの認証サーバー上で事前に登録済みの公開鍵で署名を検証することによって実現され、「端末の認証器で認証した結果を、リモートの認証サーバーで受け入れ信頼するプロトコル」といえます。信頼のできる認証器であるかどうかの保証については、仕様の策定しているFIDOアライアンスが第三者として認定をして、正規の認証器であることを検証できるようにするための証明書を提供しています。そのためFIDO認定の認証器の結果を信頼するサーバーやアプリはRelying Party(RP)と呼ばれています。

U2Fの仕様の構成

U2FではRPアプリケーションから利用可能な下記2つのClientのインターフェースを定義されており、実際に一部のブラウザーのJavaScriptAPIとして実装されています。

interface u2f {
    void register (RegisterRequest[] registerRequests, SignRequest[] signRequests, function(RegisterResponse or Error) callback, optional int? opt_timeoutSeconds);
    void sign (SignRequest[] signRequests, function(SignResponse or Error) callback, optional int? opt_timeoutSeconds);
};

　また認証器で生成するデータフォーマットや署名方法などを規定したRaw Message Formatの仕様や、U2F ClientからUSBだけでなくBLE、NFCなどの近接無線プロトコルごとの認証器へのアクセス手段について記載している仕様から構成されています。

登録と認証時にどのようなデータのやりとりをするのかをイメージしやすくするために、シーケンスについてもよろしければ確認ください。

登録時のフロー

認証時のフロー

RP視点でのU2Fの魅力と課題

パスワード認証した上で登録などを行うので、ユーザーIDと認証機で生成した鍵の紐付けが比較的楽であるのと、プロトコルのシーケンスや提供されるAPIが少なく比較的シンプルであるため、RPがU2F対応するための実装やUX変更にかかるコストが少ないのは大きなメリットです。

手軽に手に入るとはいえ認証器の購入がまず必要がある点と、あくまで二要素目の認証の代替的な位置づけであるため、高いセキュリティが要求されるエンタープライズでの利用や比較的リテラシーが高いユーザー向けで、一般ユーザー向けに利用してもらうためには敷居が高いように思います。また、2015年12月現時点ではブラウザーのなかでアドオンなしで標準サポートしているのはPC版Chromeのみで、対応から1年近く経過したにも関わらず他のブラウザーへの実装がされていない状況のためサポート端末も限られてしまっているのが当面の課題です。

UAFの仕様構成

図のように、UAFはU2Fと比べてクライアント端末側のコンポーネントが細かく分かれており複雑になっています。

FIDOServerからのリクエストを受けて、RPアプリケーションがどのようにFIDO Clientとメッセージやりとりを行うか、たとえばAndroidアプリの場合はIntent、iOSアプリの場合はカスタムURIスキームを使うといった仕様がUAF Application API & Transport Binding に記載されています。
また、Clientから認証器へのリクエストを仲介するAPI層のインターフェース仕様がUAF Authenticator Specific Module (ASM)、ASMと認証器とのメッセージのやりとりの仕様がUAF Authenticator Commandにそれぞれ記載されています。具体的には搭載している認証器の情報の参照、鍵ペアの生成と保存、登録済みの鍵の一覧表示、指定した鍵を使って署名データを生成する機能を提供しています。

登録と認証時にどのようなデータのやりとりをするのかをイメージしやすくするために、シーケンスについてもよろしければ確認ください。

登録時のフロー

認証時のフロー

RP視点でのUAFの魅力と課題

UAFの魅力は、RPが許容する認証ポリシーのリクエストを入れられるところだと思います。例えば、端末にマルウエアが感染している状態だとしてもユーザーを守りたい金融機関や決済サービス事業者などのRPがセキュアな認証を求めるケースでは相応の生体認証が可能な認証器が搭載されている端末のみに利用を制限できます。逆にセキュリティよりもパスワードレスなUXであることに重きをおいているRPの場合は、生体認証器がなくてもPINコード入力をするような認証器でも構わないといった例など、さまざまな認証方式に柔軟に対応できるのです。

課題と感じているのはRPが認証のリクエストをする先のFIDO Clientの提供形態が端末によって異なってくる可能性があるという点です。

1. 端末ベンダー製のものが出荷時プリインストールされて提供
2. サード・パーティ製のものを別途アプリストアから単体で動作するインストールする
3. RP組み込み型のもの。FIDO Client機能を組み込んでひとつのRPアプリケーションとして提供。

RPの立場からすると、FIDO Clientを1のように初回から利用できる状況になっていると、UAF対応に乗り出しやすいと考えています

FIDO 2.0

U2FとUAFはそれぞれ異なるベンダーによって策定されてきた関係もあり、ことなるユースケースを想定して策定され、多くのベンダーが製品を実装してきました。その一方で両者とも対応可能なブラウザーや端末が限定的で、より広範なプラットフォームでのサポートが求められていました。

そこで、FIDOプロトコルのブラウザーやOSのネイティブサポートを目標に、現在FIDO2.0の仕様の検討がはじまりました。

FIDO 2.0の仕様構成

FIDO2.0ではFIDO Clientといった中継のためのレイヤーがなくなり、RPアプリケーションから直接リクエストができるOSやブラウザーのネイティブプラットフォームのAPIへのインターフェースが定義され、見かけ上U2Fに近いシンプルな構成になりました。

下記の仕様が定義されています。

• WebAPI for Accessing Credential API
  • RPアプリケーションから利用されるブラウザー/OSのネイティブAPI。U2Fと同様に認証器で鍵を生成する登録するAPIwindow.fido.makeCredentialおよび、登録済みの鍵を使って認証用の署名をつくるAPIwindow.fido.getAssertionを定義しています
• Signature Format
  • 上記のAPIで生成されるクレデンシャルやアサーションの署名データのフォーマットを定義しています
• Key Attestaition Format
  • RPサーバー側でクレデンシャル検証時に必要な、認証器の信頼性を証明するためのデータのフォーマットを定義しています
• External Authentication Protocol
  • U2Fの仕様にもあったNFCやBLEなどを使って端末に組込みではないタイプの認証器に対応できるように、プラットフォーム層と外部認証器の間の通信プロトコルについての取り決めを定義しています

上記のWebAPIやSignatureやAttestationのデータフォーマットに関してはウェブ標準仕様を策定しているW3CへFIDO2.0のWebAPI仕様を今年11月に提出がされており、将来的に全ブラウザー上でサポートされるのではと期待が高まっています。

さいごに

とりとめのない仕様の紹介となりましたが、興味をもってもらえれば幸いです。