RSS

2020年のWebAuthnアップデート

Digital Identity技術勉強会 #iddance Advent Calendar 2020 12日めの記事です。

年末ということで、気楽に2020年のWebAuthn関連の話題を振り返ってみたいと思います。WebAuthnは2019年に一度W3C勧告になりましたが、その後も色々な実装での採用の拡大や、WebAuthn Level2という新しい改訂版の仕様策定の進展など、2020年も色々動きがありました。それらの中から、興味を惹かれた話題を解説していきます。

SafariでFace ID/Touch IDがPlatform Authenticatorとしてサポート

WebAuthn周りで今年最大の進展というと、やはりSafariのWebAuthn実装がFace ID/Touch IDをPlatform Authenticator(内蔵の認証デバイス)としてサポートしたことが挙げられると思います。WWDC 2020で発表され、iOS14で実際に実装されました。

Face ID/Touch IDでWebの認証が可能になることは、認証時のユーザーのパスワード入力の手間を省くことに繋がる為、特にスマートフォン向けのサイトのユーザー体験の向上をもたらし、非常に意義のあることだと思います。Platform Authenticatorであることから、端末の紛失、機種変更、そしてブラウザの履歴消去でも失われる資格情報になってしまう為、アカウントリカバリ方法の確保はRoaming Authenticator(外付認証デバイス、セキュリティーキー等)以上に重要となりますが、ともあれこれでWindows、Android、Mac、iOS、主要なOSすべてでPlatform Authenticatorが提供されたことになり、Platform Authenticatorを活用した便利で安全な認証が今後流行って欲しいところです。

なお、Face ID/Touch IDをPlatform Authenticatorとして利用する場合、Attestation Statementのフォーマットとして、新しい"Apple Anonymous Attestation“というフォーマットが使用されています。Attestation Statementは、その認証デバイスが信頼出来るデバイスであるかどうかをRelying Party側が検証するために、認証デバイスの構成情報を提供する署名されたデータですが、あまり詳細な情報が載っていると、Relying Partyがフィンガープリンティングに利用し、利用者の追跡に利用出来てしまう為、プライバシーの観点から慎重な利用が求められるものです。Appleは、この懸念に対処するために、Apple Anonymous Attestationでは載せる情報をAndroid Key AttestationやAndroid SafetyNet Attestationと比較して絞り込んでおり、また、Attestation証明書もPacked Attestationを利用している一般的なUSBドングルタイプのセキュリティーキー等と異なり、デバイスに焼き込むのではなく、資格情報毎に新しい証明書を発行し、フィンガープリンティングでの利用を防止しているようです。

Enterprise Attestation

さて、Apple Anonymous Attestationはプライバシー確保のためにフィンガープリンティングを防ぐための設計がされていると述べましたが、逆に企業内利用用途では、認証デバイスのモデルどころか、シリアル番号まで含めて把握したい、というニーズが存在します。このニーズに応える為、WebAuthn Level2では、Enterprise Attestationと呼ばれる新機能が追加されました。

前述のAttestation Statementでフィンガープリンティングされないようにしたい、というWebAuthnの設計目標と対立する為、このニーズは、企業内利用という限定的なユースケースでのみサポートされ、具体的には、ブラウザか認証デバイスがあらかじめ特定のサイトでのみEnterprise Attestationを返却するように構成されており、Relying PartyがAttestation Conveyance Preferenceに新しく定義されたenterpriseというキーを指定して要求していること、を満たした場合に取得できるように制限されるようです。

ちなみにEnterprise Attestationを実装するには、CTAP側にも、Enterprise Attestationを要求されていることをAuthenticatorに伝えるためのフラグの追加等が修正が必要そうですが、現在公開されているCTAP2.1 Review Draftでは、まだそういった追加は見当たりません。まぁそのうち表に出てくるでしょう。

LargeBlob Extension

WebAuthnは、Level2の策定が始まってしばらくしてExtensionの整理が行われ、ブラウザでのサポートが進んでいないExtensionはLevel1で勧告化されたものであってもバッサリと仕様から削られましたが、LargeBlob拡張は、入れ替わりにLevel2から入った新しいExtensionです。このExtensionを利用すると、認証時に、資格情報とは別に認証デバイスに対してバイナリデータを読み書き出来ます。

が、使いどころが中々難しい印象です。largeBlobと名前はついていますが、保存出来るデータ量はたかが知れているでしょうし、サーバー側のDBに保存するでもなく、クライアントのlocalStorageに保存するでもなく、認証デバイス内部に保存することに価値があるデータとはいったい何なのか、直ぐには思いつきません。

residentKeyオプションの追加

WebAuthnの資格情報には、二要素認証の第二要素にのみ使えるServer Side Credentialと、認証デバイスにデータを保存し、ユーザーのID入力を省略した認証が可能なClient Side Discoverable Credentialの二種類があります。

WebAuthn Level1では、どちらを生成するかの選択をAuthenticatorSelectionCriteriaというデータ構造のrequireResidentKeyというパラメータで指定しましたが、指定可能な値がbooleanであり、「residentKey(discoverable credential)のみ受け入れる」という指定しかできませんでした。

WebAuthn Level2では、AuthenticatorSelectionCriteriaに対してresidentKeyという新しいメンバが追加されました。値としては、disrouraged, preferred, requiredが指定でき、

  • discouraged : Server Side Credentialが望ましいが、Client Side Discoverable Credentialも受け付ける
  • preferred : Client Side Discoverable Credentialが望ましいが、Server Side Credentialも受け入れる
  • required : Client Side Discoverable Credentialのみ受け入れる

と、オプションの表現の幅が広がりました。このresidentKeyの追加に伴い、これまでのrequireResidentKey は非推奨となっています。

Credential Properties Extensionの追加

residentKeyオプションによって、どちらの資格情報を作成したいかオプションの指定が細かく出来るようになりましたが、実際に作成された資格情報がServer Side Credentialなのか、Client Side Discoverable Credentialなのか、判別したいというニーズに対し、Credential Propertiesというクライアント拡張が追加されました。戻り値として、Client Side Discoverable Credentialであるかを示す値が返却されます。

Cross-Origin iframeサポート

WebAuthnでは、デフォルトでは、iframe内外でオリジンが異なる場合にiframeの中で読み込まれたサイトでWebAuthn APIを実行することを許可しません。クリックジャッキング攻撃を防止する為です。しかしながら、これが出来ると、例えば決済業者の支払のダイアログをWebページに埋め込んだ上で認証を求めることが出来たりと便利だよね、ということで、明示的に許可を与えることでWebAuthnのAPIをオリジンが異なるiframeの中から呼び出すことが出来るようにWebAuthn Level2では改訂が進められています。

caBLE

前述の通り、SafariのWebAuthn実装でFace ID/Touch IDがPlatform Authenticatorとしてサポートされたことで、主要なOSでPlatform Authenticatorを利用する環境が整ってきた一方で、Roaming Authenticatorについては、ブラウザのサポートは先行していたものの、認証デバイスの所持率が上がらず、WebAuthnの普及の妨げとなっています。そもそも1個数千円する認証デバイスを一般ユーザーがわざわざセキュリティの為に自分から進んで購入することは考え難く、WebAuthnの一段の普及促進のためにはユーザーが元々保有している機器が認証デバイスとして利用できるようになることが期待されてきました。スマートフォンは、その点最適で、指紋センサーやIRカメラを搭載し生体認証が可能で、秘密鍵を安全に保存できる対タンパ性の高い保存領域があり、ユーザーが常に持ち歩いているという特性が非常にマッチしています。

caBLEはスマートフォンを認証デバイスとして活用するシナリオを実現するために、認証デバイスとクライアントの間のトランスポートとしてGoogleが提案しているFIDO CTAP2仕様に対する拡張です。元々、認証デバイスとクライアントの間の非接触方式のトランスポートとしては、NFCとBLEをベースとしたトランスポートが定義されていましたが、NFCはリーダーを備えているPCが限られていること、BLEは、使用開始にあたり、ペアリングが必要であることがユーザービリティ上の課題であり、スマートフォンのインターネット接続性を活用して、ペアリングの手間を省いたBLEベースのトランスポートを新たに実現しよう、というものが、caBLE(cloud assisted BLE)です。

このcabLEについて詳しい仕様はまだドキュメントとして公開されておらず、断片的な情報が聞こえてくるのみだったのですが、先日のFIDOセミナーでGoogleの担当者からcaBLEの紹介のセッションがあり興味深いものでしたので、興味のある方は、FIDOセミナーのサイトで、レコーディングがまだ配信されていますので、見てみると良いかと思います。あと、1年位で、caBLEも使えるようになりそうです。

まとめ

以上、WebAuthnの最近の変化を紹介してきましたが、如何でしたでしょうか。少しづつですが、着実に実際に使っていくためのピースは揃いつつあるのかなという印象です。WebAuthn仕様も段々長くなってきて読むのが面倒になりつつありますが、このエントリがキャッチアップの助けとなれば幸いです。