新春特別企画

パスワードレス認証WebAuthnの勘所と対応状況

この記事を読むのに必要な時間:およそ 5 分

cross-platform Authenticatorと
platform Authenticator

ClientとAuthenticatorが明確に分かれていることにより,セキュリティキーのような外部デバイスを利用すると,ひとつのキーを別々の環境で利用できる相互運用性が生まれます。またユーザー認証の方法は,各Authenticatorにより異なり,生体認証を用いた認証やPINによる認証など,Authenticatorを入れ替えることによって,ユースケースにあった認証方法をサーバー側はほとんど意識することなく選択可能です。このような外部Authenticatorはcross-platform Authenticatorと呼ばれ,それらとブラウザーとのやりとりはCTAP(Client To Authenticator Protocol)として標準化されています。

しかし,実際のところセキュリティキーのような外部デバイスだけがAuthenticatorではありません。

図5 2種類のAuthenticator platform & cross-platform

画像

WebAuthnではセキュリティキーのような外部認証デバイス以外に,platform Authenticatorと呼ばれる,⁠Platform」に紐づいたAuthenticatorが定義されています(上図②)⁠⁠Platform」とは,すなわち「Windows」「Android」などであり,WebAuthn互換のAPIが各種プラットフォームに用意されています。ブラウザーがそれらのAPIを呼び出すことで認証を行います。ただしこれらのAPIは,CTAPのように標準化されているわけではないため,各ブラウザーやOSベンダーが独自に実装を行うことになります※5)⁠

※5
独自にiOSのAuthenticatorを実装している方もいますlyokato/WebAuthnKit)⁠

すでにいくつかのプラットフォーム上では実装が進んでおり,Android上ではモバイル版ChromeがAndroidのAPIを呼び出し,指紋やPINを利用して認証を行えます(ヤフージャパンで実装されたのは,こちらのAPIを利用しています)⁠

またWindows 10上のMicrosoft EdgeはWindows 10のAPIを呼び出し,Windows HelloがAuthenticatorとして振舞います。MacOSではChromeがKeyChainのAPIを呼び出して認証を行います。いずれの場合においてもTEEやTPMといったセキュアデバイス,あるいはそれに準ずるセキュアな領域にキー情報を保存します。

図6 Platform Authenticatorの例(Android)

画像

ところで,外部・内部Authenticatorを問わず,WebAuthnでは認証情報はデバイスに依存することになります。例えばスマートフォン上で作成した認証情報は,そのスマートフォンでしか利用できません。またユーザー認証を行うための指紋やPINなどの情報もデバイスに紐づきます。

これは従来のパスワード認証のような「デバイスを問わず利用できる認証情報」と大きく異なる点です。WebAuthnではデバイスを紛失した場合,認証情報も同時に失われます。そのため,デバイスの紛失に対するアカウントリカバリの方法も検討しなければなりません。GitHub上でも盛んに議論されており秘密鍵をクラウド上にバックアップする仕様や,アカウントリカバリ用バックアップキーの仕様などが提案されています。その他にもセキュリティを担保するためには,デバイス紛失時には,直ちに対応するキーペアを無効化するなど,対策が必要になります。

デバイスの紛失やアカウントリカバリの他にも,検討すべき点はあります。ユースケースとして,PC上のブラウザーやアプリケーションでのログインを,スマートフォンを利用して行いたいというケースがあるかと思います。その場合,WebAuthnのスペックのみでは,PUSH通知や認証情報の受け渡し等が足りず個別の実装が必要になります。

図7 Push通知による他デバイスの認証

画像

例えば上図の②,④はスペック外のため独自の実装となります。

このような認証を単純に実装すると,ログイン画面を偽装し,本物のサービスとバイパスすることでフィッシングが可能になってしまいます。

図8 Push通知によるログインへのフィッシング攻撃

画像

フィッシングの可能性を指摘しましたが,このようなユースケースは決して非推奨ということではありません。ここで注目してほしいのは,WebAuthnはあくまで認証プロトコルであり,RPとClient,そしてAuthenticatorになるデバイスという経路においてはフィッシングを防げますが,それ以外の部分には関与しないという点です。つまり,インターネットを経由した他デバイスからの認証を実装する場合や,認証後の認可フローを検討する場合は,ユースケースに応じた対策が必要になります。

さて,このような攻撃を防ぐ方法の一つとして,スマートフォンをPCとCTAPプロトコルで接続することが考えられます。スマートフォンとPCがCTAPでつながると,先ほど話したとおりWebAuthnの認証は正しいrpIdとoriginの組み合わせでのみ行われるため,上記のような攻撃を防ぐことができます。

ただし,この場合フィッシングに対しては強くなりますが,PCとスマートフォンを何かしらのインターフェイスで接続することが必要になります。

図9 CTAPによるスマートフォン認証

画像

最も現実的なのはBLEを利用することですが,通常BLEは事前のペアリングが必要で,利便性が高いとは言えません。それに対しChromeではcaBLEと呼ばれるBLEの接続方法を検討しているようです。

著者プロフィール

@watahani

もと本屋のソフトウェアエンジニア3年目。昨年からFIDOやWebAuthnといった認証技術について調査やコミュニティ活動を始める。YubiKey検定3級(自称)。

Twitter:@watahani
ブログ:https://blog.haniyama.com