パスキーに移す前に、iPhoneを失くしたときの復旧経路を作った

はじめに：パスキーを採用したいが端末をなくしたらどうするの？

情報漏洩のニュースが後を絶たない今日この頃、いかがお過ごしでしょうか。 何か自分でできることがないかを考えた結果、なるべくパスキーに寄せる運用を考えました。

パスキーはパスワードを覚えなくてよく、フィッシングにも強い仕組みです。私も個人のアカウントを少しずつパスキーへ移したいと考えていました。

ただ、ひとつ不安がありました。iPhone を失くしたら、自分のアカウントに戻れるのかという点です。パスキーの鍵は手元の端末やパスワードマネージャーの中にあるので、それを失ったときの戻り方を決めないまま移すと、ログインの手段を自分で減らすことになりかねません。

そこで、移行そのものより先に、紛失しても戻れる道筋を作ることにしました。この記事では端末を失っても別の端末や紙からアカウントに戻れる手順と置き場所の組み合わせを、「復旧経路」と定義します。この記事はその復旧経路を作った準備編です。各サービスの移行や紛失の訓練はまだ終わっていないので、続編で書きます。

※記事中のバージョン、料金、無料枠、仕様は、執筆時点（2026年11月）の情報です。

私が使っている端末は次の4つです。

• Windows 11 の PC
• iPhone
• iPad
• Linux（Ubuntu 24.04）の PC

以前から、パスワードは KeePass で管理し、データベースのファイル（.kdbx）は OCI（Oracle Cloud）上に自分で立てた Nextcloud で同期していました。

iPad でも、iPhone と同じく KeePassium で同じ .kdbx を使っています。

ゴール：端末間でパスキーを同期すればいい

今回のゴールは3つです。

1. パスキーが使えるサービスでは、パスキーを使う
2. iPhone を失くしても、アカウントに戻れる
3. 端末の間でパスキーを同期する

この記事で扱うのは、2と3を実現するための準備です。1は続編で扱います。

パスキーとは

パスキーはパスワードの代わりに使うログインの手段です。FIDO2/WebAuthn という標準に基づいていて、Web では WebAuthn の仕組みで本人を確かめます（passkeys.dev の用語集）。

仕組みは公開鍵暗号です。登録するときに公開鍵と秘密鍵の組を作り、サイトには公開鍵だけを渡します。秘密鍵は自分の側（端末やパスワードマネージャー）に残ります。FIDO Alliance は、パスワードのような「サイトと共有する秘密」がないと説明しています（FIDO Alliance: Passkeys）。サイトから公開鍵が漏れても、それだけではログインに必要な秘密鍵は手に入りません。

パスキーは作成したサイトやアプリに結びつきます。Google の開発者向けの解説によると、ブラウザと OS が、パスキーを作成したサイトやアプリでしか使えないようにしています。そのため、よく似た偽のサイトに誘導されても使われず、フィッシングに強い仕組みになっています（Google: Passkeys）。

ログインするときは、端末の画面ロックと同じ方法（指紋・顔・PIN）で本人を確かめます。指紋や顔の情報は端末から出ず、サイトに届くのは確認できたという結果だけです（FIDO Alliance: Passkeys）。

保存の仕方には2種類あります。

今回の構成は前者の使い方です。KeePassium はパスキーを KeePassXC と同じ形式でデータベースに保存します（KeePassium 2.0 released）。そのため、同じ .kdbx を Nextcloud で同期すれば、Windows・iPhone・Linux で同じパスキーを使えます。実際に使えたかどうかは後半の互換性テストの節に書きました。

ただ、同期できても、保存先をすべて失ったときに戻れるかという不安は残ります。そこで、重要なアカウントには物理キーも登録することにしました。物理キーは後者で、どこにもコピーされない代わりに、iPhone やデータベースとは別の戻り道になります。なお、Apple Account での物理キーは、パスワードに加えて使う本人確認の手段で、パスワードの代わりにはなりません（Apple: About Security Keys for Apple Account）。

フェーズの考え方

方針は復旧経路を先に作ってから移すことです。そのため、作業を次のフェーズに分けました。

並べ方の考え方は次のとおりです。

• 実際にパスキーへ移すのはフェーズ5です。その前に、戻り道としてバックアップ（0）、2段階認証の復旧（0.5）、各端末の準備（1〜2）を置きました。
• フェーズ3は本番前に必ず行うと決め、本物のアカウントではなくテスト用のサイトで、端末の間の相互利用を確かめました。
• Apple Account は物理キーで守ることにしました。Apple の公式の案内には物理キーを使う方法が書かれていますが、他社アプリに保存したパスキーでサインインできるかは書かれていないためです。そこで、フェーズ4（物理キー）をフェーズ5の前にしています。
• フェーズ5でもパスワードは消さず、強いランダムなものに変えて KeePass に残します。パスキーが使えないときの戻り道にするためです。
• 最後のフェーズ6で、iPhone なしで全アカウントに戻れることを実際に確かめてから完了とします。

0.5 と 1.5 は作業の途中で足したフェーズです。0.5 はパスキーへ移しても、パスキーに対応していないサービスや別のログイン手段として2段階認証のコードが残るため、1.5 は Linux でも同じデータベースを使うために足しました。

この記事で扱うのはフェーズ0〜3です。フェーズ4〜6は続編で書きます。

方式の比較：KeePass で統一

パスキーをどこに保存するかで、候補は3つありました。

Bitwarden は Windows でパスキーの保存先として登録できます（公式ヘルプによると、Microsoft Store 版などが必要です）。クラウドで同期してくれるので、自分でサーバーを持たなくて済みます。iCloud キーチェーンは、Apple の端末だけで完結するなら最も手間がかかりません。どちらも合理的な選択です。

それでも私が KeePass を選んだのは、次の理由からです。

• すでに KeePass と Nextcloud で同期する運用ができていて、データの置き場所を変えずに済む
• KeePassium は KeePassXC と同じ形式でパスキーを保存するため、Windows・Linux・iPhone で同じパスキーを使える（KeePassium の公式ブログによる）
• データベースが1つのファイルなので、USB メモリにコピーするだけでオフラインのバックアップになる

一方で、KeePassXC のパスキーはブラウザでのログインに限られると認識しています。Windows のアプリ内でパスキーのログインが必要になったら、Bitwarden をもう一度検討するつもりです。

Windows 側はこれまでの KeePass 2.x から KeePassXC へ切り替えました。KeePass 2.x にもパスキーのプラグインはありますが、使っている人の報告が少なかったので採用しませんでした。

復旧経路の設計

端末・ソフト・保存場所・復旧経路の全体像は次の図のとおりです。

.kdbx の置き場所

.kdbx の実体は次の場所にあります。

• Windows（Nextcloud クライアントの同期フォルダ）
• Linux（同じく同期フォルダ）
• OCI 上の Nextcloud
• オフラインの USB メモリ（毎月1回コピーする）

iPhone の KeePassium は Nextcloud から直接開くので、iPhone を失くしても .kdbx 自体は残ります。

iPhone なしで使える必要があるもの

.kdbx が残っていても、開くための情報がなければ戻れません。iPhone がなくても使えるようにしておくものを書き出しました。

• KeePass のマスターパスワード
• Nextcloud のログイン情報
• Apple Account のパスワード
• Authy のバックアップパスワード
• OCI コンソールのログイン手段（Nextcloud のサーバーを直すために要る）

このうち、マスターパスワード、Nextcloud、Apple Account、OCI コンソールの4つは、iPhone を使わずにログインできることを実際に確かめました。OCI コンソールの2段階認証が iPhone だけに依存していないことも、このときに確認しています。

復旧のためにロストしたら困る情報を紙に書く

書き出してみて気づいたのが、ログイン情報が KeePass の中にしかないと、復旧の手順が循環するという問題です。

たとえば、Nextcloud のパスワードを KeePass にしか保存していないとします。iPhone を失くしたうえで手元の PC も使えないと、.kdbx を取りに Nextcloud へ入るためのパスワードが、.kdbx の中にあることになります。

セルフホストはサーバー障害にも備える

Nextcloud を自分で立てている以上、サーバーが止まることも考えておく必要があります。Nextcloud が止まっても、Windows と Linux には手元のコピーが残ります。それでも、サーバー側のデータ消失や、OCI のアカウントや VM の停止に備えて、USB メモリへのバックアップを毎月取ることにしました。サーバー側の備えは後の節で書きます。

2段階認証（Authy）の扱い

パスキーへ移しても、2段階認証のコード（TOTP）はなくなりません。パスキーに対応していないサービスもあり、パスキー以外のログイン手段として TOTP を残すサービスもあるからです。私は Authy を iPhone と iPad で使っているので、Authy の復旧経路も考えました。

Authy の仕組みと、私が置かれている状況は次のとおりです。

• コードは Authy のクラウドに、バックアップパスワードで暗号化して保存される。新しい端末で復元するには、電話番号での認証（SMS か電話）とバックアップパスワードが要る
• iPhone を失くすと SIM も失うので、SIM（eSIM）を再発行するまで電話番号での認証を受けられない
• Authy にはコードを書き出す公式の機能がない
• Authy のデスクトップ版は 2024年3月19日に提供を終えている（Twilio の公式の変更履歴による）

そのため、当面は iPad が復旧の手段になります。iPad の Authy に iPhone と同じアカウントがすべて表示されることを確かめました。

あわせて、Authy の設定を2つ変えました。

1. 端末の追加（Allow Multi-device）を、iPhone と iPad の登録が済んだので無効にした。SIM を乗っ取られて、勝手に端末を追加されるのを防ぐためです。機種変更や紛失のときだけ有効にします
2. 「Use an existing device to approve a new device registration」を有効にした。新しい端末を追加するときに、登録済みの端末での承認が必要になります。私の場合は iPad が承認役です

KeePassXC と KeePassium は TOTP にも対応しているので、Authy から KeePass へ移す手もあります。ただ、パスワードと2段階認証のコードが同じデータベースに入ると、データベースが漏れたときに両方を一度に失います。当面は Authy を続け、パスキーへの移行が進んで TOTP の出番が減ってから判断します。

構築

Windows：KeePassXC とブラウザ拡張

1. KeePassXC を公式サイトからインストールする
2. Nextcloud の同期フォルダにある .kdbx を KeePassXC で開く（形式の更新は求められませんでした）
3. 「設定 → ブラウザ統合」を有効にし、使うブラウザを選ぶ
4. 同じ画面でパスキーの機能を有効にする
5. ブラウザに KeePassXC-Browser 拡張を入れ、データベースと接続する
6. KeePass 2.x はアンインストールせず、自動起動から外す

KeePass 2.x は残してありますが、同じファイルを2つのアプリで同時に編集しないよう、使わないことにしました。

iPhone/iPad：KeePassium

1. 「設定 → 一般 → 自動入力とパスワード」で KeePassium を有効にする
2. KeePassium で Nextcloud 上の .kdbx を開く
3. 自動入力のときの解錠を Face ID で行えるようにする（アプリ保護のパスコードと Face ID を設定し、マスターキーを記憶させる）

2段階認証の設定用 QR コードを読んだときに開くアプリは、iPhone の「確認コードを設定するアプリ」で Authy にしました。設定したあとは、iPad の Authy にも同じコードが出ているかを確かめるようにしています。

Linux：公式 PPA の KeePassXC

Linux の PC でも、同じ .kdbx を KeePassXC と Chrome で使えるようにしました。

Flatpak 版や Snap 版はブラウザとの連携に追加の設定が要るので、使いませんでした。Nextcloud を WebDAV でマウントする方法も、.kdbx には向かないと考えて避けました。

手順は次のとおりです。

1. KeePassXC を公式 PPA から入れ、keepassxc --version で 2.7.7 以上かを確かめる
2. Nextcloud のデスクトップクライアントを公式 PPA から入れ、自分の Nextcloud にログインする
3. 同期するフォルダを .kdbx のあるフォルダだけにする
4. KeePassXC で同期フォルダの .kdbx を開く
5. 「設定 → セキュリティ」で、操作がないまま10分たったときと画面をロックしたときに、データベースをロックするようにする
6. 「設定 → ブラウザ統合」を有効にし、Google Chrome を選ぶ
7. Chrome に KeePassXC-Browser 拡張を入れて接続する

確認：webauthn.io で相互に使えるか

本番のサービスで試す前に、パスキーのテスト用サイト webauthn.io で、端末の間でパスキーを使い回せるかを確かめました。

PC のブラウザで試したときの画面です。まず「Register」でパスキーを作成しました。

ログインのときは、KeePassXC-Browser がパスキーの候補を出します。PC で作った「test-from-windows」のほかに、iPhone で作った「test-from-iphone」も並んでいて、同期したパスキーを PC から選べることが分かります。

パスキーを選ぶと、ログインできました。

テストのあと、同期の運用ルールを決めました。片方の端末で編集したら、同期が終わるのを待ってから別の端末で開きます。衝突のコピーファイルができたら、どちらが正しいかを確かめてから統合します。

サーバー側の備え

Nextcloud のバージョン履歴

サーバーに入って調べたところ、Nextcloud のファイルのバージョン履歴は有効でした。.kdbx を保存するたびに古いバージョンが残っていました。

Nextcloud の Web 画面から .kdbx の古いバージョンをダウンロードし、KeePassXC で開けることを確かめました。「復元」ボタンは押していません。古いバージョンを取り出して開けることまでを確認した、という段階です。

OCI のボリュームにバックアップがなかった

調べてみると、Nextcloud を動かしている VM のボリュームに、バックアップのポリシーが設定されていませんでした。ブートボリュームにも、データ用のブロックボリュームにもです。ディスクの障害や操作のミスでボリュームを失うと、Nextcloud のデータを戻す手段がありませんでした。

.kdbx は複数の端末と毎月の USB バックアップで守れています。それでも Nextcloud 全体を守るために、OCI でボリュームのバックアップを設定しました。

• スケジュール：週1回、増分
• 時刻：毎週火曜 18:00 UTC（日本時間では水曜 03:00）
• 保持期間：14日
• 割り当て先：ブートボリュームとデータ用ブロックボリュームの両方

OCI の Always Free では、ブロックボリュームのストレージはブートとブロックを合わせて200GBまで、ボリュームのバックアップは合わせて5件までが無料です（OCI の公式ドキュメントによる）。

インスタンスの詳細画面の「ストレージ」タブでも、ブートボリュームを確認できます。

iPhone を紛失したときの手順

以上の準備をもとに、iPhone を失くしたときの手順を決めました。ただし、この手順はまだ訓練で通していません。手順3はこれから用意する物理キーを前提にしています。

1. 「探す」で紛失モードにし、必要ならデータを消去する
2. 2段階認証のコードは iPad の Authy で表示する。SIM（eSIM）の再発行を携帯電話会社に申し込む
3. 新しい iPhone で Apple Account にログインする（物理キーを使う）
4. SIM が戻ったら、iPad の Authy で端末の追加を一時的に有効にする。新しい iPhone で電話番号の認証とバックアップパスワードを使って Authy を復元し、iPad で新しい端末の登録を承認する。終わったら端末の追加を無効に戻し、紛失した iPhone を Authy の端末一覧から削除する
5. Windows か Linux のブラウザで Nextcloud にログインし、新しい iPhone 用のアプリパスワードを作る。KeePassium の「サーバーに接続」から WebDAV で .kdbx を開き、マスターパスワードを入力する
6. Apple Account から紛失した端末を削除する。Nextcloud の「設定 → セキュリティ」で、紛失した iPhone のアプリパスワードと端末のセッションを取り消す
7. iPhone の自動入力の設定をやり直し、パスキーでログインできるかを確かめる

これからやること

準備編はここまでです。残りは次のとおりです。

• フェーズ4：物理キーが届いたら PIN を設定し、1本を持ち歩き用、1本を自宅保管用にします。Apple Account ではセキュリティキーを2本以上登録する必要があります（Apple の公式サポートによる）。Microsoft、Google、メインのメールアカウントにも2本とも登録する予定です
• フェーズ5：メール、Apple・Microsoft・Google、金融、その他の順に移します。各サービスで回復コードを印刷して保管します
• フェーズ6：新しい iPhone のつもりで、Apple Account（物理キー）、Nextcloud、KeePassium の順にログインできるかを試します。Nextcloud が止まったつもりで、USB メモリのバックアップから .kdbx を開けるかも確かめます
• 残っている確認：最初の自動バックアップと復元のテスト、KeePassium の更新、iPhone の「パスワード」アプリと Chrome に KeePass にないパスキーやパスワードが残っていないかの確認、Authy に登録しているアカウントの一覧づくり、SIM の再発行の手順の確認

これらは続編で書く予定です。

参考資料

• FIDO Alliance: Passkeys
• passkeys.dev: Terms
• Google: Passkeys
• KeePassXC 2.7.7 released（パスキーの正式な実装）
• KeePassXC 公式 PPA（Launchpad）
• Ubuntu Packages: keepassxc（noble）
• Ubuntu Packages: nextcloud-desktop（noble）
• KeePassium 2.0 released（KeePassXC と同じ形式でパスキーを保存）
• Bitwarden: Storing Passkeys
• Twilio Changelog: End of Life (EOL) of Twilio Authy Desktop apps
• Apple: Set up iCloud Passwords on your Windows computer
• Oracle Cloud Infrastructure: Always Free Resources
• Apple: About Security Keys for Apple Account
• webauthn.io（パスキーを試せるデモサイト）
• Passkeys and Your KeePass Database: Current State
• Microsoft Expands Windows 11 Passkey Support with 1Password and Bitwarden Integration（Petri）
• KeePassXC 2.7.7 released with a passkey support（Techlore Discussions）