パスワードなしでの認証を可能にする「パスキー」技術にはわなが潜んでいる、YubiKeyなどのハードウェア認証デバイスを利用している場合は注意

「パスキー」は各種ウェブサイトにパスワード不要でログインできるようにする仕組みで、AppleやGoogle、Microsoftといった大手テクノロジー企業が利用を推進しています。しかし、使い方を誤るとYubiKeyなどのハードウェア認証デバイスが使い物にならなくなってしまうとして、RustのWebAuthnライブラリを作成しているウィリアム・ブラウンさんが注意を促しています。

Firstyear's blog-a-log
https://fy.blackhats.net.au/blog/2023-02-02-how-hype-will-turn-your-security-key-into-junk/

パスキーの認証の仕組みには、クライアント側に鍵を保存しない方法と、クライアント側に鍵を保存する方法の2種類が存在しています。クライアント側に鍵を保存しない場合、あらかじめ認証に利用する鍵を生成し、セキュリティキーのマスターキーを利用して暗号化し、認証情報を利用する当事者である「Relying Party(RP)」に送信しておきます。認証時には下図の通りRPから送信してもらった認証情報IDから鍵を取り出して「チャレンジ」と呼ばれる乱数に署名することで正当なユーザーであることを証明します。

上記の通りサービス側に保存される鍵は、「Non-Resident Key(非居住者キー)」や「Non-Discoverable Credential(発見不可能な認証情報)」とも呼ばれています。セキュリティキー内にはマスターキーしか保存されないため、アカウントを大量に作成しても全く問題ありません。ただし、認証時に適切な認証情報IDを送信してもらうために先にIDを入力する必要があります。

一方、クライアント側に鍵を保存する方法の場合、認証の手順において、認証情報IDを復号する代わりにセキュリティキーに保存されているキーを選択し、そのキーでチャレンジに署名することで正当性を証明します。

クライアント側に鍵を保存することで、パスワードだけでなくIDの入力も不要にすることが可能ですが、鍵の保存スペースを確保する必要があります。ブラウンさんによると、ハードウェア認証デバイスにおいて鍵の保存スペースは非常に貴重とのこと。例えばYubiKeyの場合、20個から32個の鍵しか保存することができません。

さらに、クライアントとハードウェア認証デバイス間の通信の仕様である「Client to Authenticator Protocols(CTAP)」のどのバージョンをサポートしているかによってさらに厄介な問題が発生します。CTAP2.1PREやCTAP2.1をサポートしているハードウェア認証デバイスであれば、内部に保存されている鍵を更新したり削除したりすることが可能ですが、CTAP2.0仕様のハードウェア認証デバイスの場合は一度保存した鍵を変更・削除することが不可能です。

そのため、誤った鍵を保存してしまった場合には、その鍵のスペースを諦めるか、デバイス全体をリセットすることになりますが、デバイス全体をリセットした場合にはマスターキーが変更されてしまい、そのデバイスに紐付いていた全ての認証情報が機能しなくなります。

AppleやGoogle、Microsoftといった大手テクノロジー企業が利用を推進していることで、パスキーの利用は広まっていますが、「ユーザー名やIDすら入力しなくて良くなる」というメリットが注目されてクライアント側に鍵を保存する方式が主流になっており、ハードウェア認証デバイスの容量が足りなくなる恐れがあるとブラウンさんは指摘しています。ブラウンさんのパスワードマネージャーには150を超えるサイトのパスワードが保存されており、仮に全てのサイトがパスキーに対応した場合、ブラウンさんは5個のYubiKeyを追加で購入する必要がでてくるわけです。しかも、認証するサイトごとに対応するYubiKeyに交換する必要があり、とても「使える」とは言えない状態になってしまいます。

スマートフォンを利用したパスキーにおいてはストレージ容量の制限が緩いため、クライアント側に鍵を保存しても問題ありません。クライアントに応じて使い分けたいものですが、記事作成時点の仕様では、Relying Party(RP)がクライアント側に鍵に保存する「Resident Key(RK)」方式をとりたい時の要求レベルが3段階に分かれている中で、下図の通り「rk=preferred」という要求をした場合でも、ストレージが限られているハードウェア認証デバイスの場合にRK方式が選択されてしまいます。

上記の問題が解決するまでは、「rk=discouraged」を指定するのが次善の策とのこと。また、ハードウェア認証デバイスに対してFIDOが数千個の鍵を保存できるストレージの確保を義務づけるという解決方法も考えられると述べられています。