プライベートなデータは、保護される前にスマートフォンの外へ出る必要はありません。この考えから、私たちは Senvra を開発しました。写真、動画、音声、PDF、ファイル、ノートを保存できるオフライン優先のプライベートスペースで、アカウントも、Senvra が運営するクラウド保管庫も、自動アップロードもありません。
Senvra の保管庫にネットワーク権限は必要ありません。 キーボードを開いた後に、ネットワークアクセス、ローカルネットワーク、モバイルデータ通信、または他社製キーボードの「フルアクセスを許可」を求められた場合は拒否できます。Senvra のローカル保管庫、ロック解除、入力、閲覧は引き続き利用できます。その要求は Senvra の保管庫ではなく、iOS または選択中のキーボードから出ている可能性があります。機密性の高い内容を入力する場合は、音声入力と不要なクラウド入力機能を無効にした Apple 純正キーボードを使うか、他社製キーボードのフルアクセスを無効にしてください。権限の拒否はキーボード経由で入力内容が端末外へ出るリスクを減らしますが、端末の安全性、キーボードの提供元、明示的な書き出しの管理に代わるものではありません。
しかし、「端末内にある」ことと「安全である」ことは同じではありません。信頼できる保管庫には、さらに厳しい問いへの答えが必要です。
- パスワードを繰り返し推測されたらどうなるのか。
- バックアップファイルを盗まれたら何が分かるのか。
- クラッシュ、録画中断、容量不足が起きても、それまでのデータを守れるのか。
- アプリがバックグラウンドに移った後も、復号状態がメモリに残らないか。
- 端末が Jailbreak されている場合、どの前提が崩れるのか。
私たちの答えは、多層防御（Defense in Depth）です。NIST は、人・技術・運用を組み合わせ、複数の層に異なる障壁を設ける考え方として説明しています。Senvra では、信頼できる環境、暗号による分離、安全な復旧プロセス、日常操作中の保護という4層に具体化しています。
This diagram could not be rendered. Its source is still available below.
View diagram source
flowchart TB
A[1. 信頼できる環境<br/>最新の iOS、端末パスコード、Jailbreak なし]
B[2. 暗号による分離<br/>独立したスペース、鍵、認証済みファイル]
C[3. 安全なプロセス<br/>復旧、バックアップ、検証、アトミックコミット]
D[4. 日常操作の保護<br/>プライバシーシールド、自動ロック、クイッククローズ]
A --> B --> C --> D
D -. 露出時間を短縮 .-> Aどれか1層を万能だとは考えていません。ある対策が完全でない場合でも、別の対策が被害を小さくできることに、多層設計の意味があります。
第1層：信頼できる端末環境から始める
Senvra の保護モデルは、サポート対象で最新の iOS を実行し、Jailbreak されておらず、端末パスコードで保護された iPhone を前提としています。
この境界は重要です。Jailbreak は、通常の iOS アプリが依存するサンドボックス、コード署名、プロセス分離を弱めます。OS レベルの権限を得た攻撃者は、アプリの私有ファイルを調べたり、実行中プロセスを計測したり、正当な利用のために復号された後の秘密を取得したりできます。Jailbreak 検知は攻撃コストを上げられますが、OWASP も検知自体が回避可能であると説明しています。完全に侵害された OS 上で絶対的な安全を約束することはできません。
実際の基礎対策は明確です。
- iOS を最新に保つ。
- 強い端末パスコードと Face ID を使う。
- Jailbreak 端末に機密データを置かない。
- すでにロック解除された端末は、より高いリスクとして扱う。
Senvra 自身の信頼面も小さくしています。保管庫の内容は端末内で処理・保存されます。Senvra アカウント、ホスト型クラウド保管庫、保護コンテンツの自動アップロードはありません。本番版の保管庫操作には、ネットワーククライアント、WebView、ローカルネットワーク宣言、バックグラウンドネットワーク権限が必要ありません。Support はユーザーが明示的に開いた場合だけシステムブラウザへ渡され、エクスポートしたコピーはユーザーが選んだ保存先の管理下に移ります。
ローカル優先だから侵害が不可能になるわけではありません。なくなるのは、攻撃者、運営者、またはデータ漏えいが一括取得できる中央の Senvra 保管庫です。
第2層：スペース、鍵、ファイルを分離する
Senvra における暗号化は宣伝用のラベルではなく、役割を分離した鍵階層です。
各プライベートスペースには、ランダムな256ビットのマスターキー、固有のパスワードソルト、暗号 ID が割り当てられます。パスワードは PBKDF2-HMAC-SHA256 で処理され、現在の本番パラメータは600,000回です。導出鍵は各ファイルを直接暗号化するのではなく、スペースのマスターキーを開くために使われます。
保護された各アイテムは AES-256-GCM 認証付き暗号で保存されます。認証は、内容を隠すだけでなく改変の検出にも必要です。メディアチャンク、メタデータ、サムネイル、鍵エンベロープ、所有スペースとオブジェクト ID は認証データで結び付けられています。暗号化済み部品を別の場所へ移しても、そこで有効なデータにはなりません。
This diagram could not be rendered. Its source is still available below.
View diagram source
flowchart LR
P[スペースパスワード] --> K[PBKDF2-HMAC-SHA256<br/>600,000回 + 固有ソルト]
R[32バイトのアクセスキー] --> H[HKDF-SHA256<br/>独立した復旧ドメイン]
K --> M[ラップされた256ビットのスペースマスターキー]
H --> M
M --> I[独立したアイテム鍵エンベロープ]
I --> G[AES-256-GCM メディアチャンク]
I --> T[認証済みメタデータとサムネイル]1つのパスワード、1つのスペース、一覧なし
多くの保管庫は、存在するコンテナを先に表示し、ユーザーに1つ選ばせてからパスワードを求めます。しかし、その選択画面自体が情報を漏らします。内容が見えなくても、プライベートスペースの存在、数、名前を周囲の人に知られる可能性があります。
Senvra は逆の流れを採用します。アプリは通常の Everyday スペースから始まり、プライベートスペースは閲覧可能な一覧に現れません。入口は1つだけで、入力したパスワードに対応するスペースへ直接移動します。異なるパスワードは異なるスペースを開き、名前、カバー、実数を先に表示しません。肩越しの覗き見、一時的な確認、ロック解除済み端末を短時間渡した場面で、別のスペースが存在するという視覚的な手掛かりを減らします。
これは単なる画面上の非表示ではありません。保存カタログは4つの固定ディレクトリスロットを使い、未使用位置をパディング記述子とファイルで埋めることで、外形から実際のスペース数が直接分からないようにします。ロック解除時には、実際のパスワードスペースを確認し、一致した時点で即時終了せず、同等の導出・秘匿処理を完了します。誤った試行も一貫して処理され、3回失敗するごとに待機時間が1分、5分、30分、1時間、24時間へ段階的に増えます。
この設計が減らすのは、インターフェースとカタログメタデータからの漏えいです。「隠れているから暗号化されている」という意味ではなく、Jailbreak 端末や専門的なフォレンジック解析に対する完全な否認可能性も約束しません。内容そのものは、独立した鍵、認証付き暗号、信頼できる端末環境によって保護されます。
同じ鍵階層はアイテム同士も分離します。大きな動画は制限されたチャンクごとに認証され、1つのアイテムの破損を理由に無関係なファイルまで信用したり無効化したりしません。Security Center はライブラリを書き出さずに保護ファイルを認証し、整合性の問題を特定できます。
iOS の保護もこの層の一部です。機密ディレクトリには Complete File Protection を使い、端末に結び付いたラップ材料は WhenUnlockedThisDeviceOnly の Keychain に保存します。Senvra はアプリ層の暗号化を追加しますが、基盤 OS の重要性を無視しません。
第3層：復旧と障害時の処理も安全にする
機密性だけで復旧できない設計は、完全なデータ安全性とは言えません。パスワードは忘れられ、端末は故障し、ストレージは満杯になり、プロセスは突然終了します。Senvra はこれらを例外ではなく設計条件として扱います。
サーバーリセットではなく、ユーザーが保持するアクセスキー
各プライベートスペースにはランダムな32バイトのアクセスキーを設定できます。アクセスの復旧、パスワードの再設定に利用でき、現在のキーを確認した後にローテーションもできます。Senvra にはサーバー側のパスワードリセット用バックドアはありません。
責任境界も明確です。パスワードとアクセスキーの両方を失うと、Senvra でもスペースを復号できません。アクセスキーは端末外の信頼できる場所に保管してください。
バックアップには2つの独立した資格情報が必要
現在の V3 ポータブルバックアップは2要素の資格情報を使います。
- プライベートスペースでは、スペースのアクセスキーと別のバックアップパスワードが必要です。
- パブリックスペースでは、新しく生成したランダムなバックアップキーと別のバックアップパスワードが必要です。
バックアップパスワードは PBKDF2-HMAC-SHA256 で600,000回処理されます。資格情報キーとパスワード由来の材料は、ドメイン分離された HKDF で組み合わされます。その結合鍵はランダムなアーカイブキーの認証とアンラップにだけ使われます。アーカイブ本体は、シーケンス番号とレコード種別も認証データに含めた、独立した AES-256-GCM フレームとして書き込まれます。
バックアップファイルだけ、パスワードだけ、保存したキーだけでは開けません。
This diagram could not be rendered. Its source is still available below.
View diagram source
flowchart TB
A[アクセスキーまたは生成済みバックアップキー] --> C[ドメイン分離された鍵結合]
B[バックアップパスワード<br/>PBKDF2-HMAC-SHA256] --> C
C --> D[ランダムなアーカイブキーを認証して開く]
D --> E[AES-256-GCM で制限付きフレームを暗号化]
E --> F[タグ、バイト数、アイテム摘要、マニフェスト摘要を検証]
F --> G[完全な .senvrabackup をアトミック公開]
F -. 失敗 .-> X[拒否して未完了出力を削除]V3 の外側ヘッダーには、スペース名、アイテム名、元 ID、サムネイル、スコープ詳細を置きません。認証フレーム、バイト数、各アイテムの摘要、マニフェスト摘要、最終終了マーカーがすべて一致した場合だけ、バックアップを受け入れます。インポート時には対象スコープとの一致も確認し、由来情報によって同じ項目の無言での重複を防ぎます。
メイン保管庫は通常の Apple 端末バックアップから除外されます。Apple の復旧対象にできるのは、完全で強く暗号化され、匿名名を持つ復旧コンテナだけです。ユーザーは暗号化バックアップを Files など自分が管理する場所へ手動保存することもできます。
Senvra はインポートせずにバックアップを Verify できます。重要な変更後に検証し、定期的に復旧演習を行うことを推奨します。検証していないバックアップは、証拠ではなく期待にすぎません。
録画は段階的に保護・コミットする
長い平文動画を一度書き、最後に暗号化する方式には大きな危険時間があります。Senvra は録画セグメントが届いた時点で保護データとして書き込みます。
録画開始前に、保護されたジャーナルを作成し、最終処理用の容量を予約します。受理済みセグメントは暗号化され、永続ストレージへ同期された後、アトミック更新されるジャーナルに記録されます。セグメント構造、バイト数、SHA-256 摘要が一致してから最終メタデータをコミットし、検証後にだけ保留ディレクトリを正式なアイテム位置へ移します。
アプリが中断された場合、すでにコミットされた保護セグメントは次回起動時に検出・復旧できます。突然の電源断でハードウェアや OS バッファ内の最後のフレームまで必ず残る、という意味ではありません。それまでに暗号化され永続化された有効セグメントを、障害のためにすべて捨てないという意味です。
他の重要な書き込みも、保留場所へ書く、検証と同期を行う、アトミックに公開する、という同じトランザクション方式を使います。未完了データを完了済みとして表示しません。
重要なアクセスは検証可能な履歴になる
スペースのオープンと重要な操作は、暗号化された追記専用のアクティビティチェーンに入ります。各イベントは直前のイベントへ連結され、独立した Keychain アンカーが切り詰め、置換、古い状態へのロールバックの検出を支援します。
これはリアルタイム侵入通知ではなく、誰が操作したかを証明するものでもありません。所有者が重要アクセスを確認し、履歴の内部整合性を検証できる、端末内の証跡です。
第4層：人が忘れやすい瞬間を守る
多くのプライバシー事故は認証の後に起きます。アプリ切替、着信、机に置いたままの端末、画面収録、閉じ忘れなどです。その瞬間に働くには、セキュリティ操作が十分に使いやすい必要があります。
Senvra はライフサイクル変化をセキュリティイベントとして扱います。
- アプリが非アクティブになると、プライバシーシールドで機密内容を覆い、一時平文を消去します。
- バックグラウンドに入ると、現在のプライベートスペースを閉じ、メモリ内のロック解除状態を消去します。
- 端末ロック時には保護アクセスを閉じ、機密処理を停止します。
- 画面キャプチャ検知時はシールドを表示し、安全な遷移後にだけ内容を再表示します。
- 自動ロックは30秒、1分、2分、5分、15分から選べます。
- クイッククローズで通常スペースへ戻れ、任意で Shake to Close も有効にできます。
- 非アクティブ時には、インポート、エクスポート、バックアップ、整合性確認、ローカル索引などの長時間処理を中止または遮蔽します。
iOS がスクリーンショット撮影を通知した場合も Senvra は反応しますが、限界は明示します。OS がすでに保存・同期した画像を、iOS アプリが確実に消去することはできません。Senvra は保護コンテンツを閉じてロック解除状態を消去しますが、撮影済み画像の回収は約束しません。
Face ID やジェスチャーは利便性のための入口であり、スペース固有のパスワードと復旧資格情報に従属します。利便性が唯一の復旧経路になることはありません。
このモデルが約束しないこと
Senvra は次のことを主張しません。
- Jailbreak 済み、または OS が完全に侵害された環境での絶対的な保護。
- すでにロック解除された端末を持つ人が、絶対に内容を見られないこと。
- iOS が保存済みのスクリーンショットを必ず回収できること。
- ユーザーが書き出した平文コピーを、保存先でも制御できること。
- リモート消去、自動クラウド同期、サーバーによるパスワード復旧。
- 実施されていない第三者独立セキュリティ認証。
端末と利用可能なバックアップをすべて同時に失った場合のデータ損失も防げません。暗号化、整合性、復旧は関連しますが、互いの代わりにはなりません。
実践的な設定チェックリスト
- iOS を最新に保ち、Jailbreak しない。
- 強い端末パスコードと Face ID を使う。
- スペースごとに固有のパスワードを使う。Senvra の最小値は12文字、推奨は16文字以上です。
- アクセスキーを Senvra 外、かつ同じ端末以外にも保管する。
- 別のパスワードで暗号化バックアップを作り、ファイルと必要な2資格情報を適切に分離した信頼できる場所に保管する。
- 大きな変更後に Verify を実行し、定期的に復旧演習を行う。
- 実用可能な最短の自動ロック時間と、確実に使えるクイッククローズ方法を選ぶ。
- 書き出した平文コピーは保管庫の管理外であることを忘れない。
なぜ Senvra をこのように作ったのか
プライバシー保護のために別企業のサーバーへ機密データを送ること、自分のデータへ継続的にアクセスするために払い続けること、1枚のロック画面だけを信頼することを、私たちは望みませんでした。Senvra は買い切りで、広告もサブスクリプションもありません。所有権と復旧能力をデータの持ち主に残すため、中核保管庫はオフラインで動作します。
これは「破られない」という宣言ではありません。信頼できるプラットフォーム、独立した暗号ドメイン、障害を前提とした復旧、露出を素早く終わらせる操作という、境界が明確な障壁です。「スマートフォン内で安全」とは、信頼先が少なく、限界が正直に示され、必要になる前に検証できる復旧経路があることだと考えています。