パスキーの課題は「復旧」が難しいだけではない ―― 構造的欠陥「Authorization Gap」という視点
はじめに
Ars Technicaに掲載された記事
「Passkey technology is elegant, but it's most definitely not 'usable security'」
この記事では、パスキーの最大の弱点として
「デバイス紛失時のリカバリ（復旧）の難しさ」
が挙げられています。
確かに、一般ユーザーにとって
「鍵を失くしたらアカウントごと消える」
というプレッシャーは、ユーザビリティ上の大きな障壁です。
しかし、セキュリティアーキテクトの視点から見ると、パスキーには
「使い勝手」という表面的な問題以上に深刻な、構造的な欠陥
が隠れていると考えています。
それが、私が提唱している
「Authorization Gap（認可の乖離）」
です。
1. 「身分証」と「契約書」は別物である
一般の方に分かりやすく説明すると、こういうことです。
-
Identity（身元）は「運転免許証」:
「私は確かに本人です」と証明する。 -
Intent（意思）は「契約書へのハンコ」:
「私はこの内容に同意し、実行します」と表明する。
パスキーの問題は、
「免許証を見せただけで、白紙の契約書にハンコを押したことにされている」
ような状態が、システムの裏側で起こり得ることです。
2. 具体的なシナリオ：ログインしたつもりが「送金」に
「認可の乖離（Authorization Gap）」 が引き起こす、
身近な恐怖のシナリオを考えてみましょう。
【シナリオ：銀行の自動音声ガイダンス】
あなたのスマホに銀行から電話がかかってきます（あるいは自分からかけます）。
音声が流れます：
「日本語で進める場合は『1』を、中国語の場合は『2』を押してください」
あなたは日本語で進めたいので、迷わず 『1』 を押します。
しかし、実は銀行のシステム側では、全く別の音声が流れていました：
「100万円の送金を承認する場合は『1』を、拒否する場合は『2』を押してください」
これが 「ロジックのすり替え（Logic Mapping）」 です。
あなたは「言語を選んだ（意思 A）」つもりなのに、
システムには「送金を承認した（意思 B）」と伝わってしまう。
パスキーという「最強の本人確認」があるからこそ、
システム側は一切の疑いなく送金を実行してしまいます。
3. 証拠能力の逆転：あなたが「共犯者」にされる
これが最も恐ろしい点です。
もし上記の被害に遭って銀行に文句を言っても、銀行側はこう答えるでしょう。
「記録を見てください。あなたのデバイスで、あなた自身の指紋（または顔認証）を使って承認されています。これは、あなたが自分の意思でボタンを押したという動かぬ証拠です」
強固なセキュリティが、「本人が騙された」という事実さえも塗りつぶし、
あなたを「不正操作の実行犯」に仕立て上げてしまう。
これが、私が警鐘を鳴らす 「フォレンジックの悪夢」 です。
4. 解決策：あえて「面倒くさい」を作る
これを防ぐには、ログインとは別の 「意思のダブルチェック」 が不可欠です。
-
内容の復唱:
「100万円送金します。よろしければ『100』と入力してください」のように、操作内容と入力内容を直接結びつける。 -
色の違うボタン:
ログインは「青」、送金承認は「赤」のように、視覚的に「今は重要な局面だ」と脳にスイッチを入れさせる。 -
「間（ま）」を置く:
指紋認証の直後にすぐ完了させるのではなく、「この内容で本当に良いですか？」という確認画面をあえて挟む（意図的な摩擦）。
まとめ
パスキーは、私たちが「パスワード」という遺物から脱却するための素晴らしい第一歩です。
しかし、Ars Technicaが指摘するように「復旧」というUXの問題を解決するだけでは不十分です。
「誰であるか」を特定する技術と同じくらい、「何をしようとしているか」を正しく検証する技術、
すなわち Authorization Gap を埋める設計 に注力しなければ、
私たちは利便性と引き換えに、
より深刻なアイデンティティの脆弱性を抱え込むことになるでしょう。
📅 【連載】
Discussion