バックアップが本当に必要になる日：Senvra がプライベートデータを取り戻す仕組み

本当にバックアップが必要になる日は、たいてい良い日ではありません。

iPhone を失くした。アプリを誤って削除した。端末が起動しなくなった。そんな時、以前設定画面で見た緑色のチェックマークには、ほとんど意味がありません。大切なのは、手元のファイルを今も検証できるか、そして実際にデータを取り戻せるかです。

だからこそ、バックアップだけで一つの記事を書く価値があります。プライベートデータでは、「バックアップがある」だけでは足りません。Senvra の外へ出た後も秘密が守られ、破損を見逃さず、緊急事態の前に復元を試せる必要があります。

復元に必要なものを2つに絞りました

Senvra のバックアップを作成した後、保管するものは次の2つです。

1. 暗号化された .senvrabackup ファイル
2. そのファイル専用に生成された Backup Key

追加の Backup Password はありません。元のスペースを開くパスワードを覚えている必要もありません。

Backup Key は UUID ではなく、時刻、端末モデル、スペース情報から作る文字列でもありません。システムの安全な乱数生成器で作られた20個のランダムバイト、つまり160ビットのエントロピーを持ちます。5組の8桁16進数で表示するのは、読みやすく照合しやすくするためだけです。

新しいバックアップを作るたびに、新しい Backup Key が生成されます。その鍵はそのバックアップだけを担当します。

flowchart LR
    V[現在のスペース] --> B[新しいバックアップを作成]
    B --> F[暗号化ファイル<br/>.senvrabackup]
    B --> K[独立した Backup Key<br/>160ビットのランダムエントロピー]
    F --> R[復元]
    K --> R

これは二要素バックアップではなく、私たちもそのようには表現しません。強く予測不能な暗号学的秘密が1つあります。境界は明快です。ファイルだけでは開けず、Key だけではデータがありません。両方を同じ人に渡せば、バックアップを開かれる可能性があります。

だから重要なのは、もう一つパスワードを考えることではなく、ファイルと Key を別々に保管することです。

Backup Password をなくした理由

最初に思いつく案は、Backup Key に Backup Password を追加することでした。入力欄が一つ増えると、安全層も一つ増えたように見えます。

しかし、バックアップは日常のログインとは失敗の仕方が違います。ログインなら再試行や再設定ができることがあります。何年後かに秘密を一つ忘れたオフラインバックアップには、助けを求めるサーバーがありません。秘密が増えるたび、唯一残ったコピーを永久に使えなくする経路も増えます。

そして、ランダム生成された160ビットの Backup Key は人間のパスワードではありません。辞書語、誕生日、キーボード配列の癖がなく、ユーザーが強いパスワードを考えられるかにも依存しません。攻撃者が向き合うのは一般的な短いパスワードではなく、2^160 のランダム空間です。

そこで私たちは意図的に選びました。複雑そうに見せるための人間用パスワードは追加せず、バックアップごとの強いランダム Key を使い、復元に必要な秘密を一つにする。

操作は軽くなりますが、保管責任は軽くなりません。Senvra は Backup Key の復旧可能なコピーを保持しません。保存したことを確認してから作成を続けます。Key を失えば、Senvra にもそのファイルは開けません。

Space Access Key と Backup Key は別の扉を開きます

ここは混同しやすく、最も大切な違いです。

プライベートスペースが開いているからといって、その iPhone を手にした人がすべてをエクスポートできてよいわけではありません。プライベートバックアップを作る前に、Senvra は元の Space Access Key を求め、現在のスペースのものかを端末内で確認します。

設定画面ではこの操作専用の Backup Key も生成されますが、所有権の確認が通るまでバックアップファイルは作成されません。

承認後、Space Access Key の役目は終わります。バックアップの暗号化には使わず、ファイルにも書き込まず、復元にも必要ありません。ファイル自体を守るのは、独立して生成された Backup Key です。

flowchart TB
    A[Space Access Key] --> O[端末内で所有権を確認]
    K[独立した Backup Key を生成] --> C[バックアップ資格情報を準備]
    O -->|承認| E[暗号化ファイル作成を許可]
    C --> E
    E --> R[後日 Backup Key だけで<br/>検証または復元]
    A -. ファイルに保存しない<br/>ファイル暗号化に使わない .-> E

この分離には実際の利点があります。

• iPhone とスペースが開いていても、正しい Space Access Key がなければ全量エクスポートできない
• Backup Key が漏れても、稼働中のプライベートスペースを開いたりパスワードを再設定したりする資格情報にはならない
• 後から Space Access Key をローテーションしても、正しく保管済みのバックアップは無効にならない

Everyday スペースには所有権の再確認はありませんが、各バックアップには独立した Backup Key が生成されます。

Backup Key がファイルを守る仕組み

Backup Key は元の20個のランダムバイトに戻され、バックアップごとの新しい32バイトソルトと HKDF-SHA256 から、256ビットのラッピング鍵が導出されます。

同時に、Senvra は新しいランダムな256ビット Archive Key を生成します。実際の内容を暗号化するのは Archive Key です。Backup Key から導出した鍵は、鍵チェックを認証し、Archive Key をラップします。

これは160ビットを「256ビット強度」と宣伝するためではありません。資格情報の強度は、元の160ビットのランダムエントロピーが上限です。階層化の目的は、ユーザー資格情報、アーカイブ鍵、内容暗号化の役割を分け、バックアップごとに新しいランダムな文脈を持たせることです。

ファイル内部では AES-256-GCM 認証付き暗号を使います。Manifest、項目メタデータ、サムネイル、コレクション、タグ、内容はすべて暗号化層の内側です。外側の Header に残るのは、形式バージョン、作成時刻、ランダムなコンテナ ID、ソルト、機能フラグなど、安全に解析するための最小情報だけです。

ストレージ提供者は、ファイルの存在、おおよそのサイズ、.senvrabackup 拡張子を見ることができます。内容の暗号化は中身を守れますが、周囲のファイルシステムにファイルの存在まで忘れさせることはできません。

大きな動画を先に平文 ZIP にしません

バックアップ中に、あとで暗号化するための平文 ZIP をディスクへ残したくはありません。

Senvra は各項目を上限付きメモリバッファで読み、4 MiB のデータフレームに分け、ランダムな Archive Key ですぐに封印します。大きな動画も、完全な平文バックアップとして一時フォルダへ置く必要がありません。

各暗号化フレームは、形式バージョン、コンテナ ID、認証対象 Header、フレーム番号、フレーム種別に結び付けられます。読み取り時には、各項目のバイト数、チャンク数、SHA-256 コンテンツダイジェストに加え、全項目数、総バイト数、Manifest ダイジェストも確認します。

チャンクの変更、フレーム順序の入れ替え、ファイルの切断、フレーム種別の置換、末尾への余分なデータ追加は、すべて検証失敗になります。

進捗100%はまだ終わりではありません

これは設計の中でも、私たちが特に重視した部分です。

Senvra はまず、ファイル保護された pending ファイルへ書き込みます。暗号化が終わっても、すぐにはユーザーへ渡しません。コンテナ全体を最初から読み直し、すべての暗号化フレームを認証し、復号された Manifest が作成予定のものと完全に一致することを確認します。通過したときだけ、pending ファイルを完成したバックアップとしてアトミックに公開します。

その後、「ファイル」などへ保存します。しかしコピー自体も失敗し得ます。そこで Senvra は、アプリ内の検証済みファイルと外部コピーについて Header、バイト数、完全ファイル SHA-256 を比較します。両方が一致して初めて、Security Center は現在のバックアップとして記録します。

sequenceDiagram
    participant D as 現在のデータ
    participant P as Pending 暗号文
    participant F as ユーザーが保存したファイル
    participant S as Security Center

    D->>P: フレーム単位で読み、直ちに暗号化
    P->>P: 全体を再読込して認証
    P->>F: ユーザーが外部コピーを保存
    F->>S: Header、サイズ、完全ファイルダイジェストを比較
    S-->>D: 一致後のみ最新として記録

「ファイルを作った」と「安全なコピーを保存した」は別の状態です。一つの緑色チェックで混同させたくありません。

復元テストは Header を見るだけではありません

バックアップが失敗する理由は、作らなかったからとは限りません。最悪の日まで誰も復元を試さなかったから、ということがあります。

Senvra は何もインポートせずに復元テストを実行できます。対応する Backup Key でラップされた Archive Key を開き、Header を認証し、全フレームを読み、Manifest と項目関係、すべてのコンテンツダイジェスト、アーカイブ終了マーカーを確認し、末尾の余分なデータも拒否します。

暗号化された Manifest には元データの指紋も入ります。これにより、Senvra は次の2つを区別できます。

• 暗号学的に有効で、今も開ける古いバックアップ
• 有効で、現在のスペース内容とも一致する最新バックアップ

どちらにも価値はありますが、同じ状態ではありません。後者だけが現在のスペースに対する最新の復元テストとして記録されます。

復元はスペースを置き換えず、信頼できる内容を追加します

Senvra の復元は、「端末を過去のスナップショットへ戻す」よりも「検証済み内容をここへ取り込む」に近い仕組みです。

バックアップは同じ種類の現在のスペースにだけインポートできます。元のスペース一覧を再構築せず、プライベートスペースがいくつあったかも明かしません。現在のスペースの名前、スキン、パスワード、Space Access Key、Face ID、ジェスチャー設定も置き換えません。

項目を書き込む前に、Senvra はバックアップ全体を検証します。その後、項目ごとにファイル保護された pending ディレクトリへ置き、現在のスペースに属する新しい項目鍵で再暗号化し、読み返して検証してからアトミックに公開します。

途中で中断しても、既存の内容は壊れません。同じバックアップをもう一度選ぶと、完了済みの元項目を認識し、重複コピーせずにスキップします。

クリップボードに置くのも短時間だけ

長い Key を現実的に保存できるよう、Space Access Key と Backup Key は一時コピーできます。コピーはこの端末だけに限定され、Universal Clipboard の対象にならず、120秒後に期限切れになります。

その2分の間に別の内容をコピーした場合、Senvra は新しい内容まで消しません。先ほどの Key がまだ残っている場合にだけ、能動的にクリアします。

これはクリップボードを金庫に変える機能ではありません。露出時間を短くするための措置です。Key を保存するときは、クリップボードやキーボード入力をアップロードする第三者ツールを避けてください。

現実に続けられるバックアップ習慣

実践はシンプルです。

1. 作成を確定する前に、Backup Key を信頼できる場所へ保存する。
2. Key をファイル名へ書かず、.senvrabackup と同じチャット、メール、未暗号化フォルダに置かない。
3. 検証済みバックアップを独立した場所に最低2つ保管する。
4. 重要な内容変更後に新しいバックアップを作り、外部コピー確認まで完了させる。
5. 定期的に復元テストを行い、新しいコピーの検証前に最後の正常な旧バックアップを削除しない。

Senvra 自体はネットワークアクセスを必要とせず、代わりにバックアップをアップロードしません。「ファイル」で選んだ保存先は、別の提供者の規則で同期される場合があります。

任意の Apple Recovery Copy も、Backup Key がなければ開けない暗号化コンテナです。Senvra はそのコピーを検証し、システムバックアップ対象の場所へ置けますが、Apple のデバイスバックアップが存在すること、保持期間、復元成功を保証することはできません。

最後に、正直な境界

バックアップファイルがあっても Backup Key を失えば、Senvra にも復元できません。

Backup Key があっても、ファイルをすべて失えば復元するデータがありません。

両方が一緒に漏れれば、バックアップの機密性は失われます。この設計は、不適切な保管、Jailbreak 済み端末、すでに第三者の制御下にある OS まで解決できるとは主張しません。

私たちにできるのは、各段階を検証可能な工程にすることです。プライベートスペースのエクスポート前に所有権を再確認する。バックアップごとに独立したランダム Key を作る。平文の中間ファイルを残さない。すべてのフレームを認証する。完成後に読み直す。外部コピーを照合する。必要になる前に復元を練習する。

私たちにとって、それは「バックアップは暗号化されています」という一文より大きな意味があります。

全体像については、Senvra が iPhone のプライベートデータを守る仕組みと Senvra 製品ガイドもご覧ください。

参考資料

• RFC 5869：HKDF
• NIST SP 800-38D：GCM 認証付き暗号
• Apple Platform Security
• OWASP MASVS-STORAGE-1