絶対に理解できる「FIDO」の話 パスワードの弱点を克服する認証：困ったときのビジネス用語（2/3 ページ）

[溝田萌里，キーマンズネット]

“秘密の情報”を共有しないモデル　FIDO認証の特長

　FIDO認証モデルでは、本人確認を生体認証などの情報を使って行うため、ユーザーはパスワードを管理する必要がなく、利便性が向上します。安全性の面では、端末における生体認証などの手段に加え、「公開鍵暗号方式における署名検証」という手段を組み合わせて、二段構えで安全性を確保する仕組みを採用しています。

　専門的な話をすると、従来のIDとパスワードを使った認証方法は、この仕組みの部分でも弱点がありました。以下では、両者の仕組みを比較し、FIDO認証がどのように安全性を保っているのか詳しく説明します。

サーバに秘密を共有する従来の認証方法

　IDとパスワードを使った認証方法の仕組みから見ていきましょう。図1はその流れを表したもの。まずサービス登録の際には、ユーザーの設定したIDとパスワードがサービス側のサーバに送られ、保存されます（図1の0）。

　ユーザーがサービスにログインする際には、ユーザー側がPCなどのデバイスを通してIDとパスワードを打ち込み（同.1）、それに対してサーバ側はあらかじめ登録されたデータと同じものかを照合します。両者の値が一致すればログインが完了するという仕組みです（同.3）。

図1　従来の認証モデル（出典：FIDOアライアンス）

　この仕組みの問題は、ユーザーとサービス側が秘密の情報であるパスワードを共有するということ。サーバには秘密の情報であるパスワードが保存されているため、サーバが攻撃され、情報が流出するという可能性が考えられます。

実は、多くの生体認証ソリューションも同じ仕組みを採用している場合が多く、サービス側のサーバに個人の生体情報、またはそれに相当する情報を共有するという点でパスワードを使った認証と同じリスクを抱えています。万が一、認証に用いられる秘密の情報がサーバから流出してしまえば、甚大な被害となることは想像に難くありません（図2）。

図2　秘密を共有するモデル（出典：FIDOアライアンス）

サーバに秘密を渡さないFIDO認証

　一方、FIDO認証モデルでは流出してはいけない情報をサービス側と一切共有しません。生体情報などを使った本人確認は、ユーザーが所持するスマートフォンなどの端末で完結し、その上で「本人である」という認証結果が公開鍵暗号方式を用いた署名として作成されて、サービス側のサーバとやりとりされるためです（図3）。以下でこの流れをさらに詳しく説明します。

図3　FIDOの認証モデル（出典：FIDOアライアンス）

　図4は一連の流れを説明したもの。まずは、図の行程0番でユーザーの情報を登録します。この際、端末側では秘密鍵と暗号鍵というペアで構成された情報が発行されます。サーバ側には2つの鍵のうち公開鍵だけが送信され、ユーザーアカウントとひも付けて登録されます。これで認証のための準備が整います。

　ユーザーがサービスにログインする際には、まずサービス側のサーバからチャレンジコードというランダムに生成された文字列が送られてきます（図4の2）。次に、端末側のFIDO認証器が、生体情報などを使った本人確認を行い（同.3、4）、サーバから送られてきたチャレンジコード（ランダムな文字列）の情報に「秘密鍵」を使って署名をします（同.5）。

　サーバ側は、この署名に対し、あらかじめ登録された公開鍵を使って、ユーザーが保持するペアの秘密鍵が署名したものかどうか検証を行います（同.6）。ここで、サーバが発行したチャレンジコードなどが改ざんされていないかどうかを確認することで、秘密鍵を持つユーザー以外の「なりすまし」を防げます。この検証が終われば無事ログインが成立します。

図4 FIDO認証の流れ（出典：FIDOアライアンス）

　この仕組みのポイントの1つは、端末とサーバの間で、公開鍵と秘密鍵という異なる性質の情報をペアにしてやりとりすること。仮にサービス側のサーバが攻撃されて公開鍵が盗まれたとしても、ペアとなる秘密鍵を持っていなければチャレンジコードに署名ができず、なりすましを行えません。これが「公開鍵暗号方式を用いた署名検証」を認証に用いることのメリットです。

　秘密鍵が入った端末をユーザーがなくしたとしても、FIDO認証の仕組みではユーザー本人の指紋や声、顔といった情報がなければ秘密鍵は利用できません。秘密鍵は、FIDO認証器を提供するベンダーやメーカーのさまざまな工夫によって端末内の安全な領域に格納されているため、外部から無理に取り出すことも難しいといわれています。

　また、前述したように、このモデル全体を見れば、本人確認に必要な生体情報の認証処理は端末側で閉じたまま行われ（図4の3、4）、端末側で確認した「本人ですよ」という情報が公開鍵と秘密鍵のペアで検証される（同.5、6）という二段構えの構造であることが分かるでしょう。これによって、サービス側のサーバが大事な情報を一切共有しないという仕組みを作り出し、安全性を確保しているのです。