- Passkeysをresident keyとして定義し、それを要求する流れが広がると、Yubikey・Feitian・Nitrokeyのようなセキュリティキーは限られた保存容量のため、すぐに限界に突き当たる
- non-resident credentialは、Relying Partyが提供したcredential IDをセキュリティキーが復号してRPごとの秘密鍵を得る構造であり、デバイス内部にはmaster keyだけが保存される
- 一方、resident/discoverable credentialは秘密鍵そのものをセキュリティキーに保存するため、アカウントごとにスロットを消費し、Nitrokeyは8個、Yubikeyは通常20〜32個程度しか対応しない
- CTAP2.0セキュリティキーではresident keyを個別に削除できず、全体初期化が必要で、このときmaster keyも変わるため、既存のnon-resident keyまで動作しなくなる
- サービスやライブラリがresident keyをデフォルトで要求すると、150件以上のアカウントを使うユーザーは複数のセキュリティキーとバックアップキーを管理しなければならず、望む認証器を自由に選びにくくなる
resident keyが問題の中心である理由
- Passkeysへの過熱した期待がセキュリティキーを時代遅れのデバイスのようにしてしまうかもしれない、という懸念の核心にはresident keyがある
- セキュリティキーがアカウント数を「無制限」に支援できるという認識は、多くの場合non-resident credential方式に依存している
- resident keyはセキュリティキー内部の保存領域を実際に消費するため、アカウント数が増えるほどデバイスの限界がすぐに表面化する
non-resident credentialの動作方式
- non-resident credentialでは、Relying Partyが認証時にcredential IDをブラウザ経由でセキュリティキーに渡す
- credential IDはセキュリティキーだけが復号できる暗号化blobであり、復号結果はそのRelying Party専用の秘密鍵である
- セキュリティキーは復号した秘密鍵でchallengeに署名し、その署名をブラウザとRelying Partyに返す
- この構造では秘密鍵がセキュアenclave内に常駐せず、セキュリティキー内部にはmaster keyだけがある
- credential IDはAES-128で暗号化され、HMACが適用されているため、外部から改ざんまたは復号するのは難しいと評価されている
- AES-128が破られて、セキュリティキーなしで秘密鍵を復号できるなら、TLS暗号化やSSHも攻撃可能なレベルだという比較がある
resident/discoverable credentialの違い
- resident keyまたはdiscoverable credentialは、秘密鍵がセキュリティキー内部に保存される方式である
- Relying Partyが空のcredential ID一覧を送ると、セキュリティキーがそのRPで使える鍵を探して選択し、署名する
- この構造は、外部からcredential IDを受け取ってmaster keyで復号する方式に依存しない
- その代わり各credentialがセキュリティキー内部の領域を占有するため、resident keyスロット数が実質的なアカウント数の上限になる
userVerificationはresident keyとは別物
- credentialがuserVerificationを強制するには必ずresidentでなければならない、という混同があるが、この2つの概念は分離されている
- セキュリティキーはタッチでpresenceを確認するだけでなく、内部でPINや生体認証を検証して、実際の利用者かどうかを確認できる
- この動作はuserVerification flagで制御され、key residencyとは別に動作する
- したがってresident keyでなくても、デバイスは独自に多要素認証器のように使える
セキュリティキーの保存容量とCTAPの制約
- resident keyはデバイス内部に保存されるため、セキュリティキーのスロット数が重要になる
- Nitrokeyはresident keyを8個サポートする
- Yubikeyは一般に20〜32個をサポートする
- 一部のキーはresident keyをまったくサポートしない
- セキュリティキーが実装するCTAP標準も、管理のしやすさを大きく左右する
- CTAP2.1とCTAP2.1PREではresident keyを個別に管理、更新、削除できる
- CTAP2.0ではresident keyを削除するにはデバイス全体の初期化が必要になる
- CTAP2.0デバイスの初期化ではmaster keyも一緒に初期化されるため、既存のnon-resident keyまで動かなくなる
- 多くのセキュリティキーはCTAP2.0である可能性が高く、Yubicoの場合、CTAPバージョンはファームウェアバージョンによって異なる
passkeysという名称とresident key定義の広がり
- Appleは2022年、macOS/iOSでTouch IDとFace IDをWebAuthn authenticatorのように使うpasskeys機能を発表した
- passkeysという名称は、「webauthn authenticator」や「security key」よりもユーザーに親しみやすい呼び名だと評価されている
- その後、passkeysの意味が明確に固定されないまま、さまざまな解釈が現れた
- Rust WebAuthnライブラリとRelying Party実装者は、passkeysをユーザーが選択できるすべてのauthenticatorの名称として定義した
- 一部のコミュニティ参加者は、passkeysを複数デバイス間で同期されるcredentialと呼んだ
- FIDO Authenticateカンファレンスでは「passkeyはresident keyである」という定義が登場し、その後FIDOもFAQでこの定義を使っている
- resident key定義が注目される理由の1つは、ブラウザの予定機能であるconditional UIと結びついているためである
- credentialがresident keyであれば、ユーザー名とWebAuthn credentialを自動補完できる
- ユーザーが自分でユーザー名を入力しなくてよい体験を提供する
resident key要求が生むユーザー問題
- WebAuthnライブラリがすべての登録にresident keyを要求するよう誘導すると、保存容量が限られたセキュリティキーはすぐにいっぱいになる可能性がある
- たとえば、パスワードマネージャーに150件を超える保存済みパスワードがある場合、それをすべてresident keyに変えるには、少なくとも5本のYubikeyが必要になる
- バックアップまで考えると、10〜15本のYubikeyを管理しなければならないかもしれない
- これはセキュリティキーを選んだユーザーにとって悪いユーザー体験であり、passkeysのresident key要求によってセキュリティキー自体の利用が難しくなりうる
- FIDO認証キーのマーケティングでは「無限のkey pair storage」や「登録アカウント数の制限なし」といった文言が使われるが、これはnon-resident keyでは正しくてもresident key要求とは衝突する
- WebAuthn Work Groupの目標の1つは、ユーザーが望むauthenticatorを不利益なく自由に選べるようにすることだが、resident keyの強制はこの目標に合わない
- passkey環境で適切に動作する認証器の種類として、Apple passkeys、Android passkeys、WebAuthnをサポートするパスワードマネージャー、TPM 2.0を使うWindows、Touch IDをTPMのように使うmacOS上のChromiumベースブラウザが挙げられている
可能な対応の方向性
- rk=preferredの動作を変え、セキュリティキーではresident keyを作成しないようにする案がある
- 現在、Relying Partyはresident key要求レベルを
discouraged、preferred、requiredのいずれかに指定できる
- 現在の
rk=preferredは、roaming authenticatorであるYubikeyでもresident keyを作成し、結果としてrk=requiredと似たように動作する
preferredを「保存容量が無制限のときだけresident keyを作成する」と緩和すれば、Android/iOSではresident keyを作りつつ、セキュリティキーの保存領域は消費しないようにできる- WebAuthn WGはまだこの変更に消極的であり、ブラウザが別途実装するには現実的にはChromeチームの判断にかかっている
- passkeyライブラリにrk=discouragedの使用を求める方法もある
rk=requiredはセキュリティキーを排除しうるrk=discouragedはAndroidユーザーがconditional UIを得られなくなる可能性がある- ユーザー名にはすでに自動補完手段があるため、セキュリティキーを排除するよりはよいという判断である
- FIDOにresident key保存容量を認証要件として求める案もある
- 現在、FIDOは認証デバイスに対して保存容量要件を義務化していない
- FIDOがresident keyを望むのであれば、認証デバイスが数千個のresident keyを保存できるようにすべきだという主張である
結論
- passkeysをresident keyとみなす過熱した流れは、セキュリティキー利用者がオンラインで望むauthenticatorを選ぶことを妨げたり、著しく難しくしたりする可能性がある
- 問題はpasskeysそのものよりも、保存容量と管理機能が限られたセキュリティキーにresident key要求を一律に適用する点にある
1件のコメント
Hacker News のコメント
暗号化そのものとは少し違う話だが、母から Gmail に入れないとパニック状態で電話がかかってきた。調べてみると Google が新しい Android スマホを パスキーとして自動登録し、それをデフォルトのログイン方法に変えていたのだが、UI があまりにも分かりにくかった。
パスワードでログインするには 2 番目の選択肢を押さないといけないとか、パスキーが何かを理解している前提なのは無理があると思う。「Android にパスキーを送信しました」と表示されてもスマホには通知が来ず、30 分見ても解決できなかった。自動登録されたパスキーを削除することも、デフォルトの認証フローを無効にすることもできなかった。Google の UX はひどく、低価格帯の Samsung スマホ向けに改変された Android を大規模認証システムの土台として信頼したのは愚かな判断に見える
最近 Google で経験した問題の 1 つにすぎない。以前はプライバシーのために何となく避けていたが、今では Google の利用をできるだけ減らすことに全力を注いでいる。Google Maps では理由もなくビジネス情報が削除され、再登録に 2 週間かかり、人間と電話で話すことは不可能だった。サポートメールはどれも電話番号を案内してくるが、それは広告サポート番号なので停止されたビジネスアカウントには何もできず、Google Business チームがその番号をサポート用として案内している事実すら信じようとしなかった。Google Ads のサポート担当に、Google Business 関連の担当者と話す方法はないと認めさせるまで 30 分間同じ質問を繰り返さなければならなかった。今ではもう 反 Google の伝道師になっている
スマホのバッテリーが切れていたら？ スマホをなくして、位置情報サービスの認証情報を復旧するためメールでパスワード再設定を送りたいのに、そのメールにログインできなかったら？ そこから「質問に答える」手続きが始まる。責任の所在が不明な隠れたアルゴリズムが Linux の ungoogled chromium を怪しいと判断し、「現在使えるストレージ容量の何パーセントを使っていますか？」のような質問の答えを間違えて覚えていたら、アクセス復旧は運任せになる。ちなみに自分は有料の Google ユーザーだ
それでも言いたいことは完全に分かる。UX も用語もややこしい。各ステップで説明が出ていても、人は特に急いでいるときには小さな説明文を読み飛ばし、いちばん大きくて派手なボタンを押すように学習されているので、あまり助けにならない。UX 設計として本当に難しい問題だ
ユーザーが離れない限り Google は気にしないし、気にする必要もない。別のものを望むなら、広告主が費用を負担しないサービスが必要だ。Google があるやり方でユーザーを搾取するなら、Apple は別のやり方で搾取するだけで、毒を選ぶことは本当の選択肢ではない
Apple が実際には定義していないせいで、「パスキーって結局何なのか？」を知りたがるユーザーのために思想家たちがその空白を埋めることになった。
自分は、Apple はパスキーを iCloud Keychain と同期される鍵ペアとして定義しているものと理解していた。WWDC 2021 の発表でも、パスキーは「常に持ち歩ける」もの、つまりデバイス間同期と「復旧可能」である点によって、セキュリティキーとは別物だと区別されていた。その後、定義は別のクラウド同期方式にも拡張されたようだ。この記事は間違った折衷をしていると思う。セキュリティキーは重要ではない[1]。使っているのはごく少数の技術ユーザーと、セキュリティを本当に重視する少数の企業だけだからだ。Web の安全性を高めるには、人々をパスワードから脱却させなければならず、人口の 99% は強制されない限りセキュリティキーを使わないだろう。パスキーは、とりわけ OS 深部との統合のおかげで、パスワードを置き換える可能性が高い。1% 未満のユーザーに常駐キー用スロットが足りないからといって、認証をそちらに合わせて最適化すべきではない。[1] Yubikey 3 本、Yubico セキュリティキー 3 本、SoloKey 1 本を持っている
ユーザーはバックアップ・復旧可能なパスキー提供者を使うかどうかを選べて、relying party はそのシグナルを受け取る。そのシグナルを見て、パスワードログインの選択肢を削除する提案をするかどうか判断することもできる
FIDO 標準によれば、パスキーはパスワードを置き換え、ユーザーが複数のデバイスから Web サイトやアプリにより速く、簡単に、安全にログインできるようにする。パスワードと違って、パスキーは常に強力でフィッシング耐性がある。https://fidoalliance.org/passkeys/
rk=requiredがなぜ存在するのかわからない。そもそもオプションであるべきではないこういう点のせいで、私はパスキーとその関係者をずっと懸念し、懐疑的に見てきた。彼らには、Microsoft のような大企業がセキュリティと互換性を深刻に損ない、競争を殺すためのありとあらゆる 悪質な市場慣行 に使いやすい道具にならないよう、プロトコルを設計する責任がある。ところが、記事や投稿で繰り返し示される態度は、むしろ「くたばれ、乱用をもっと簡単にしてやる」に近い。これは常駐キーだけの問題ではなく、たとえば証明（attestation）の扱い方も企業を潰すために簡単に悪用され得る
あるサービスが
rk=requiredを設定していて、プラットフォーム側がそれを有効化したくない、サポートしたくない、あるいは不可能なら、手続きは常に失敗して登録すらできないはずだ。ユーザーをオンボーディングして事業を拡大したいのなら、自分で自分の首を絞める選択に見える私はセキュリティや暗号の人間ではまったくないので、この記事は非常に追いにくく、他の人もそうだと思う
十分な前提知識がある人には変な質問に見えるかもしれないが、1、2文ごとに引っかかる。「結局は一つ、常駐キーに行き着く」というのがどうしてなのか、なぜなのかもわからないし、パスキーや HSM とのつながりもわからない。「発見可能な／常駐キーが何かを理解する必要がある」という言い方は、すべての常駐キーが発見可能キーだという意味なのか、すべての発見可能キーが常駐キーだという意味なのか、両方なのか曖昧だ。「ほとんどのキーが『無制限』アカウントをサポートしているのを見たことがあるはずだ」とあるが、ここでいうキーがパスキーなのか HSM に保存されたキーなのか、あるいは両方なのかわからない。「キーで包まれたキーをセキュリティキーに送る」というのも、HSM が無制限アカウントに適用できる理由が、あるキーを別のキーで包んで保存できるからという意味なのかも混乱する
携帯電話ならパスキーを 1 万件保存しても問題ないが、最新のハードウェアキーでは利用可能なフラッシュ全体で 25 件しか保存できないこともある。この保存領域が必要になる理由は発見可能性だ。たとえば GitHub.com のログインページで新しいパスキー対応を押すと、アカウント名すら入力せずにログインできる。ブラウザがパスワードマネージャのような体験を提供し、パスワードマネージャ内のパスワードのように、パスキーもローカルでサイトアカウントのレコードになる。しかし WebAuthn にはパスキー以外のモードもいくつかある。発見不可能な資格情報では、特定のユーザーアカウントに対してハンドルの一覧を提供する必要があり、このハンドルは登録時にキーが提供したものだ。認証時には、そのハンドルに一致する資格情報だけが選択肢として提示される。ハードウェアセキュリティキーはこの点を利用して、将来の暗号演算に必要なレコードをハンドル自体に保存し、このモードではフラッシュ保存領域を使わない。ユーザーがユーザー名を入力すると、ある API がハンドル一覧を返し、それをセキュリティキーに適用することで、保存領域の制限なしに認証できる。ただし多くのサイトは、アカウントの存在有無を露出しない方針を取っている。「このアカウントが存在する場合、まもなくメールが届きます」といった復旧手順を見たことがあるだろう。ログイン手順が、ユーザー名やメールにひも付くアカウントがあるかどうか、どれだけの資格情報が記録されているかを検知する API を提供するのは、サイト側として受け入れがたいかもしれない。結局、サイトがこの手順を広く採用して現在のハードウェア制約に影響するよりも、保存容量が 10 倍あるセキュリティキーが出てくる可能性のほうが高そうだ
rk=requiredを指定できる機能は有害だという主張だ。なぜなら、そのせいで多くの TPM ハードウェア がパスキーウォレット／データベースとして動作できなくなるからだコメントの大半はこの点に同意すると思う。だからといって、筆者が記事の半分をパスキーの定義論争に費やして生んだ混乱が正当化されるわけではない
パスキーは FIDO2 の上に実装され、とくに FIDO2 仕様の 常駐キー 機能を利用する。FIDO2 のハードウェア認証装置は厳密には HSM ではないが似たようなもので、Yubikey のように HSM でもあり FIDO2 認証装置でもある機器もある。FIDO2 では「常駐キー」と「発見可能キー」は同義語だ。仕様では「常駐キー」を使うが、「発見可能キー」もよく使われ、FIDO が生んだ紛らわしい用語の一つだ。「キー」はパスキーや HSM に保存された鍵ではなく、Yubikey のような FIDO2 ハードウェア認証装置を指しており、一般には「セキュリティキー」と呼ばれる。FIDO2 ハードウェア認証装置は、常駐キーを使わない限り実質的にステートレスで何も保存しないため、無制限のアカウントに登録できる。アカウントに登録されるとき、装置上で EdDSA のような鍵ペアを生成するが保存はせず、秘密鍵を内蔵マスターキー、たとえば AES256 鍵で暗号化する。その後、平文の公開鍵と暗号化された秘密鍵を google.com のような relying party に送って保存させる。認証時には暗号化された秘密鍵、つまり「包まれた」鍵が認証装置へ送られ、装置内で復号された後、デジタル署名の生成に使われる。ただし FIDO2 は非常駐キーの実装方法を実際には規定しておらず、包まれた鍵は一つの方法にすぎない。FIDO2 が要求するのは、秘密鍵が資格情報 ID から安全に導出可能でなければならないということだけで、資格情報 ID は包まれた鍵である場合もそうでない場合もある任意のデータだ
少し厳しく見すぎているように思う。脆弱なパスワードやパスワードの使い回しをなくして日常的なアカウント侵害の99%を防ぐ新しい認証標準の利点を享受したいなら、2013年から使い続けている旧型 YubiKeyから離れて、30ドル払ってアップグレードすべきだと考えることもできる
Bio FIDOモデルはどうなのか分からないが、似たようなものなら YubiCo には多数の常駐キーにうまく合う製品がないのかもしれない。修正: Bio も同じく25個制限
共有される常駐キーは、短期の一時利用を除けば存在すべきではない。これは責任負担であり、セキュリティリスクであり、悪いセキュリティ慣行を助長する。最も良い例が、セキュリティの観点から欠陥の多い TOTP だ。共有シークレットを複数のデバイスで共有したりバックアップしたりしたくあるべきではないが、それが可能であること、そしてずさんな2段階認証実装が例外ではなく標準になったことで、事実上そうするよう強いられている。今の流れを見ると、パスキーも同じように欠陥が多く、ユーザーに敵対的な方向へ進みそうだ
「持っているが失くすかもしれないもの」に基づく認証は、根本的に壊れている。デバイスを失えばアクセス権も失うか、そうでなければ最弱点が別の場所にあるはずなので、その優れたセキュリティ性に意味がなくなる
結果が証明することになるだろうが、パスキーが広く採用されれば、大多数にとってはアカウントロックの頻度は増えるどころか減るように思う
ハードウェアキーの保存容量はなぜこんなに制限されているのか気になる。キーの中に、セキュアプロセッサがアクセスできる大容量ストレージを一緒に入れるには、どれくらい余計にコストがかかるのだろうか
この大容量ストレージは当然セキュアプロセッサが強力に暗号化し、すべてが消去されるときにはその鍵も一緒に消えるようにすればよい
セキュリティの観点では、保存領域が0のセキュリティキーが最高のセキュリティキーだとさえ言える。セキュリティトークンを共有シークレットなどから導出せず、セキュリティキーやセキュア領域などに注入して保存するプロトコルには、おおむね深刻な欠陥があった。TOTP のように根本的なセキュリティ欠陥である場合もあれば、複雑性の欠陥である場合もある。同様に、HSK/2段階認証用セキュリティキーを複数のデバイスで共有したいとは絶対に思うべきではない。1台のデバイスで漏えいすれば、すべてが台無しになるということだ。代わりに各デバイスに個別のキーを持たせるべきであり、ログイン提供者やサーバー側にとってこのオーバーヘッドは大局的には無視できる
小さい保存領域には、監査がややしやすいという利点もある。もちろん現代の基準では、その小さなサイズですら現実的に監査可能な範囲を押し広げすぎているのかもしれない
TPM を見ると、何かに署名するたびに入力されるのは署名対象データと封印された秘密鍵だ。封印された鍵は、TPM が生成した秘密鍵を TPM 内蔵の鍵で対称暗号化したものだ。この封印された鍵を大容量ストレージに保存しておき、署名処理のたびに TPM に渡す。この設計により、大容量ストレージが許す限り多くの鍵を持てる
セキュリティキーをスロットに挿すと、USB メモリがセキュリティキーに保存領域を提供し、コンピュータにはセキュリティキーとして見える。セキュリティキーを挿していないときは普通の USB メモリとして動作する。普段はセキュリティキーを挿しっぱなしにしておき、保存領域がさらに必要になったら、より大きい保存モジュールを買って、既存モジュールからセキュリティキーを抜いてコンピュータに挿し、暗号化されたファイルをコピーして新しいモジュールに移し、それからセキュリティキーをまた挿せばよい
そもそも物理セキュリティキーをパスキーとして使うのが良い考えなのか分からない。パスキーはパスワードの代替として意図されており、そのためには通常、「持っているもの」に加えて、ロック解除のための「知っているもの」または「本人性」を要求するスマートフォンやデスクトップが提供する2要素の性質が必要に思える。
物理セキュリティキーは、特定の高セキュリティ文脈では、パスキーに加えて使う二段階認証として残しておくほうがよいと思う。特に複製耐性が中核機能である場合はそうだ。その用途なら、第2段階に到達した時点で、すでにログインしようとしているアカウントは分かっているので、常駐キーは不要だ。また、常駐キーが提供するオートコンプリート機能は、パスキーUXにとって重要だと思う。セキュリティオタクしか使わない少数派のキーとの下位互換性を維持するために、それを犠牲にするのはおかしい。もちろん、常駐キーなしでもそのUXを維持できる方法があるなら構わない。
アカウントを作る世の中のすべてのサービスが安全でフィッシング不能だと仮定するより、自分が選んだパスワードマネージャーのほうがより安全だと信じるほうが容易だ。だからパスキーを使う頃には、すでにOSや、パスキーを所有するパスワードマネージャーなど、より安全な文脈で身元を確立している場合が多い。また、今もしくは最近までハードウェアキーをサポートしていなかった場所は、近い将来もサポートしない可能性が高い。一方で、パスキーソリューションは導入コストがソフトウェア対応程度で済むため、はるかに容易で、投資対効果も高い可能性がある。もちろん主にWebサイトに当てはまる話であり、パスキーはWebサイト向けの「標準化されたSSHキー」に近い。ハードウェアキーは、パスキーが入った保管庫を実際に開けるための2段階要素としてのほうが有用に見え、このときパスワードも併用されるかもしれない。ハードウェアキーの寿命はまだ少し残っていそうだ。GitHub、Gmailなどで標準の方法として使ってみると、パスキーログインのフローは本当に非常に良い。
ブラウザには、パスワードマネージャーが接続できる単純なHATEOAS APIがあればよく、WebアプリはブラウザをトリガーするHTMLを公開すればよい。そうすれば、パスワードマネージャーがユーザーをどう認証するか、つまりユーザーが望む方式を決め、そのWebサイトの秘密値を自動注入して、ユーザーは自動ログインされる。問題が起きたらメールによるリセットを使えばいい。「とても華やかなセキュリティ」を求めるWebサイトの立場として、より複雑な何かを望むのは理解できる。しかし、ユーザーが任意でより高いセキュリティレベルを有効化できるべきだ。たとえば、ほとんどのWebサイトは、パスワードマネージャーがランダムなパスワードを使う前提なら、単純なパスワードハッシュで十分だ。どのWebサイトでも実装でき、すべてのパスワードマネージャーが実装でき、一般ユーザーの99%における現在のパスワード利用より優れている。これを基本認証方式にすればよい。その後、TOTP、OIDC、公開鍵暗号などが欲しければ、サーバーが広告し、クライアントが任意で参加して認証を続ければよい。すべてのサイトとすべてのユーザーが最も安全な方法を使う必要はない。まずはセキュリティの基準線を上げやすくし、より強いセキュリティは徐々に選べるようにすればよい。
誰かが自分のハードウェアトークンを盗んでも、大きな問題には見えない。https://support.yubico.com/hc/en-us/articles/4402836718866-U...
パスワードを使う場合、認証インターフェースはキーボードであり、パスワードを入力している人が名乗っている本人だという実際の保証はない。パスワードは容易に伝達可能な知識に依存するため、さまざまな方法で抽出されうる。認証インターフェースを機器対機器へ移すほうがはるかによい。容易に伝達可能な知識が伝達されていないと仮定する代わりに、生物学的存在が認証デバイスを管理できると仮定するのであり、人間はもともとそうしたことにかなり長けている。認証チャネルの数を増やしてより堅牢にもできるし、リモートシステム認証に使う機器と生物学的存在との間の認証をFace IDのように制限することもできる。要するに、スマートフォンやキーのような機器がその人自身だとみなすほうが自然に感じられる。家ではNetflixのパスワードだけでなく、クレジットカード1枚も共有している。実用上の理由から、そのクレジットカード1枚は予備の鍵と一緒に置いてあり、家に必要な物を買う必要があれば誰でも取って使える。互いにカードを適切に使うと信頼しており、全員がPINを知っているが、非接触決済が一般的なのでほとんど必要ない。費用を追跡して後で精算し合うより、ずっと自然だ。おそらく違法で、銀行が知ればカードを停止するだろうが。ITシステムは、現実世界に近い形で動作しつつ、人間の行動に歩み寄る必要が切実にある。ITシステムに関わっているので大半の人は何とか耐えているが、技術に慣れていない人は、iPhoneのパスワードは何で、iCloudのパスワードは何で、Gmailのパスワードは何で、なぜWhatsAppにコードを入力しなければならないのかといった日常的な問題にも苦労している。実のところ、自分もMastodonは理解できていない。Mastodonのフィッシングには無防備だと思うし、画面に入力しろと出たら何でも入力してしまいそうだ。
パスキーは、その名のとおり、第2要素として開発されたFIDO2 U2F標準に寄生している。常駐キーは、PINを組み合わせたデバイス内の2段階認証向けであり、スマートカードの機能的な代替物である。誰か、おそらくAppleが、WebAuthnだけで唯一の認証要素として十分だと考えたようだ。常駐キーもなく、ハードウェア結合もなく、キーはiCloud経由で移動するが、デバイス上ではTouch ID/Face IDで保護される、というわけだ。そしてこれをパスキーとしてブランド化した。2段階認証そのものが目標ではない。目標は、フィッシング、総当たり、クレデンシャルスタッフィングに強く、しかもスマートカードほど実装が難しくないユーザー認証である。FIDO2はそれを実現している。Apple、Google、Microsoftの実装における問題は、認証サイトとユーザーのデバイスの間のプロトコルレベルのセキュリティが低いことではない。そのプロトコルは同じだ。問題は、サイトが今やユーザー個人のプラットフォームアカウントを信頼しなければならず、ユーザーが正しく設定しており、しかもプラットフォームが今後も常に正しく振る舞って、ユーザー個人アカウントへの攻撃に適切に対処してくれると信じなければならない点にある。
文脈を補足すると、YCの支援を受けたパスワードレス認証企業を運営しており、大規模組織にこれを導入してきた。パスキーが消費者向けパスワードレス認証の答えになるのは明らかに見えるが、企業環境にはまだそのようには反映されていないようだ
パスキーは消費者にとっては素晴らしい。iCloudのデフォルトバックアップやAirDropのような仕組みで資格情報を他のデバイスにバックアップし、自分で緊急アクセスを可能にすることを目的としているからだ。技術的には、この資格情報を共有されたデバイスはアテステーションを提供できない。アテステーションとは、鍵ペアがYubikeyやAppleデバイスのような特定の装置で生成されたという「証拠」のことだ。Yubicoのようなメーカーは、抽出不可能な鍵ペアと証明書をキーに組み込んだ状態で出荷し、この鍵ペアにアクセスする外部インターフェースが存在しないため、管理者はこれが本物のYubikeyだと高い確信を持てる。アテステーションがなく、鍵を共有できるなら、どこから問題が始まるかは明らかだ。企業は、AirDrop可能な資格情報が特権を持つ従業員アカウントへのアクセスを露出させるリスクを負いたがらない。Yubikeyにはデジタル窃盗のリスクが事実上ない。結局のところ、パスキーはデバイスやサーバーのロック解除にも使えない。FIDO2、さらに重要なのはOS開発者たちが、パスワードを完全に終わらせるにはまだ道のりが長いということだ。現在の企業市場の大半ではYubikeyがこの空白を埋めており、中にはハードウェアに数百万ドルを費やしたところもある。現状のパスキーは売りにくいだろう
Appleもパスキーをサポートし、AndroidとChromeも、Microsoftも、Yubikeyもパスキーをサポートしている。しかし、ユーザー検証のための認証手順や複製可能性のような機能・制約は大きく異なり得る。政府機関はパスキーをサポートしつつも、AAL2要件を満たすFIPS認証済み認証デバイスで提供される場合にのみ許可することがあり得る。少なくとも現時点ではAppleやGoogleから出てくるものではない。企業は、MDM管理製品が提供するソフトウェアや構成によって生成されたパスキーをサポートすると選択でき、Appleはこれに対するベータサポートを発表している。ただし、政府対市民サービスで特定のハードウェア認証デバイスを強制しようとすると、多くの苦労を招く可能性がある。市民に80ドル以上するハードウェアを買うよう説得するのも難しく、Web技術がユーザーの選択を中心に作られているため、WebAuthn APIやユーザー体験がユーザーの選択制限を助ける方向に最適化される可能性も低いからだ
セキュリティの観点から見ると、これは本当にひどい解決策だと思う
政府やApple、Googleのような企業にとって、デジタル生活を統制するのに都合のいい夢のような構造だ。パスワードを使えば一種の無状態に近く、個人のメールアカウントや何らかのアカウントを持ったまま国境を越えても、誰にもそのアカウントを持っていることを知られず、アクセス権を差し出すよう強要されたり、ハードウェアからアクセス要素を抽出されたり、デバイスへのアクセスを失ったとしてロックされたりしにくい。マスターキーなどがTPMやセキュアエレメントに保存されていたとしても、ある種の政府ならアクセスできるので、あとは年数と計算能力の問題にすぎない。多くの場合、それ自体が特定のアカウントの資格情報を持っている証拠にもなる。デバイスやOSのメーカーは、当局によってセキュア領域へのアクセス提供を容易に強制され得るし、自発的であれそうでなくあれ、そうなる可能性がある