『パスワードレス化に向けた管理者ガイド』ブログシリーズ
この記事は、Tech Lead である Jeremy Erickson によるブログ「Administrator’s Guide, Part 1: Passwordless is Not Multi-Factorless
」（2021/6/17）の抄訳です。
「パスワードレス」という名前だけから判断すると、パスワードを必要としないログインエクスペリエンスがすべて該当すると思ってしまう可能性があります。誤った例としては、ログインする際にユーザ名だけ入力して、それ以外は何も入力しないというものがあります。パスワードレス ソリューションを検討する際は、セキュリティレベルを下げるものではなく、高めるものでなければなりません。パスワードレスでも多要素認証と同じセキュリティを確保するには、認証要素が複数必要です。
WebAuthn プロトコルには、主に次の 3 つのアクターが存在します。
- Web サイト（Relying Party（RP）とも呼ばれる）
- ブラウザ（クライアントとも呼ばれる）
- オーセンティケータ（Windows Hello、Touch ID、セキュリティキー（例：YuBikey）などさまざまなものがある）
オーセンティケータは、エンドユーザを識別するための暗号キーを生成して安全に保持できるデバイスです。アカウントの登録時に、オーセンティケータはクレデンシャルを生成し、対応する公開キーを Web サイトに送信してユーザアカウントに関連付けます。その後ログイン時に、オーセンティケータは、そのクレデンシャルに関連付けられた秘密キーを使用して、アサーションと呼ばれるメッセージに署名し、Web サイトに渡します。Web サイトは、登録ステップで取得したクレデンシャルの公開キーを使用して、アサーションの署名を検証します。アサーションの署名を検証することで、クレデンシャルが管理されているものであることが証明されます。クレデンシャルは、適切に保護されていれば、オーセンティケータデバイス（ひいてはユーザ）を強力に識別できます。
しかし、クレデンシャルを保持しているのが偽装者ではなく、本当のユーザであることをどうすれば判断できるでしょうか。たとえば、誰かがオーセンティケータデバイスを盗んだとします。そういう場合のために、WebAuthn と CTAP2 では、ユーザ検証（UV）フラグがサポートされています。この方式では、オーセンティケータデバイスは、ユーザの ID をローカルで検証してから、クレデンシャルのロックを解除してメッセージに署名する必要があります。多くの場合、指紋や顔のスキャンなどの生体情報チェック方式が採用されています。または、ローカル PIN を使用してクレデンシャルのロックを解除することもできます。その際、生体情報や PIN がデバイスからサーバに送信されることはありません。
通常、ユーザ検証はローカルでしか実施できないため、このユーザ検証プロセスに対する攻撃は非常に手間がかかりますし、特定のユーザを標的とする必要があるため、攻撃の難易度が大幅に高まります。
WebAuthn プロトコルでは、2 つの要素として以下が使用されます。
- 秘密キー（安全なハードウェアに保管されているのが理想的）
- 生体情報または PIN（ユーザの ID をローカルで検証するためにオーセンティケータが使用する）
オーセンティケータがユーザ検証を実施したことを示すメッセージのビットがどれかは、ここでは重要ではありません。重要なのは、Web サイトがユーザを認証する前に、ユーザがローカルで検証済みであることを信頼できるということです。メッセージに署名されている UV フラグによって、Web サイトは、オーセンティケータがユーザ検証を実施したことを容易に信頼できます。さらにセキュリティを強化するには、オーセンティケータがユーザ認証を実施したと偽装できないようにすることです。
WebAuthn プロトコルはコミュニティで開発されて一般に公開されています。つまり、誰もが比較的少ない工数で、CTAP2 準拠のオーセンティケータをいつでもソフトウェアに実装できるということです。WebAuthn プロトコルには、オーセンティケータが自分自身を証明しなければならないという要件はありません。
実際、WebAuthn プロトコルは、非常に長い時間を費やして、Web サイトがオーセンティケータを使用してインターネット上でユーザの匿名化を解除することができないようにしています（ユーザがログインすることで自分自身を明示的に証明しようとしない限り）。ただし、WebAuthn プロトコルでは、Web サイトは、オーセンティケータが自分自身を明示的に証明しない場合、オーセンティケータの使用を拒否できるようになっています。ここでは、ユーザの ID ではなく、オーセンティケータデバイスの ID について説明します。
オーセンティケータを信頼できるかどうかを判断するプロセスはアテステーションと呼ばれ、ユーザ登録と同時に行われます。最新の Web サイトがブラウザから信頼を得るために、認証局で発行された証明書を必要とするのと同様に、オーセンティケータも、Web サイトから信頼を得るために、認証局から発行された証明書を必要とします。多くの場合、オーセンティケータの認証局は、オーセンティケータを作成した製造元またはベンダーです。
アテステーションプロセスは次のように行われます。
- オーセンティケータが製造/生成されると、製造元は、製造元の認証局によって署名された証明書をオーセンティケータに対して発行します。製造元の認証局の公開キーは公開されているため、Web サイトが使用して、オーセンティケータの証明書の正当性を検証できます。
- オーセンティケータがユーザ登録時に新しいクレデンシャルを生成すると、証明書を使用して、Web サイトに送信する登録メッセージに署名します。登録メッセージはアテステーション オブジェクトと呼ばれ、証明書の署名および公開されている部分は、アテステーション ステートメントと呼ばれます。
- Web サイトは登録時にアテステーション オブジェクトを受け取り、その中のアテステーション ステートメントを調べます。オーセンティケータが提示した証明書に関連付けられた秘密キーを使用して、登録メッセージが署名されていることを確認します。また、オーセンティケータが提示した証明書が製造元の認証局によって適切に署名されていることも検証します。
- 証明書がすべて適切に署名されていて、検証手順が正常に完了したら、Web サイトは、オーセンティケータが、ステップ 1 で証明証を発行した製造元によって発行されたものであると判断できます。Web サイトがその製造元を信頼している場合、オーセンティケータが製造仕様に従って動作していることも信頼できます。信頼できる動作の中には、特定のユーザに対する検証手順が実施された場合にのみ、UV フラグが true に設定されることも含まれます。特定の Web サイトが信頼する製造元やデバイスモデルの詳細は、その Web サイトに委ねられています。
このアテステーションプロセスによって、Web サイトは、承認したオーセンティケータデバイスのみを使用してユーザを特定できるようになりますが、パスワードレスによるセキュリティ上のメリットを得るために、必ずアテステーションが必要でしょうか。
答えはさまざまです。セキュリティが重要な環境では、アテステーションを要求するのが賢明かもしれません。既知の脅威に対処したり、規制に準拠したりするためには、ハードウェアで保護されたセキュアなストレージを備えたオーセンティケータか、
特定のローカルユーザ検証方式を使用したオーセンティケータのみを使用することが、予防策として必要になる場合があります。しかし、多くの場合、Web サイト運用者は、このような厳しい管理を行う必要はありません。
各ユーザは、クレデンシャルを自分のユーザアカウントに登録するためにどのオーセンティケータを使用するかを自分で決められます。また、Touch ID や Windows Hello などの強力なオーセンティケータが、ユーザが自分のアカウントにアクセスする際に利用するデバイスに組み込まれるようになったため、アテステーションを使用しなくても、ユーザが自分のクレデンシャルを安全に保存するだけで十分かもしれません。現在では、これがほとんどの場合に、パスワードと合わせて実施されていることです。しかし、WebAuthn クレデンシャルを使用すれば、セキュアなキーストレージがない最もシンプルなオーセンティケータであっても、攻撃は、個別のユーザに対してローカルでしか実施できません。
Authors