SeraShield保管庫で端末上の暗号化が意味すること

他人に実際に見える可能性があるものから考える

賃貸契約書のスキャンを想像してください。ファイルが暗号化されていても、サムネイルやファイル名が読めるキャッシュに残っていれば、機密部分が露出する可能性があります。設計では、読み込んだファイル、一覧表示する索引、生成されたサムネイル、閲覧や共有のための一時コピーをすべて考慮する必要があります。

iOSはData Protectionシステムで既にファイルを保護しており、ファイルのクラスごとにアクセス規則が異なります。アプリの保管庫では、選んだデータを永続保存する前に暗号化し、独自の層を追加できる可能性があります。通常の利用中にファイルがどこで読めるのか、利用後に何が読める状態で残るのかが設計上の問題です。

鍵をいつ使用できるか決める

候補となる設計では、AppleのCryptoKitにあるAES-GCMなど、確立した認証付き暗号化APIを使って内容を隠しながら完全性も検証します。ただし、鍵の生成と保護、nonceの再利用防止、保存形式変更への対応を含め、十分に検証された鍵管理設計が引き続き必要です。

Appleのキーチェーン制御は端末の状態や利用者の存在に応じてアクセスを制限できます。これにより、ロック解除済みの電話を他人に渡した後で再認証を要求する保管庫を検討できます。代替解除方法は重要です。端末のパスコードを認めるなら、それを知る人は解除できる可能性があります。鍵を一台の端末に強く結び付けると移行や復旧は難しくなる場合があります。

公開前に確認したい証拠

偶然の閲覧、ロックされた電話の所持、コピーしたバックアップへのアクセスに対して、それぞれどこまで保護するのかを個別に定義します。状況ごとに異なるテストが必要です。他人が電話を管理する場合や保管庫から書き出されたファイルには追加のリスクがあります。

1. 読み込み、ロック、アプリの強制終了、再起動の後に、保存ファイル、サムネイル、ログ、アプリのプレビューを調べます。
2. 暗号化されたテストデータを改ざんし、内容の一部も表示せずにアプリが拒否するか確認します。
3. 代替認証、途中で止まった読み込み、鍵の変更、交換用端末での復元を試します。
4. 書き出しや共有の際に保管庫から外へ出るファイルを文書化します。