パスワードレス認証とは？FIDO2の導入を検討される方へ
FIDO2はなぜ安全で堅牢なのか
この記事の目的
FIDO認証と呼ばれるパスワードレスの認証方式が生まれ、近年かなりの進化を遂げ大きく普及してきています。webサービスやアプリケーション等の認証にFIDOが利活用される未来もそう遠くないでしょう。
この記事では、
- パスワード社会が抱える問題
- FIDO2を導入、支援する各企業の状況
- FIDO2の認証機能のセキュリティ
- FIDO2の導入にあたって、企業が何をするべきなのか
の理解を目的としています。この記事で扱うのはFIDO2です。U2Fやその他のプロトコルに関しても簡単に説明を加えますが、自分で検索をかけてもらったほうが早いです。
パスワード社会が抱える問題
現在、webサービスにログインする際にはIDとパスワードを打ち込む方法が一般的です。利用するオンラインサービスも増えて、多くのパスワードを管理している人も少なくないはずです。
一般に攻撃を行う人は大抵、自分の情報に関して無頓着な人を標的にします。つまり、パスワードを多くのサイトで使いまわしていたり、明らかに予測が可能なパスワードを利用しているような人です。
(123456のような。驚くべき事ですが、本当にそのようなパスワードを利用している人がいます)
彼らはおおよそ自分の情報が盗まれる事など想定していませんから、自分にとって都合の良いパスワードを利用します。
基本的に、管理の甘い人間が作るパスワードは脆いという現実があります。これはパスワードの抱える最も顕著で重大な問題でしょう。実際にVerisonの2017年度の調査によると、81%ものハッキングが脆弱なパスワードが原因で発生しています。
さらに悪いことに、webサイト別に簡単には予測できないパスワードを作成し、パスワード管理ソフトで管理していてもパスワードは漏洩する可能性がある、ということです。
近年のフィッシングやソーシャルエンジニアリングの手法の発達により、いくら強いパスワードを作成しようが、パスワードを入力する必要がある限り、危険性はなくなりません。Anti-Phishing Working Groupによる調査では世界中に最低でも255,065種類ものフィッシング攻撃が存在しています。
もはや、パスワードの存在が個人のアイデンティティを保証する存在として機能しなくなりつつあると言えるのではないでしょうか。フィッシングにより簡単に他者のアカウントとしてログインが可能であるからです。
加えて、個人が厳重にパスワードを保護したとしていても、企業側の管理状態が杜撰であるとパスワードは意味を為しません。最近であれば、フェイスブック社が数億人単位でのパスワード情報を暗号化せずに管理していたとして、社内で自由に閲覧が可能な状態になっていました。また、セブンペイなどのように、パスワード設計がそもそも杜撰な状態であると、多くの重大なインシデントを生みます。
パスワードに関して人間が原因となる問題が多く発生していることを理解いただけたかと思います。であれば、そもそも個人と企業間で、共通の秘密を保持しなければ良いのです。それを実現するのが次に紹介するFIDO2です。
FIDO2による認証とは
FIDO2を説明する前にFIDO Allianceについて簡単に述べておきます。FIDOはFast IDentity Onlineを意味し、従来のパスワードに挙げられるような、共有の秘密に依存しない認証体系を実現しようとする非営利の標準化団体です。2012年にPaypal等の主要な6社によって設立されました。現在ではAmazonやGoogleをはじめとする40社を超えるボードメンバーによって運営されています。
FIDO Allianceはパスワード社会が抱える問題に対する解決策として、
（1）使いやすさ、（2）プライバシーとセキュリティ、（3）標準化
を掲げており、FIDO AllianceはUAF、U2FそしてFIDO2という3つのプロトコルを開発してきました。UAFはFIDOに対応した端末を用いてパスワードレス認証を行う方式、U2Fは従来のパスワード認証に加え、キー等での2段階認証を実現したものです。FIDO2はそれらのプロトコルにより汎用性を持たせたもので、導入への障壁を低く設計しています。
詳細に入りましょう。FIDO2の認証自体は手元にある認証器に対して、主に生体情報(指紋など)を入力する事で、認証を行う方式を採用しています。そして、この認証はWebAuthnとCTAPと呼ばれる2つの要素から成り立っており、従来の、デバイスを限定していたUAFに比べ、認証器を認証の環境がよりシームレスになっているのが大きな特徴です。
WebAuthnとCTAP
FIDO2をFIDO2たらしめる大きな要素となっているWebAuthnとCTAPですが、これは何でしょうか？
WebAuthnは認証というプロセスをwebオンライン上で利用可能にしたものです。UAFでは認証をFIDO対応端末に限定しており、汎用性が高いものではありませんでした。しかし、WebAuthnは既存のブラウザからJavaScriptで認証APIを呼び出すことで、端末に依存しない認証形態を提供することが可能になっています。
CTAPは認証器の安全な通信のためのプロトコルです。BluetoothやNFC、USBなどを介して動作する外部キーを、FIDO2に対応するWebブラウザでセキュアに動作させることが可能です。
FIDO2の対応状況
FIDO2は専用の認証器を必要としない汎用性の高いプロトコルです。ブラウザがFIDO2に対応する事で、普段利用するスマートフォンなどの端末を認証器として利用することができます。
現状として、Chrome Desktop, Firefox, Chrome Android, 最近ではSafariなどはWebAuthnプロトコルに対応しており、ブラウザを経由して認証を行うことが可能です。多くのブラウザがFIDO2準拠のプロトコルに対応したこともあり、多様なデバイスからのアクセスが可能になっています。IBMのリサーチによる現時点での対応状況を示した図は以下です。
*safari等の対応状況も反映し、私の知る限りで図に追加しています。間違いや追加等あればご指摘ください。ソースはリファレンスをご覧ください。
Yubico keyなど外部の認証器もありますが、デバイスそのものをFIDO2の認証器として利用可能な物も存在します。Android端末はその際たる例ですが、スマートフォンに付随の指紋認証機能などを利用して、生体情報を入力することが可能です。端末が一つの認証器となり、様々なwebサービスにアクセスすることができます。また、Windows Helloは内部に認証器の機能を埋め込んだOSとして、FIDO2の機能を利用することができます。
拡張性として、認証器とWebブラウザの接続を可能にするFIDO2は非常に高いものになっていますが、ブラウザを経由しないもの(例えばスマホアプリケーション)などには対応できず、アプリでの認証を可能にするにはアプリ内でブラウザを経由させる必要があるでしょう。
FIDO2がもたらす安全性・堅牢性
FIDO2はなぜ安全なのか、データフローと実際の仕組みに基づいて紹介しましょう。FIDO2を利用する際には"登録"と"認証"という2つの手順を踏むことになります。ここで登場する3つのコンポーネントについて整理をしておくと以下になります。
- 認証器(Authenticator)
作成された認証情報(秘密鍵等)は認証器のセキュアエレメントに格納されます。Windows HelloのようにOSに組み込まれている場合もあれば、NFCやbluetoothなどで通信を行う物理的なデバイスの可能性もあります。 - WebAuthnを提供するブラウザ(API)
FIDO2に対応したChorome, Safari等のブラウザです。JavaScriptにより記述されたアプリケーションを利用してサーバや認証器と通信を行います。 - ログインしたいシステムのサーバ(Relaying Party)
Relaying Party(RP)とも呼ばれ、登録の際に生成したユーザの公開鍵情報を保管し、自身で送信したチャレンジ等の検証を行います。
*本来はFIDO2のサーバ、RPサーバ、データベースと役割ごとに分類するべきですが、説明のため統合します。
WebAuthnでは認証に公開鍵基盤を利用したチャレンジ・レスポンス認証を採用しており、認証器とサーバの間で公開鍵認証を行っています。すなわち、パスワード情報や生体情報などの、秘密にしておくべき情報の受け渡しが発生しません。そういったクレデンシャル情報は認証器のセキュアエレメントに保管しています。
登録と認証は基本的に同じ手順を踏んでおり、サーバからのChallengeコードに対して、認証器が秘密鍵で署名をし、サーバに送り返すというのが大まかな流れです。しかし、登録に当たっては、認証器とサーバがお互いを信用できる状態を確保する必要があります。次項でデータの流れを確認します。
各項目における動作とデータの流れは、MDN Web DocsのWeb Authn APIが非常に簡潔にまとめています。同様にこちらも詳細に分かりやすくまとめていただいているので是非参照してください。流れを掻い摘んで説明します。
登録
図の通り、間にブラウザとアプリケーションを通して通信を行います。まず、ユーザからブラウザを通して登録要求を受けたサーバは、アプリケーションに対して、チャレンジコード、ユーザ情報、RP情報を送信します。リプレイ攻撃を防ぐために、チャレンジコードはサーバ上で生成し、一定時間で破棄するような仕組みが必要です。
これらの情報を検証し、API上で統合したものがClient Data JSONです。その後、ブラウザは認証器を呼び出し、ハッシュ化したClient Data Hashを送信します。
その後認証器はブラウザから送られたデータを検証します。ユーザによる承認後、非対称の対となる鍵を生成し、Attestationを作成します。Attestationとは、ユーザの公開鍵が正当な認証機から作成されていることをサーバで確認するための仕組みです。フォーマット内に、認証機の情報、公開鍵などを含むAttestation Objectをサーバが検証することで成立します。
Attestationは認証器の製造過程において焼き付けられた秘密鍵で署名されているので、サーバは認証局に遡って認証器の正当性を確認することが可能です。
ブラウザはAttestation Responseとしてサーバにデータを返します。サーバは受け取ったAttestationを基にoriginやchallengeを検証して、ユーザの公開鍵を登録します。
以上が登録のプロセスになります。
ただし、認証情報はその認証器にのみ保存されているという不便が存在します。すべてのログインはそのデバイスに紐づくため、デバイスの紛失等に関しての対策をする必要があります。これはどの端末からでもアクセス可能としたパスワード認証と異なる点です。
認証
認証も基本的に登録と同じ手順を踏みます。すでにサーバにユーザの公開鍵は登録してあるので、認証器でサーバ情報とチャレンジコードに対して署名を行い、返す手順になります。
*参考にさせてもらっているこちらには1) 認証ではユーザやRelying Patryの情報を必要としません。とありますが、認証器で署名する際にはRPのorigin等を確認する必要があり、情報を必要とするはずなのですが... どなたかご存知の方がいれば連絡ください。
認証器は登録時に生成した秘密鍵を用いて、clientDataHashとauthenticatorDataに署名を行うことで新しいAssertionを生成します。Assertionのデータの内容はAttestationとほぼ同じで、公開鍵が含まれていない点が異なります。
これらAssertionデータをブラウザに返し、Assertion Responseとしてサーバに送信します。サーバでは登録された公開鍵を用いて署名を検証し、本人の認証を確認します。
以上が認証のプロセスになります。
登録と認証、どちらの場合もデータの関所でサーバのoriginを検証します。これにより、フィッシングの可能性をなくし、安全性・堅牢性を実現しています。
FIDO2の導入にあたって
FIDO2の規格において、企業側が用意する必要があるのは、クライアントデバイス側のアプリケーションと、RPサーバ、FIDO2サーバ等です。データのプロトコルとフォーマットに関しては規定はないので、各企業での安全な実装が求められます。認証器との通信の部分はブラウザやOS側でのAPIが用意されており、実装は不要です。
現在、ほとんどのブラウザでFIDO2の規格に対応していることもあり、参入する環境は整ってきていると言えます。また、YubicoがMobile SDKを実装したり、ますます活用の幅が広がっており、FIDO2の導入の障壁が小さくなりつつあります。これにより、スマホアプリでのFIDO2認証の可能性が出てきました。
FIDO2の導入はユーザビリティを向上させると共に、安全性と堅牢性をユーザにもたらします。その一方で、紛失に対する解決策や、originの異なるサイト等でのデータの扱いに関してなど不便な部分も残されています。
終わりに
今回はFIDO2に関しての解説を行いました。個人的に非常に興味深いトピックで、これからの技術的、ビジネス的な動きが気になっています。
私はパスワードの存在自体に懐疑的な訳ではありませんでしたが、今回のリサーチを行うにつれ、実際のインシデント例を目の当たりにして、危機管理を行うべきだと強く感じました。
同時に、FIDO2などのシステムでこれを解決しようとする動きは非常に良いことで、API等が整備され益々盛り上がりを見せることを期待しています。
また、FIDO2を導入しようとされている方にとって有益な情報になっている事を望んでいます。できるだけ最新情報を取り入れ、リファレンスも充実させているので、何かの参考になると嬉しいです。
