
【技術概要】パスキー/FIDO認証はなぜ安全なのか
先日、「パスワードは不要!?未来のスタンダードと成り得るFIDO認証とは?」というコラムを投稿しました。
本コラムでは「パスキー」と呼ばれる認証の仕組みにも利用されている「FIDO認証」という技術仕様について、なぜパスワードに代わる次世代認証として期待されているのかを、「セキュリティ」と「ユーザビリティ」の観点から技術的にご説明いたします。
※本コラムで扱うFIDO認証はFIDO2(webauthn + CTAP2)を指します。
FIDO認証で使用される技術
FIDO認証では公開鍵暗号方式(補足1)を用いて高セキュリティを実現しています。
公開鍵暗号方式はHTTPS(TLS)など堅牢なプロトコルで採用されており、FIDO認証では電子署名(補足2)としてエンドユーザの正当性を確認するために用いられます。
そのような公開鍵暗号方式がどのように利用されるのか、FIDO登録/認証シーケンスに絡め、この後のセクションでご説明します。
FIDO認証を実現する構成要素
FIDO認証のシーケンスとしては大きく登録シーケンスと認証シーケンスの2種類あります。
それぞれのシーケンスをご説明する前に、FIDO認証を実現する構成要素に関してご説明します。
FIDO認証を実現する構成要素としては以下となります。
名前 | 概要 | 備考 |
---|---|---|
エンドユーザ |
利用サービス・システム(RPサーバ)にログインしたいユーザ |
FIDO認証を利用するためには必ず認証器とブラウザを所持しておく必要がある。 ブラウザではなくFIDO認証に対応しているアプリ/OSでも代替可能。 |
認証器 (Authenticator) |
エンドユーザの本人性検証、秘密鍵/公開鍵の管理、電子署名を行うことができる機器 本機器を利用する際は「ローカル認証」と呼ばれる認証が行われる |
スマートフォン(iPhone、Android)やwindowsOS(windowsHello)、セキュリティキ-(Yubikeyなど)が認証器にあたる。 最新版のスマートフォン、Windows(WindowsHello)は認証器としての機能を有しているため、 既に対象機器を利用しているエンドユーザは特に追加で購入/携帯する必要はない。 |
ブラウザ (クライアント) |
サービスにアクセスする際に利用するアプリケーション |
Edge、Chrome、safari、Firefoxなどのブラウザなどがクライアントにあたる。 各ブラウザはスマートフォン、windows、MacOSにプリインストールされているため、 最新版にアップデートされたブラウザ環境を利用しているエンドユーザは特に追加でインストールする必要はない。 |
サービス・システム (RPサーバ) |
FIDO認証に対応しているサービス・システム |
サービス提供者はFIDO認証が利用できるように、サービス・システムを改修する必要がある。 |
FIDOサーバ |
利用サービス・システムに対してFIDO認証によるログインを試みたエンドユーザを認証するサーバ |
サービス提供者はFIDO認証が利用できるようにFIDOサーバを用意する必要がある |
登録/認証シーケンス
ではFIDO認証の流れを登録/認証シーケンス例をもとにご説明します。
FIDO認証では前述通り、電子署名を利用してエンドユーザの正当性を確認し、認証しています。登録シーケンスでは、エンドユーザは認証器を用いて、電子署名で利用する秘密鍵/公開鍵を生成し、生成した公開鍵をFIDOサーバに登録します。
認証シーケンスでは、エンドユーザは認証器が生成した公開鍵/秘密鍵を用いて認証を行います。
公開鍵/秘密鍵を生成/管理する認証器の使い方や、ネットワーク上に流れるデータをイメージしながら後述するシーケンスをご参照いただくと、FIDO認証が安全かつユーザビリティの高い認証である理由を理解しやすいと思います。
登録シーケンス
まずはFIDO認証で利用する公開鍵を登録するシーケンスです。
FIDO認証の特色となる部分をご説明します。
まずは「⑤チャレンジの発行/保管」です。
チャレンジは「③ログインIDの送付」を行ったが、⑫「認証器の正当性と公開鍵の送付」を行った通信元(クライアント)と同一かをFIDOサーバが判断するために利用されます。
FIDOサーバは「④チャレンジの要求」ごとに推測できない異なる値のチャレンジを発行し、ログインIDと紐づけて管理します。
推測できない異なる値のチャレンジを発行し、さらに一度発行されたチャレンジを再利用出来ないようにすることで、悪意ある攻撃者が途中の通信の盗聴に成功し、同じチャレンジを再利用して不正な公開鍵を送ろうとした場合でも、FIDOサーバはチャレンジの再利用を検知し、送られてきた公開鍵を正当な公開鍵ではないと判断できるようにします。
次は「⑧ローカル認証」です。
この認証は、秘密鍵/公開鍵を管理する認証器によって行われます。認証器は認証器自身の利用権限を対象のエンドユーザが所持しているか確認します。
ローカル認証では、生体情報(指紋、顔など)や(PINコードなど)が利用でき、どちらの情報が利用できるかは認証器や設定に依存します。
ローカル認証で使用される生体情報や知識情報などの秘匿すべき認証情報に関しては、認証器に閉じて利用されるため、アクセス先のサービス/システムを含む外部ネットワークはもちろんのこと、ブラウザにさえ秘匿な認証情報が送られません。
次は「⑩鍵の作成」です。
「⑧ローカル認証」が成功したら、認証器はアクセス対象のサービス/システム用の秘密鍵/公開鍵を作成します。この秘密鍵/公開鍵はブラウザではなく、認証器にて保持されます。
サービス/システム並びにFIDOサーバに送られるのは公開鍵のみであり、秘密鍵はアクセス先のサービス/システムを含む外部ネットワークはもちろんのこと、ブラウザにさえ送られません。
最後に「⑭登録情報確認」です。
FIDOサーバは送られてきた認証器や公開鍵、チャレンジなどの情報からエンドユーザ(認証器)の正当性を判断します。
正当であると判断された場合、FIDOサーバはログインIDと公開鍵を紐づけて管理します。
認証シーケンス
続きまして認証シーケンスです。認証シーケンスでは登録シーケンスで登録した公開鍵と、対となる秘密鍵を用いて認証を行います。
エンドユーザが正当であると判断します。
各項目で用いられている技術詳細は異なりますが、大まかな流れとしては、認証シーケンスと登録シーケンスとほとんど同一です。
異なるポイントとしては、既に登録シーケンスにて公開鍵/秘密鍵が作成済みであるため、エンドユーザは新たに作成する必要がない点と、ブラウザがサービス・システム並びにFIDOサーバに送る情報としてチャレンジへの電子署名が含まれる点となります。
FIDOの登録/認証シーケンスに関して説明しました。
まとめるとFIDO認証は以下の3つの理由のより、セキュリティとユーザビリティの両立を実現していると言えます。
- ローカル認証では生体情報(指紋、顔など)や知識情報(PINコードなど)を利用できるため、長くて難しいパスワードを覚えて運用する必要がない。
- ローカル認証で使用する生体情報(指紋、顔など)や知識情報(PINコードなど)の秘匿情報、公開鍵暗号方式で使用する秘密鍵はブラウザにさえ渡らないため、ネットワーク上に流出しない。FIDOサーバもそれらの秘匿情報を管理する必要がない。
- ネットワーク上に流れる情報はログインIDやチャレンジ、公開鍵などの情報など、たとえ第三者に傍受されたとしても、それだけでは不正アクセスやなりすましを行うことはできない情報のみである。
最後に
パスワードを不要とするFIDO認証の詳細と、FIDO認証(あるいはパスキー)がどのようにセキュリティとユーザビリティを実現しているかについてご説明いたしました。
FIDO認証はトレードオフといわれてきたセキュリティ、ユーザビリティを共に実現できる夢のような認証です。
ただ、難点を挙げるとすると、FIDO認証の仕様は様々な技術要素が組み合わさっており、技術的なハードルは高いと言えます。利用するのは簡単であっても、仕組みを作る部分については、この分野について熟知したエンジニアでないと難しいかもしれません。また、利用するための改修や準備には相応のコストや期間が伴います。
認証・認可プラットフォーム「TrustBind」を販売するNTTテクノクロスでは、パスキーやFIDO認証をお客様のサービスやシステムに導入するためのお手伝いをしております。パスキーやFIDO認証の導入にお悩みの場合、ぜひ一度NTTテクノクロスにご相談ください。
補足
補足1:公開鍵暗号方式
公開鍵暗号方式とは、公開鍵と秘密鍵を利用してデータを暗号化する方式です。
特定の秘密鍵には特定の公開鍵が存在し、秘密鍵で暗号化されたデータは対となる公開鍵でなければ復号できず、反対に公開鍵で暗号化されたデータは対となる秘密鍵でなければ復号できないという技術特性が用いられています。
公開鍵は名前の通り外部に公開して利用され、秘密鍵は名前野通り秘密裡に流出しないように管理されます。
例えばデータを渡したいAさんと受け取りたいBさん、その2人のやり取りを盗聴したいCさんの3名がいるとします。
Bさんは自身の公開鍵と秘密鍵を生成し、公開鍵をAさんと共有、秘密鍵はBさん自身で公開せずに秘密裡に管理します。AさんはBさんにデータを送る際に、Bさんから共有された公開鍵を用いてデータを暗号化します。
この暗号化されたデータはBさんが所持する秘密鍵でしか復号することができず、暗号化されたデータをCさんが傍受したとしても、Cさんは対となる秘密鍵を所持していないので、復号することは出来ず、データを安全にやり取りすることが出来ます。
公開鍵暗号方式と同様に、共通鍵暗号方式という技術もありますが、こちらは秘密鍵と公開鍵のように対となる鍵ではなく、1つの共通な鍵で暗号化や復号を行う方式となります。
補足2:電子署名
署名(電子署名とも言われる)は本人証明、非改ざん証明を行うために用いられ、公開鍵暗号方式の「秘密鍵で暗号化されたデータは対となる公開鍵でなければ復号できず、逆に公開鍵で暗号化されたデータは対となる秘密鍵でなければ復号できない」という技術特性を用いて実現します。
DさんがEさんに送るデータが改ざんされていないことを証明するケースを考えてみましょう。
Dさんは事前に秘密鍵と公開鍵を生成し、Eさんに公開鍵を渡しておきます。
DさんはEさんにデータを伝達したい時、伝達したいデータを自身の所有する秘密鍵で暗号化し、伝達したいデータと共に暗号化したデータをEさんに送ります。
Eさんは暗号化していないデータと暗号化したデータを取得し、事前に送られてきたDさんの公開鍵を利用して暗号化したデータを復号します。
この時、Eさんは「暗号化されたデータを復号できたこと」からデータの送信元はDさんで間違いないことが分かり、「Dさんが送りたいデータと復号したデータが一致すること」からデータは改ざんされていないことが分かります。
なお、非改ざん性を証明する仕組みは上記のとおりですが、実際の電子署名では伝達したいデータをそのまま暗号化して送るのではなく、ハッシュと呼ばれるデータ圧縮の仕組みで圧縮されたデータを暗号化して使用します。
合わせて読みたい
パスキー/FIDO認証対応 TrustBind
※本コラムに掲載している商品またはサービスなどの固有名称は、各社の商標または登録商標です。