Appleの発表したPasskeys in iCloud KeychainはWebAuthnをどう変えるのか

f:id:ritou:20210615043226p:plain

おはようございます、ritouです。

先日のWWDC2021の "Move beyond passwords" というセッションにて発表された "Passkeys in iCloud Keychain" という仕組みについてどんなものかを紹介します。

developer.apple.com

WebAuthn

数年前からパスワード認証を置き換えると言われ続けている認証技術の一つである "WebAuthn" (やFIDO)という技術をご存知でしょうか。(ご存知ない方は "WebAuthn builderscon" "WebAuthn droidkaigi" などで検索してみましょう) 今回の話をするにあたって、WebAuthnがどんなものかをある程度理解しておく必要があります。

公開鍵暗号の仕組みを利用
- パスワード認証のようにユーザーとログイン対象のWebアプリケーションがパスワードを共有するのではなく、PC/スマートフォンの端末や外付けのセキュリティキーの中に秘密鍵、を保存しつつ生成した署名を送信、ログイン対象のWebアプリケーションが保存している公開鍵を用いて検証する
ローカル認証を利用
- スマートフォンのロック解除に使われるような指紋、顔認証、パターン、4桁PINなど でユーザーを確認する
認証フローにWebブラウザが介入して一連の認証処理が行われたOrigin情報をWebアプリケーション側が検証可能なため、フィッシングのリスクを排除できる
- 2段階認証でよく使われているワンタイムパスワード入力はフィッシング対策にはならない

ということが特徴です。

WebAuthnでは秘密鍵が保存されているデバイスを所持していること、ローカル認証により意図したユーザーが操作していることを検証できるので、単体でもWebアプリケーションのログイン機能の要件を満たせる、かつフィッシング耐性もあるので素晴らしいものだ、という主張です。

この機能が普及するためのキモとして

デバイスの対応("秘密鍵"の保存)
ブラウザの対応(WebAuthnプロトコルへの対応)

があります。

前者については、YubiKey(Yubico)やTitan(Google)というようないわゆる "SecurityKey"だったり、スマートフォン/PC自体がその機能を持ちます。後者についてもPC/スマートフォン向けの対応ブラウザが増えており、今後ますますコンシューマ/エンタープライズ両方での利用が増えていくであろうという状態だとここしばらく言い続けています。

しかし、このWebAuthnの悩ましい問題として、”リカバリー困難問題” があります。

デバイスに保存された秘密鍵は他の端末にシェア/コピーできない

という仕組みのために、デバイスが紛失、壊れてしまったら当然、そのデバイス内に保存されている秘密鍵を用いた認証が利用できなくなってしまいます。

スマホもセキュリティキーも、壊れたり壊されたり落としたり無くしたりとにかく平和じゃない(経験済み)
PC/スマートフォン自体に秘密鍵を保存するケースでは、新しい端末で使い始める時に手間がかかる
- 一度 "別の方法" でログイン状態にしてから、"このデバイスでWebAuthnを利用する"(鍵ペアの生成、公開鍵のやりとり) という一連のフローをやりなおさないといけない
この "別の方法" で安全なものがなくて困る
- WebAuthnが最強！なので他の認証方式だと認証強度が弱くなってしまうんじゃ
- ベストなのは 認証に利用できる状態になったセキュリティキーを大事に引き出しの中にしまっておく ことだけど、コンシューマ向けのユーザーにそこまでさせるのは正直きつい

というのが長年議論されてきました。

Appleの動画にある比較表の"Security Key"の項目で、"Always with you" はユーザーがいくらWebAuthn使いたくても秘密鍵が保持されているデバイスがないとダメよってこと、"Recoverable" はデバイスロスト時に困るってことが表現されています。

f:id:ritou:20210615045708p:plain

Passkeys in iCloud keychain

散々前フリしたところで、Passkeys in iCloud keychainは、ここまで話したWebAuthnの困ってるところをうまく解決しようという試みです。

概要

一言で言ってみると、WebAuthnのキモである デバイスに保存された秘密鍵は他の端末にシェア/コピーできない という部分を デバイスに保存された秘密鍵を「安全な方法」で他の端末とシェア/同期できる ようにすることで、デバイスロスト/リカバリーの問題を解決しようとしています。

Appleの場合は、iCloud Keychainを用いることで他のApple端末とWebAuthnで利用する秘密鍵を共有するぞってわけです。

iCloud キーチェーンを使えば、パスワードやその他の機密情報をお使いのすべてのデバイスで最新の状態に同期できます。

support.apple.com

用語的には、"Passkeys" = "WebAuthnの秘密鍵を共有可能な仕組み" それを iCloud Keychainから利用するんだというのが "Passkeys in iCloud Keychain" だというところでしょう。いや、テキトーなことは言わんほうが良い。

WebAuthnとの利用フローの違い

例えば、WebAuthnに対応したWebサービスAと手元に🍎なデバイスが2台ぐらい(iPhone/iPad)があるとしましょう。

iPhoneでは指紋認証を設定済み
WebサービスAにiPhoneでログインし、新たなログイン方法としてiPhoneを設定
WebサービスAをiPhoneから利用する際は指紋認証でOK
iPadでは顔認証を設定済み
WebサービスAにiPadから何らかの方法でログインし、新たなログイン方法としてiPadを設定
WebサービスAをiPadから利用する際は顔認証でOK

となっていたところが、

iPhoneでは指紋認証を設定済み
WebサービスAにiPhoneでログインし、新たなログイン方法としてiPhoneを設定
WebサービスAをiPhoneから利用する際は指紋認証でOK
iPadでは顔認証を設定済み、iCloud Keychain で秘密鍵を同期!!!
WebサービスAをiPadから利用する際は顔認証でOK

となります。

f:id:ritou:20210615053954p:plain

セキュリティキー(を持ち歩いてUSBの形があれやこれや言いつつとりあえず使えたわ！っていうの)と同じ体験がAppleデバイスを持っててiCloud Keychainで同期してるってだけで味わえます。このリストだけではあんまり便利になった感覚がないですが、これが複数のWebサービス×複数の端末ってなっていくとじわじわ違いとして現れてくるでしょう。

使い物になるかどうか、懸念点はないか

WebAuthnのデバイスロスト/リカバリーの問題を避けられるとなればWebAuthnの普及促進に繋がるでしょう。

秘密鍵の管理という点では、Passkeys in KeyChainはこれまで "デバイス単位" でセキュリティを担保していたものが、プラットフォームを支える "Identity単位" のセキュリティで担保することになります。秘密鍵にアクセスできる端末が増えたということは、それだけ不正利用のリスクも増えると考えることもできます。 WebAuthnをログインに採用しているサービスから観ると、これまで設定済みの端末のみに絞られていたリスクが、iCloud Keychainで同期している全てのApple端末全体に広がってしまうことを認識する必要があるでしょう。

このメリット/デメリットを意識するまでもないコンシューマ向けサービスにとっては良いニュースだと思いますが、NIST SP800-63シリーズで定義されている、厳密なユーザー認証の強度(Authenticator Assurance Level, AAL)を厳密に意識する必要のあるレベルのサービスには多少気になるかもしれません。 "他の端末にシェア可能な秘密鍵は利用できない" "Passkeys in Cloud KeyChain経由のアサーションは受け入れない" みたいな細けぇ分岐処理が出てきたらカオスになるので避けたいところです。

ID連携との違い

Appleはこれを独自の技術としてアッピールするというよりは、「他のPlatform(と言ってもGoogle/Microsoftを名指ししているようなものですが)でも同じような仕組みを用意して使って行ったらいいじゃない」みたいなスタンスを取ろうとしているのが新鮮なところですが、結局大きなPlatformを持つ巨人たちのための仕組みじゃねーか と感じる人もいるでしょう。

デバイスからIdentityへみたいなことを言ったついでに、Sign in with Appleのようないわゆる "ID連携" と今回の "Passkeys in Keychain" の仕組みの比較をしてみたいと思います。

Webアプリ側はWebAuthnのプロトコルを意識するだけで、しれっとAppleアカウントのセキュリティの恩恵を受けられるのが "Passkeys in Keychain"
- 開発者はWebAuthnに対応するだけ
- ユーザーは個々のWebアプリごとに一度手元のApple端末でログインの設定が必要
Webアプリ側が明示的にAppleアカウントの恩恵を受けにいけるのが "Sign in with Apple"
- 開発者はSign in with Appleの実装が必要
- ユーザーはApple ドメイン上で認証するだけ