#1616: パスキーを解説、高齢者のために Apple が抱える難問、macOS 11.6.7 Big Sur が電子メール添付ファイルのバグを修正

お知らせするのが少し遅くなってしまったが、その理由の一つは私がメインに使っている Mac のすべてが今は macOS 12 Monterey を走らせているからだ。二週間ほど前、 Apple は他のアップデートとは別に、macOS 11.6.7 Big Sur を静かにリリースした。macOS 11.5 以来初めての珍しいことだが、今回のリリースノートには具体的な役に立つ情報が記されている。この macOS 11.6.7 Big Sur アップデートで、電子メールの添付ファイルを開こうとしてもそのファイルを開くために必要なアプリが既に動作中の場合には開かなかった macOS 11.6.6 での問題が修正されたという。この問題が起こると、必要なアクセス権がないというエラーメッセージがユーザーに示されていた。

TidBITS Talk ユーザーの chs は、M1 MacBook Air を macOS 11.6.7 へアップデートした後に印刷でトラブルに遭うようになった。どうやら原因はそれまでインストールされていた Rosetta がアップデートに伴って削除されてしまったことらしく、Rosetta をインストールし直すことで Brother プリンタドライバが有効化された。(ネイティブな Brother ソフトウェアにアップデートしても問題は解決したはずだ。) また、Will M も報告を寄せて、11.6.7 にアップデートした後で、彼が 4 月に 11.6.5 をインストールして以来初めて Time Machine が Time Capsule へのバックアップを完了したとのことだ。

簡単に言えば、まだ Big Sur を使っている人は、Software Update を使って macOS 11.6.7 にアップデートすれば電子メールの添付ファイルの問題が解決し、ひょっとすると Time Machine が止まってしまった問題も解決するだろう。ただし、Rosetta をインストールし直す必要が生じるかもしれないと知っておこう。または単純に Monterey へのジャンプを果たしてもよい。

討論に参加

ここ数週間ほど、私は今は亡き友人 Oliver の年配の父 JP とその妻 Gretel の手助けをするのに時間を割いてきた。彼らは、別な州にある介護付きアパートへの引っ越しの準備をしていた ("Oliver Habicht、53 歳ですい臓がんにより逝去" 26 September 2020 参照)。彼らは、栄養疫学と栄養人類学において国際的に著名な科学者であり、お二人とも加齢による不可避の身体的損傷は見受けられるものの、時には投薬や疲れのために反応が鈍くなることもあるが、心神的には全く正常でおられる。

私は、Oliver と必要な時には代役をする約束をしており、そして彼は JP と Gretel の技術サポート役を長年勤めてきたので、彼らがコンピュータの質問があると言ってきた時には喜んで手助けしようと思った。JP は 1987 年に私がまだ Cornell の３年生だった時の初めてコンサルタントをした顧客であり隣のブロックに住んでいたので、それがどんなものか、多かれ少なかれ、感じは分かっていた。当時私は、彼の家に行き、彼の Mac Plus 上の空のフォルダに名前を付けることで彼自身に残したメモを解読したり、各種のソフトウェアやハードウェア問題と向き合うのを手助けした。

彼らが引っ越しする予定の日まで数回訪問するのが精一杯であり、家中が引っ越し荷物で満杯であったので、焦点を当てるのは３つの分野とした：旧式のハードウェアを整理する、彼らのバックアップ戦略を合理化する、そしてより良いパスワード管理システムを考え出す。それぞれの場面で、私は Apple がこれらの問題に対処するために相応の努力を払ってきたという事実に気付かされたが、最近のハードウェア、オペレーティングシステム、そして技術を使っていない年配の Mac ユーザーには必ずしも役に立たないやり方になっていると思えた。

私は、70 台、 80 台、そして 90 台の人々について過剰な一般化はしたくない。何故ならば、この年齢層にいる高度に技術的で能力のある TidBITS 読者は沢山いるからである (我々の 100 才以上の人は言うに及ばずであろう - "George Jedenoff: 101 歳の TidBITS 読者" 17 June 2019 そして "102 才の George Jedenoff、自伝を出版" 26 August 2019 参照)。しかし、私が主流の一般大衆の中で観察した事からすると、高齢者がコンピュータ、タブレット、そしてスマートフォンに大きく依存する様になっているが、技術の世界での止むことの無い変化に戸惑っていることが見えてきている。でも、システムが必然的に難しすぎるという話ではない (改善の余地はあるが)；学ぶべきことが多過ぎ、そして余りにしばしば変更されるという話である。加えて、技術を何十年も使って来た人達は、沢山の旧式のハードウェアを身の回りに持っている傾向にあり、アップグレードと互換性の問題を更に複雑にしている。

古い格言 "壊れていないものを修理するな" に頼りたくもなる場合もあるし、それが本当な場合もある。しかし、技術の世界では、動かずにいるのは可能でない場合が多い。アプリの中にはただ年を経ただけで壊れてしまうものもあるし (例えば macOS 10.15 Catalina における 32-bit アプリ)、アップデートには新しい最低限のハードウェアとオペレーティングシステムを必要とするものもあるし、新しいそして改訂されたアプリには人を感動させずにはおかない能力が出現したりする。ある程度の変化は不可避であるが、変化が何年も延期された場合全ての事がより難しくなる。私が遭遇したことを挙げてみる。

古いハードウェア

私が最初に訪ねた時、JP と Gretel は箱一杯の雑多な付属品を持っていた - キーボード、マウス、USB ハブ、電源 - 私の名前の入った付箋のラベル付きで。(実際、付箋は至る所にあった。と言うのも、それ等は優秀なリマインダーだし、それに JP は昔からうっかり博士そのものであった。) 彼らはまた、古い MacBook Air, Mac mini, iMac, Dell PC タワー、そして PC サブノートブックを持っていたが、全てが彼らの重荷になっていた。どれも使われてはいなかったが、彼らはそれ等をリサイクルするのではなく保存してきた。その理由の一つは、古いコンピュータを新しいもの手にした後直ぐに戦列から外すのは難しいからである。いつ何時、何らかの理由で古いものが必要になるかも知れないではないか。それに、そのマシンが他の人にとっても価値があるかどうかに拘わらず、廃棄する前に内部ドライブを消去するのは重要である。

ドライブを消去しマシンを手放すのは私の役目であった。これらのマシンの年を考えると、その作業は思った以上に難しいこととなった。2010 MacBook Air は簡単であった：macOS Recovery で起動し、SSD を再フォーマットし、そして macOS を再インストールした。それを引き受けたいという友人まで現れた。しかし、私は iMac のハードドライブを消去する事は出来たが、それは 10.11 El Capitan をインストールするためには私の Apple ID が必要だと強要し、そしてそのインスタレーションは何度となく失敗に終わった。Mac mini はブートしたように見えたが、ディスプレイをドライブする所まで持って行けていないので、スクリーン上に何があるか、或いはドライブは消去されたのか見ることが出来ない。(何人かの人が助けの手を差し伸べてくれていて Target Disk Mode を勧めてくれているので、このプロジェクトに戻った時には試したいと思っている。) 私は未だ PC には手が届いていない - それ等はドリルで穴を開けリサイクルに回されることになるかも知れない。

要は、コンピュータを廃棄のために準備することに関して、私の様な経験、知識、そしてハードウェア (そしてコンピュータやスクリーンを動かし回るのに必要な筋力と柔軟性も) を持つ誰かが必要となるのであれば、それはとても多くの高齢者の手に負えるものではないであろう。廃棄するために Mac を綺麗にする作業はコンサルタントや IT アドミン以外の人がしょっちゅうやる様な類いのものではないので、それはとりわけ真実だと言える。

幸いにして、これは Apple が正しい方向に動いている場面の一つと言える。まず、同社はユーザーに古いハードウェアを下取りに出すかリサイクルするよう勧めている。次に、macOS 12 Monterey に始まって、Apple は Mac を譲渡用に準備するのをより易しくしている、かなり隠れた形でではあるが。

Monterey を走らせている Mac を新生活のために準備する手順を述べてみる (これは M1 Mac か Intel-based Mac で T2 セキュリティチップを持ったものを必要とする)。System Preferences アプリを開いて、しかし何時もやるようにそのウィンドウの内側で作業するのではなく、System Preferences > Erase All Content and Settings を選択し Erase Assistant を始める。Continue をクリックした後、それは全てのアプリを消去しそして全てのデータを消去する作業を進める。或いは、少なくとも、私はその様に想定する。何故ならば、私はそれに私の 27-inch iMac ブートドライブを消去させなかったので。

おっとっと、多くの高齢者はこれらの要件を満たす Mac は持っていないかも知れない。他の Mac に対しては、ブート時に Command-R を長押しして macOS Recovery を開始させ、そこから Disk Utility を使ってブートボリュームを消去し、それからクリーンバージョンの macOS を再インストールする。

より良いバックアップ

IT 専門家であった Oliver からの助言のあった長年の Mac ユーザーとして、JP と Gretel のお二人共 Time Machine ドライブをローカルのバージョン化されたバックアップとして、そして IDrive へのオフサイトバックアップを持っていた。彼らはオフサイトバックアップの重要性を理解していたが、IDrive に関しては不満があり、新しい Internet バックアップを欲しがっていた。彼らはまた、バックアップについての二つの良くある混乱の元でも苦闘していた：

• 彼らは、収容力のある Time Machine ドライブ上に他のファイルも保存出来るのか知りたがっていた。技術的には、可能であるが ("APFS の Time Machine ドライブで余った容量を使う方法" 20 May 2022 参照)、同じ物理ドライブ上にバックアップと元データを一緒に保存するのは良い考えではない。とりわけ、複数のバックアップシステムを維持していくやり方をきちんと理解していない人達にとってはそうである。
• IDrive の他に、彼らは Dropbox と Google Drive の追加ストレージに対して支払いをしており、そのストレージに対してバックアップ出来るのか知りたがっていた。繰り返しになるが、それは技術的には可能だが、両者が提供しているのはオンライン同期とストレージであって、バックアップではない。バージョン化とファイル削除に対する保護の付いたバックアップのためには、バックアップアプリが必要である。

話し合いの後、彼らが間もなくこの地を離れる事も考慮して、私は彼らをコンピュータ一台当たり年額 $70 でBackblaze に対して設定し、そして IDrive アカウント上の自動更新を止める手助けをした。彼らは又、Dropbox アカウントを無料レベルまで下げたが、Google One ストレージプランに関しては Gmail で十分な容量を確保するため一番下のレベルを保持した。

Backblaze は良いシステムである、とりわけ最初に設定したら後は忘れてしまえると言う意味では。それは高齢者には必須であり、彼らのバックアップを管理するためにより長い時間を費やす必要が無くなる。JP と Gretel が初めのうちに感じた主たる問題は、Backblaze の設定ペーンは Mac 上にありそして追加の管理やファイル復元のためには Web ベースのインターフェースを使わなければいけないという不連続性にあった。彼らは又、最初のバックアップでは湯沸かしポットは見つめていると中々沸かないと言う問題の犠牲となった。彼らの最初のバックアップは完了する迄数日かかった。

Apple はこれ迄 iOS と iPadOS に対するバックアップニーズに対しては iCloud Backup で対応してきたが、同社が Mac を有料の iCloud+ ストレージにバックアップする iCloud Time Machine を未だリリースしていない事に私は今でも驚いている ("将来の Apple オペレーティングシステムに対する５つの改善策" 19 May 2022 参照)。その様な内臓のシステムがあれば、より多くの Mac ユーザーが - 年齢に関係なく - 外付けドライブを買う必要が無くなるので彼らのデータを保護するようになるであろうし、そして、ローカルに Time Machine を既に使っている人に対してはオフサイトバックアップを提供出来る事になる。

共有パスワード

懸念の最後の分野はパスワードである。私には理由は分からないが、JP とGretel はこれ迄パスワードマネジャーに移行したことがない。それは一部には JP の特異なまでのメモ取り習慣と Gretel の卓越した記憶力のせいかもしれない (Backblaze に申し込む時、彼女は American Express のカード番号、有効期限、そして CVC コード迄全て支障なくソラで言えた)、何れにしろ、Gretel は一度限りのパスワードや事実を覚えられないかも知れないことは自覚しており、紙切れに手書きしたメモに頼っている。同様に、もっとデジタル化はしているが、JP は Word 書類を維持しており、そこに色々なサイトに対するパスワードを表現するコード化されたメモを残している。その内容は彼自身か彼を良く知る人しかそのパスワードを解き明かせないものとなっている。彼は最近その書類を家族と共有する様になったが、もっと良い解が存在することは承知していた。

高齢者をパスワードマネジャーに移行させるのは心配である。パスワードマネジャーは全ての面で優れているが - より速く、より簡単で、より安全で、より簡単に共有出来、そして複数機器の使用にも便利である - ウェブサイトにログインする全く新しい方法を学ばなければならず、それは大変そうに見える。もしパスワードマネジャーがその長所を超えてログインを大変にするのであれば、その価値以上に問題が多くなってしまう。

最初、私は彼らにバックアップに関してはより良いローテックの解決法をそして Google Chrome に彼らに代わってパスワードを保存させる方法を使って貰うよう手伝うのが良いのではないかと考えていた。しかし、JP は LastPass を設定してそれを家族と共有することを強く望んだ。我々はその様にし、そして私は彼に LastPass が新しく作成した或いはアップデートしたログインを記録する時どの様に聞いてくるかを示したが、これは長期的に見るとうまく行かないのではないかという危惧がある。Apple の Passwords と iCloud Keychain の方が現実的な選択肢だったのではないか、とりわけ Apple のアカウント復旧用の連絡先や Legacy Contacts を考えればそう思えるが、Apple の解は LastPass や 1Password にある共有機能に欠けている。この共有機能は、行動不能になったり、死去したりする親類のアカウントにアクセスする必要が生じるかも知れない家族にとっては魅力あるものとなっている。

究極の解は勿論パスキーであり、それはパスワードよりもより簡単でより安全であるが、高齢者は更にもう一つの新しい認証システムに慣れるのに苦労するのではないかと私は心配になる ("パスキーがパスワードよりシンプルかつセキュアなものになる理由" 27 June 2022 参照)。もし JP と Gretel が彼らの世代のなにがしかの代表であれば、パスキーの生体認証の側面は高齢者に対しては有効な解ではないかもしれない - Touch ID は彼らのどちらでもうまく行かないし、それに私は指紋スキャンの精度は年齢と共に下がっていくという説を見たことがある。その理由は、皮膚はより平らになり弾力性を失うからである。Face ID にはその様な問題は生じないであろうが、Apple 機器の多くが Touch ID に依存し続けている。

と言う訳で、Apple は、パスワード管理、パスキー、そして復旧選択肢を携えて正しい方向に向かっているように見えるが、対応可能なハードウェアを持たない人、或いは認証の新しい形態が過度に難しく感じる人に対しては手遅れなのかも知れない。

討論に参加

Apple が自社バージョンのパスキーを発表した。パスキーはパスワードに代わる業界標準の一つで、パスワードに比べてより高いセキュリティと乗っ取りに対する保護を提供しつつ、それと同時にほとんどあらゆる面でパスワードよりはるかにシンプルなものだ。

パスキーのコンテンツをあなたがタイプ入力したり管理したりすることは決してなく、パスワードのみ、またはパスワードと二要素認証を組み合わせたログインを使っている特定のウェブサイトのアカウントをあなたがアップグレードしようとする際に、パスキーが生成される。パスキーは、パスワードにまつわる数多くの重要な弱点を克服する：

• 個々のパスキーは唯一無二で、これは常にそうなる。
• すべてのパスキーはあなたのデバイス上で作成され、ログインの際にその秘密鍵部分があなたのデバイスの外へ出ることはない。(あなたの複数個のデバイスの間でセキュアにパスキーを同期したり、それを他の人と共有したりすることはできる。)
• パスキーは強力な暗号化アルゴリズムによって作成されるので、推測されたりクラックされたりする恐れのある“弱い”パスワードに類した心配は無用だ。
• サイトが保存するのはあなたのログインに対応するパスキーの公開鍵部分のみであって、あなたの身元を認証する秘密鍵部分は保存されないので、あなたの認証情報をウェブサイトが漏洩することは不可能だ。
• パスキーはそれに付随した正当なウェブサイトにおいてのみ出現するので、攻撃者がフィッシングによってあなたからパスキーを盗み取ることは不可能だ。
• パスキーが盗まれることはないので、パスキーを変更する必要がない。
• パスキーはもともと二個の異なる部分を含んでいるので、二要素認証を必要とすることはない。
• 去年一年をかけて開発者たちとテストを実行した上で、Apple はパスキー対応を iOS 16、iPadOS 16、macOS 13 Ventura、および watchOS 9 に組み込んだ。これらのオペレーティングシステムは今年の 9 月か 10 月にリリースされる予定だ。これらのオペレーティングシステムは既存のパスワードやその他のユーザーキーチェーン内の項目と同様にパスキーを保存して、それをデバイスのパスワードやパスコード、Touch ID や Face ID で保護する。また、パスキーは iCloud Keychain を使ってあなたのデバイスの間でセキュアに同期され、そこでは終端間の暗号化が用いられる。Apple がパスキーやその他の iCloud Keychain データにアクセスすることはない。

おそらく何より素晴らしいのは、Apple がパスキーを既存の広くサポートされた業界標準である W3C Web Authentication API、つまり WebAuthn の上に構築したことだ。WebAuthn は World Wide Web Consortium と FIDO Alliance によって作られたもので、FIDO Alliance はフィッシングの有効性を減らし、乗っ取りを防ぎ、ユーザーのために認証のシンプルさを増そうとするアプローチを長年開発し続けている業界団体だ。Apple、Amazon、Google、Meta (Facebook)、Microsoft はすべて FIDO に加盟しており、大手の金融機関、クレジットカードネットワーク、半導体やハードウェアのメーカー各社も加盟している。

多くのウェブサイトやオペレーティングシステムは既に WebAuthn に対応しており、有名どころでは Yubico が作っているもののようなハードウェア鍵を通じて実装されている。あなたがウェブサイトを訪れて、セキュリティ鍵を通じてログインする方法を選べば、ハードウェア鍵を挿入するかまたは鍵の上のボタンを押すかすると、ブラウザとオペレーティングシステムとハードウェア鍵とがすべて互いにやり取りすることでログインが完了する。このようなハードウェア鍵の機能を直接オペレーティングの中へ移行させようとするのがパスキーだ。つまり、余計なハードウェアは必要でない。Apple によれば、既にハードウェアベースの WebAuthn に対応しているウェブサイトならばほとんど余計な努力なくパスキーに対応できるはずだという。

説明を始める前に、Apple がパスキーを小文字で "passkey" と書いていることに注目したい。これは、パスワードやパスコードやパスフレーズと同じような一般的な概念として受け取ってほしいという試みなのだろう。Google、Microsoft、その他の会社もこれと互換なテクノロジーを提供するはずだし、同様の総称的名称をそれぞれのパスキーに付けることだろう。新しい用語が混乱を招くことがあるのは確かだが、"passkey" ならば口にしやすく、技術用語を並べた "multi-device FIDO credentials" のような語呂の悪い表現よりずっと好ましい。

では、パスキーがどのように動作するのかを見て行こう。

パスキーは公開鍵暗号方式の利点を日々のログインに持ち込む

パスキーは公開鍵暗号方式に依存する。これはもう 30 年近く前から TidBITS の記事で扱ってきたものだ。公開鍵暗号方式では、暗号化アルゴリズムがシークレットを生成し、それが２つの部分に分割される。片方が秘密鍵で、これがあなた以外に明かされることはない。もう片方が公開鍵で、こちらは秘密鍵を晒すリスクなしにいかなるやり方でも共有することができる。この公開鍵暗号方式が、セキュアなウェブと電子メールとターミナル接続、iMessage、および他の多くの規格やサービスを支えている。

誰かの公開鍵を手にした人は誰でも、それを使ってメッセージを暗号化することができ、それに対応する秘密鍵を持っている人のみがそのメッセージを復号化することができる。秘密鍵を持っている人は、さらにそれを補う働きとして、その秘密鍵を使ってメッセージに“署名”を入れることができ、それは実質的に「私がこのメッセージを送ったことを認証します」と言っていることに相当する。決定的に重要なのは、公開鍵を持っている誰もが、その署名を作成したのがその秘密鍵の所有者のみであると確認できることだ。

パスキーは公開鍵と秘密鍵の組にいくらかのメタデータを結び付けたものだ。例えば、それが作成される対象となったウェブサイトのドメインといったメタデータだ。パスキーでは、ログインを認証するためにそれを作成したデバイスの外に秘密鍵の部分が出ることはなく、ウェブサイトの方はそれに対応する公開鍵の部分のみを取り込んで、そのユーザーのアカウントの一部としてそれを保存する。

パスキーを使うためには、まず最初の手順としてウェブサイトで、またはアプリの中で登録をする。サイトで二要素認証 (2FA) にサインアップしたことのある人は、ここの手順に馴染みがあるはずだ。つまり、既存の認証情報でログインしてから、2FA を有効にし、テキストメッセージを受け取るかあるいは QR コードをスキャンするかして、認証アプリまたは (iOS 15、iPadOS 15、または macOS の Safari 15 では) キーチェーンの中へその情報を入れて、受け取ったことを確認する。

パスキーにおいては、そこの手順が違っている。パスキー認証を提供するウェブサイトにログインすると、アカウントのセキュリティセクションまたはパスワードセクションで認証をアップグレードするオプションが提供される。そのウェブサイトがまず登録メッセージを生成し、Apple のオペレーティングシステムがそれを解釈するが、これはあなたの目には見えないところで起こる。それへの応答として、あなたのデバイスが公開鍵と秘密鍵の組を作成し、セキュアな形でローカルに保存してから、公開鍵の部分をウェブサイトに送信する。するとそのサイトはオプションとしてそれに対する“チャレンジ”を送り返し、デバイスがそのことを表示してあなたに登録を確認させることができる。

その後そのサイトを再び訪れると、あなたにログインが表示されるとともに、iPhone や iPad では QuickType バーにパスキー項目が示され、macOS の Safari ではポップアップメニューで示される。いずれの場合も、既存の状況でパスワードや認証コードを扱うやり方とよく似ている。それらのログイン補助と同様に、パスキーの使用は Touch ID、Face ID、あるいはそのデバイスのパスコードによって認証することになり、そのどれによるかはあなたの設定に応じて決まる。

舞台裏では、パスキーによるログインを求めたあなたのリクエストへの応答として、そのサイトが保存していた公開鍵を使って“チャレンジ”リクエストを生成する。するとあなたのデバイスは保存していた秘密鍵を使って応答を構築しなければならない。そもそもあなたがパスキーによるログインを求めた時点であなたは自分の身元保証を済ませているので、チャレンジリクエストが届いた時点でデバイスはそのパスキーの秘密鍵にアクセスできるようになっており、新たな認証手順の必要なくチャレンジに応答できる。それからサーバが保存していた公開鍵と突き合わせてデバイスからの応答を認証し、あなたのみがアクセスを許すべき正しい人物だという確認を得る。もしすべての裏付けが取れれば、ウェブサイトがあなたのログインを受け入れる。

パスキーは二要素認証を置き換える存在であり、そのことの理由をここで考えておくべきだろう。一見したところ、直感に反するように見えるからだ。いったいなぜ、たった１つのコードをデバイスに保存しておくだけで決定的な確認ができるのだろうか？ セキュリティ要素を複数個備えておくことの解釈は通常、「あなたが知っている何かと、あなたが持っている何かと、あなたが何か」という風に形容される。実は、パスキーにはそのうち少なくとも２つが組み込まれているのだ：

• あなたが知っている何か： 一般的にパスワードと思われているが、本当は“知っている”ものとは固定された情報であなたが知っているものなら何でもよい。パスワードマネージャがランダムに生成した 20 文字のパスワードがあったとして、あなたはこれを“知っている”と言えるのか？ 答えはイエスだ。それは入力した通りに取り戻すことが可能だからという意味においてだ。
• あなたが持っている何か： パスキーはデバイスの中にあるので、パスキーのロックを外せたならばあなたがそのデバイスを持っていることが証明される。パスキーがなければ、デバイスを持っていることにならない。
• あなたが何か： パスキーは必ずしも Face ID や Touch ID を使った生体認証を必要とはしないけれども、それは確かに一つの選択肢だ。Apple は常に Face ID や Touch ID に代わる最終手段としてデバイスのパスコードを使えるようにしているので、予備の手段を持たない生体認証専用のデバイスと比べて“あなたが知っている何か”との間の境界線は曖昧になる。

ここで少しだけ利点について考えてみよう。パスキーを使えば：

• フィッシングへの耐性がある： パスワードや認証コードと同様に、あなたのデバイスはそのパスキーに関連付けられたウェブサイトの特定のドメインにいる場合にパスキーを QuickType の中で、またはポップアップメニューの選択肢として表示するのみだ。パスワードであり得るように攻撃者があなたを騙して偽りのサイトにパスキーを入力させるということは不可能だ。
• 盗まれた鍵を他のアカウントで再利用することを防ぐ： 関連付けられたウェブサイトごと個々に別々のパスキーがあるので、たとえそのサイトでセキュリティ漏洩があったとしても、盗まれる可能性があるのは公開鍵のみだ。その公開鍵では、別のサイトで盗人があなたとしてログインしようと思っても役に立たない。ログインの際のチャレンジに答えるための秘密鍵がないからだ。
• 訪れたサイト上で悪意あるコードを注入されることによる被害を阻止： 悪意ある人物が悪意ある JavaScript を無害なページに“注入する”ことはよくある。メジャーなウェブサイトでさえもこれは時々起こってきた。たいていはセルフサービスの広告ネットワークを通じて自動的に配布される悪意ある広告が甘い検査を通り抜けてしまうことで起こる。ウェブサイトの HTML やスクリプトに対する単なるフロントエンドの攻撃ならば、たとえ攻撃を受けてもあなたのデバイスのパスキーを要求する正当なチャレンジリクエストを作ることができない。攻撃が成立するためにはそのサイトのサーバコードに対するバックエンドの攻撃も同時に成立させてアカウント情報を手に入れなければならず、その場合にはいずれにせよサーバのデータ全体が攻撃者の手に落ちた状態になることだろう。
• 推測や身元検索、力尽くの攻撃を阻止： 個々のパスキーに極めて複雑なシークレットが含まれているので、攻撃者が推測や総当たり攻撃でサイトへのアクセスを得ようとする方法は成功しない。
• 2FA 乗っ取りがなくなる： パスキーには第二の要素がないので、2FA 乗っ取りや傍受、サイトのなりすましやフィッシングその他を使って第二の要素を入手しようという攻撃がそもそもあり得ない。

Apple は個々のパスキーをあなたのキーチェーンの中の単なる新たな項目として保存する。あなたが iCloud Keychain を有効にしている場合には、パスキーがあなたのすべてのデバイスに同期される。(iCloud Keychain は Apple ID で二要素認証 (2FA) が有効になっていることを必要とする。ユーザーアカウントで 2FA が内部使用されている状態をパスキーが置き換えることになるのか否かについて Apple はまだ何も明言していない。)

AirDrop を使ってパスキーを他の人と共有することもできる。AirDrop を使うということはその相手の人物の近くにいなければならないことを意味し、そのことがセキュリティの一つの要素となる。情報は終端間の暗号化を通じて共有されるので、秘密鍵やその他のデータが傍受されるリスクなしに渡される。Apple は AirDrop 共有のオプションがあるということ以上の詳細をまだ明かしていないので、他にも条件やセキュリティレイヤーがあるかもしれない。

パスキーはパスワードと第二要素の両方ともを置き換えるので、もしも自分の Apple ID アカウントから締め出されたり、あるいは登録されたデバイスすべてを失ったりすればどうなるのかと心配になるのも自然なことだろう。Apple は、Apple ID アカウントへのアクセスや iCloud 同期されたデータを復旧するためのいくつかの手続きを用意している。Apple ID アカウントを復旧するには、Apple のアカウント復旧手順を使うか、またはアカウント用の Recovery Key を使う。iCloud データについては、友人や家族の手による復旧システムiCloud Data Recovery Service を有効にしてある場合には、それを使ってアクセスを再有効化できる。アカウントへのアクセスが復旧したら、その後で Apple が用意した追加の手順を踏めば、iCloud Keychain の項目を取り戻すことができる。その手順の中には、登録された電話番号に SMS を通じてコードが送られることや、iCloud 同期されたデバイスの一つにデバイスのパスコードを入力しなければならないことが含まれている。

これらはすべて、インターネットにアクセス可能なあなたのアカウントに対する攻撃が成功する可能性を著しく減らすことに繋がる。でもそれだけではない。Apple は決してまたもう一つ新たな“壁に囲まれた庭”を築こうとしている訳ではない。そうではなくて、パスキーとは業界全体の広範な努力の一部であり、Apple によればその実装が互換になるものだという。

パスキーは業界標準であって、独自仕様のテクノロジーではない

Apple は自社のパスキー対応をさきほども述べた WebAuthn 標準の上に構築した。この標準が公開鍵暗号方式によってウェブベースのログインを実装するサーバ側の方法を記述している。FIDO はクライアント側の標準も作っており、自らのプロトコルと WebAuthn の組み合わせを FIDO2 と呼んでいる。Apple は自社独自のクライアント側の方式を標準的な WebAuthn と互換になるように開発しており、他の会社が運用するパスキーに相当するものとも互いに互換になるはずだと言っている。Google、Microsoft、Apple は 2022 年 5 月に共同声明を発表して、このやり方に同意すると約束した。

Apple が開発者向けに示したパスキー入門ビデオの中で、エンジニアの Garrett Davidson は Apple が互換性を約束していると強調して、こう述べた：

私たちは FIDO Alliance 内部で他のプラットフォームベンダーと共同して働き、パスキーの実装がクロスプラットフォームで互換であり、可能な限り多くのデバイスで動作できるようにすることを目指しています。

それから彼は Apple デバイス上のパスキーを使って PC 上のウェブサイトにログインするところを実演して、QR コードを使えば既存のデバイスやエコシステムに接続されていない他のデバイスやブラウザの上でも自分のアカウントにパスキーでログインできることを示した。

あなたが自分の iPhone でパスキーによる認証を使って誰か他の人の PC 上にあるパスキー対応アカウントにログインしようと思えば、次の手順を踏めばよい。ログインの最中に、ブラウザの中でパスキーを入力したりその他の認証方法を使ったりする代わりに、デバイスを追加する方法を選ぶことができる。そのウェブサイトのサーバが QR コードを生成し、そこには一回限りのパスワード２個の組が含まれている。これはそのログインのためだけに生成され、次のステップで追加認証のために使われる。(ブラウザが開いているデバイスは、オペレーティングシステムとデバイスがパスキーに対応しているものであれば何でもよい。認証を担うデバイスの方は Apple ないし他の会社によって限定を受けることがある。例えて言えば Mac 上の Safari の中で iPhone を使って Apple Pay の確認ができるけれども Touch ID 搭載の Mac を使って iPhone からの Apple Pay を確認することはできないのと同じことだ。)

この例での PC も、サーバと直接接続して認証できるために必要な情報を含む Bluetooth メッセージを送信し始める。iPhone で QR コードをスキャンすれば、iPhone は終端間で暗号化されたプロトコルを用いて、その QR コードに示された鍵で PC のウェブブラウザとの間にトンネルを作成する。(ちなみにこの暗号化された接続は Bluetooth プロトコルではないけれども、データは Bluetooth 上でトンネルされる。Bluetooth 自体は必要な暗号化強度を備えていない。)

この Bluetooth 接続が 帯域外の 要素、つまり認証を提供しているデバイス (今の場合には iPhone) に向けてその PC が提供していない詳細情報を提供することによって、追加のセキュリティと検証が提供される。ウェブページはフィッシング攻撃によって欺かれることがあり得るので、この Bluetooth 接続がデバイスからデバイスへの裏ルートを通じて重要な情報を伝える：

• サーバのアドレス： QR コードが iPhone に対してパスキー接続のために実際にどのサーバ (あるいはサーバのリスト) に接続可能かを伝えることはない。これにより、ブラウザが悪意ある情報を提供することが防げる。
• 鍵の認証： QR コードの中にある鍵を使って Bluetooth 経由の終端間暗号化された双方向セッションが成功裏に成立したという事実により、その QR コードが確かにブラウザが発行したものであること、iPhone がスキャンしたものと同一の QR コードであることを、iPhone と PC の双方が確認できる。(Apple はまだこの段階に関する完全な詳細を発表していない。オペレーティングシステムがブラウザのリクエストに応じて QR コードを生成するのは明らかだが、ブラウザが Bluetooth 接続を傍受することはできない。だから、フロントエンドの攻撃で悪意ある QR コードを表示しても攻撃は成立しない。PC と iPhone が間にブラウザを挟まずコミュニケーションするからだ。)
• 近接性： 短距離の Bluetooth 接続を使うことで、その PC と iPhone が互いに近くにあることが実証される。

このように幅広いデバイスとプラットフォームの互換性があることで、自分のアカウントに他の人のデバイスを使ってアクセスする際にも弱い手法に格下げすることなくパスキーのセキュリティとシンプルさを同等に享受することが可能となる。弱いログイン方法に格下げを強制されることがあったならば、必ずや悪意ある者がそこを突いて、フィッシング、ソーシャルエンジニアリング、その他の傍受手法を使ってくることだろう。(第二要素として SMS テキストメッセージを使う方法と確認コードを使う方法を比較すれば、弱い方の予備的なやり方が攻撃を招いた事実があると分かるだろう。) 実際、パスキーのみが使えるという状況に到達するまでの間はパスワードによるログインを使えるようにしておく必要があり、それが脆弱な点であり続けるだろう。

パスキーの実装が展開しつつある段階では、使い勝手の面での問題があるかもしれない。でも、広範囲にわたる問題があるとは思えない。例えば、WebAuthn サーバのコンポーネントのどれかにアップデートが必要となったり、あるいは Apple が自社のフレームワークにより多くのエッジケースへの対策を盛り込んでさまざまの事例に対処しなければならなかったりということはあるだろう。

でも想像してみよう。どんな新しいオペレーティングシステムの走るどんなデバイス上でも、どんなブラウザを使っても、わざわざパスワードを作成し記憶し保護する手間を掛けたりせずに、いつでもウェブサイトにセキュアにログインできる、そんな世界を。考えただけでもくつろいだ気分になれるではないか。

まだ答が与えられずに残っている主要な疑問点は、異なるエコシステムの間でパスキーがどの程度移植可能かということだ。iOS と Android と Windows を使っていて、そのどれかで生成したパスキーを他のものでも共有して使えるのか？ Apple がパスキーの AirDrop 共有手法を開発したところを見れば、私としては FIDO の幅広い互換性がオペレーティングシステム間のパスキーの共有も含んでくれるだろうと期待したい。

近接性を通じたセキュリティへの回帰

もう何十年も前に複数ユーザーのコンピューティングシステムに保護が必要となって導入されて以来、パスワードは不安を伴うセキュリティ上の妥協を世にもたらしてきた。パスワードはそもそも不完全なものであって、物理的に近くにいることが保護の第一段階であった時代の遺物とも言える。近くにいるかどうかは、もはやインターネットによって意味をなくしてしまった。

パスワードシステムの弱点のいくつかに対処しようとする努力の中で生まれたのが二要素認証 (2FA) で、これはパスワードに加えて何かを結び付けることを要求し、あなたがコンピュータ、サービス、またはウェブサイトにログインする権利を持っていることを証明するため何らかのオブジェクトを持っていること、またはその近くにいることを要求した。けれども 2FA はそもそもアカウントのパスワードからスタートしたものであり、利用する第二の手法自体もまた攻撃やフィッシングの対象となり得るものであるので、やはり壊れた壁に一時的に継ぎ当てする手法でしかない。

パスキーはパスワードを置き換える現代的方法であり、標準的なアカウントログインを保護するセキュリティの壁を一から再構築するものだ。ここでは近接性が、パスキーを保存したデバイスという形で、アカウントの乗っ取りや傍受を減らすための強力なツールとなる。パスキーは何か恐ろしい革命的なものに見えるかもしれないが、実際には今より安全で、ある意味ではどこか旧式なところもある。ターミナルにアクセスできることがそれを使う権利を認められることの証明を提供していた、はるか昔へと逆行するようにも見えるからだ。

討論に参加