医療スタートアップが数ヶ月かけて安全なモバイルワークフローを設計した後、テスターの電話がロック解除され、スクリーンショットやローカルキャッシュを通じて患者の記録を公開した場合、チームのElectron管理パネルがデバッグビルドで配信された場合、そのビルドにAPIキーが埋め込まれていることがわかります。両方のインシデントは暗号化に関連していますが、どちらも暗号化ライブラリを追加することで解決されません。
アプリケーション暗号化は、決定のシステムです。 チームは、データが保存されたときにどのように保護されるか、システム間でどのように移動するか、キーがどこに存在するか、どのアプリケーションパッケージから攻撃者が何を学ぶことができるか、ランタイムが改ざんに対してどのように反応するか、署名された更新がそれらの保証を維持するかについて決定する必要があります。有効な出発点は、敏感なデータ、信頼境界、クライアントの機能、可能性のある悪用パスをマッピングするアプリケーションリスクアセスメントです。 アプリケーションリスクアセスメント データが敏感である可能性のある情報、信頼境界、クライアントの機能、そして悪用の可能性のあるパスをマッピングする。
目次
アプリケーション暗号化の重要性
- 保存中の暗号化と移動中の暗号化
- 保存中の暗号化
- Code
- iOS、Android、Capacitor、およびElectronのプラットフォームに関する考慮事項
- ネイティブモバイルプラットフォーム
- キーマネジメントとクライアントサイドシークレットの限界
- 規制と法的要件
- 一般的な誤りとハード化されたベストプラクティス
暗号化計画にすべてを組み込む
A web application usually keeps much of its sensitive logic and secret material on infrastructure the organization controls. A mobile application sends code, assets, configuration, and data-handling logic to a device that belongs to someone else. An Electron application has a similar problem, because its JavaScript, resources, and packaged files can be inspected by a user who can run the application.
セキュリティの境界が変わります。 セキュリティの境界が変わります。 情報は一般的な検査から保護され、盗まれたファイルは利用価値が低くなるが、アプリは一時的に平文にアクセスする必要がある。デバイスを制御する攻撃者は、入力値を観察、メモリを検査、APIをインストルメント、実行を変更できる。
医療の例を考えてみましょう。データベースを暗号化すると、ディスクからコピーされたレコードを保護できますが、コンパウンドされたランタイムから非公開のレコードを表示することはできません。クリニシャンのリクエストを保護するには、ネットワークトラフィックを暗号化する必要がありますが、ローカルに保存した非保護キャッシュから保護することはできません。ミニファイズされたJavaScriptに隠されたキーは、必要に応じてアプリケーションが使用する場合に回復可能です。
実用的なルール: すべてのクライアント側の保護を、信頼できるデバイスであることを証明するものではなく、露出を減らす層として扱う。
完全な設計では通常組み合わせる:
- 静止保護データベース、ファイル、キャッシュ、設定、ダウンロードしたドキュメントの場合。
- 移動中の保護リクエスト、同期、更新配信、サービス間の通信の場合。
- プラットフォームキーストレージ暗号化キーが通常のアプリケーションファイルに残らないようにする。
- Codeとランタイム保護、暗号化、整合性チェック、デバッグ対策、適切な証明書検証を含む。
- Aの制御された更新チャネル、署名されたリリースは、以前のバージョンに組み込まれたセキュリティの仮定を維持する必要があるため、
- 文書化されたコンプライアンスコントロール、所有権、証拠、監視、対応手順を含む。
法的義務は圧力をかけるが、エンジニアリングの規範を高める。GDPR、HIPAA、PCI DSS、SOC 2は暗号化をuniversalチェックボックスに変えるのではなく、チームに理解させる。暗号化するもの、鍵の制御、安全対策が機能することを示す方法を理解させる。
データが移動中の暗号化と、データが保存されている暗号化
信頼性の高い文書を郵便で送る。封筒はメッセージを保護するが、受信者が封筒を開くと、文書は安全なファイルカビネットで保存されている必要がある。 封筒とファイルカビネットは異なる問題を解決する。 保存中の暗号化
保存中の暗号化は、デバイス、サーバーディスク、バックアップ、データベース、外付けボリュームに保存されているデータに適用される。モバイルプラットフォームでは、オペレーティングシステムの保護機能がデバイスの一部を暗号化する場合もあるが、アプリケーションは安全な保存場所、アクセス制御、鍵の使用を選択する必要がある。敏感なアプリケーションファイルは、プラットフォームがサポートする暗号化と鍵を保護されたストアに保持する必要がある。鍵は暗号化されたデータの横に書くのではなく、
移動中の暗号化
暗号化されたエンコードはここで重要です。OWASPはプラットフォームの暗号化API、ハードウェアバックアップされたキーストレージが利用可能な場合、認証モードであるAES-GCMまたはAES-CCMなどの暗号化を推奨しています。 暗号化モードこれらの暗号化モードは、データの改ざんを検出するだけでなく、コンテンツを隠すこともできます。同様のガイドラインでは、静的データと移動中のデータを保護することを推奨し、内部ストレージにプライベートデータを格納し、プラットフォーム実装を優先することで、独自の暗号化アルゴリズムを避けることを推奨しています。OWASPモバイルアプリケーションセキュリティのチートシート).
実際の詳細はプラットフォームによって異なります。iOSはData ProtectionとKeychainサービスを提供しています。AndroidはKeystore-backedオプションと、暗号化ファイルを管理するのに役立つライブラリを提供しています。デスクトップアプリケーションは、オペレーティングシステムのクレデンシャルとローカルアクセス制御に依存しています。Chromium Embedded Framework環境でファイルを扱うチームは、 CEFドキュメントの保存に関するベストプラクティス を参照して、シフラの境界を超えたストレージの境界を確認することができます。
移動中の暗号化
通信中の暗号化は、ネットワークを横断するリクエストとレスポンスを保護します。TLS接続を適切に設定すると、中間者がアプリケーション トラフィックを読み取ったり変更したりするのを防ぐことができますが、クライアントがサーバーを正しく検証し、バックエンドが信頼された証明書を提示する場合にのみ機能します。証明書の検証を無効にしたり、安全なフォールバックを使用したり、誤って明示的なクリアテキスト エンドポイントを使用したりすると、意図された保護を損なう可能性があります。
証明書ピンニングは、特定のモバイルシナリオで、チームが証明書の操作を制御し、ローテーション用の回復計画を持っている場合に、追加の検証層を追加できます。ただし、正しいTLSの代替ではありません。誤ったピンは、有効なユーザーをブロックする可能性があります。Capacitorで構築しているチームは、 Capacitorアプリ用のSSLピンニングを検討する 運用上のトレードオフがアプリケーションに適合するかどうかを判断する前に
失敗モードは互いに補完的です。Transport Securityは、紛失したデバイスからコピーされたデータベースを保護しません。Storage Encryptionは、コンプロミットされた接続を通じて送信されたパスワードを保護しません。両方のパスを設計し、明示的なデータが現れるポイントをテストし、ログ、スクリーンショット、テンポラリ ファイル、クラッシュ レポート、クリップボード コンテンツ、同期 キューを含めます。
Code、データ、シークレットの保護
チームは、同じコントロールを説明するように「暗号化」、「オブフュージョン」、「ハードニング」を使用することがよくありますが、実際にはそれらは異なるものです。各コントロールは、異なる攻撃者の行動を対処します。混同は、誤った自信を生み出します。
オブフュージョンとミニファイション make code harder to read. They can raise the cost of cloning an application or understanding business logic, but they don’t make a secret unavailable to an application that must use it. An API key in a JavaScript bundle, a signing credential in an archive, or a value reconstructed by a predictable function can still be extracted. Hermes bytecode and Electron asar __CAPGO_KEEP_1__キーをJavaScriptのバンドルに含める
アーカイブ内の署名認証情報 protects user content and local credentials while stored. It should use platform cryptographic APIs and keys held in Keychain, Keystore, Secure Enclave, StrongBox, or an equivalent operating-system facility where available. OWASP’s cryptography testing guidance warns against placing passwords or keys in source code and emphasizes that secrets remaining on the client can be extracted (ヘルメス バイトコードとエレクトロン).
アーカイブをインスペクトすることはソースファイルよりも不便になるかもしれないが、パッケージングは秘密とは異なる データ暗号化
| ユーザー コンテンツとローカル クレデンシャルを保存中に保護する | プラットフォームの暗号化 API とキーの Keychain、Keystore、Secure Enclave、StrongBox、または等価のオペレーティング システムの機能で保持する | OWASP の暗号化テスト ガイドラインはソース __CAPGO_KEEP_0__ にパスワードやキーを置かないように警告し、クライアント上の秘密が抽出されることを強調している |
|---|---|---|
| Code の暗号化 | アプリケーションロジックの読みやすさとカジュアルな複製 | アプリケーションがアクセスできるシークレットの抽出 |
| データ暗号化 | 選択された保存データの機密性と完全性 | 正当なデコード後、平文の露出 |
| 実行時保護 | いくつかの改ざん、デバッグ、自動的な悪用 | 実行環境を制御する高度な攻撃者 |
安全な設計では、重要なシークレットをサーバーに保管し、クライアントに限定されたクレデンシャルを与え、オフラインアクセスが必要なローカルデータのみを暗号化します。トークンストレージには、有効期限、削除、更新の動作、およびプラットフォームのバインディングに関する独自のレビューが必要です。 モバイル開発者向けの安全なトークンストレージガイド 実装要件として、決定を実装する際に役立ちます。
無知なアプローチは失敗することがあります。なぜなら、シークレットのライフサイクルを保護するのではなく、シークレットの外観を保護しているからです。ソースcodeで値をXORする、キーを複数のファイルに分割する、またはJavaScriptのミニファイションに頼ることは、実行中のアプリケーションが値を再構築して使用する必要があることを変えません。
iOS、Android、Capacitor、およびElectronのプラットフォームに関する考慮事項
各実行環境では、キー ストア、API、隔離境界、復元メカニズムが異なるため、同じ暗号化設計は実行環境によって異なる動作を示します。クロスプラットフォーム抽象化はアプリケーションのcodeを簡素化できますが、異なる差異を消去することはできません。
ネイティブモバイルプラットフォーム
iOSでは、Keychainは保護された資格情報の保存を提供し、 Secure Enclave は、主なアプリケーションプロセッサから特定のキー操作を隔離できます。アプリケーションは、利用性要件に合ったアクセス制御を選択する必要があります。たとえば、デバイス認証後にデータが利用可能になるか、ユーザーが認証した後にのみ利用可能になるかなど。
Android Keystoreはサポートされているデバイスでハードウェアバックアップされたパスを提供し、 StrongBox は、利用可能な場合に強力な隔離された環境を提供します。Androidチームは、デバイスの機能、バックアップの動作、認証要件、信頼性の信号などを考慮する必要があります。ハードウェアサポートは均一ではないため、アプリケーションには定義されたフォールバックポリシーが必要であり、すべてのデバイスが同等の保護を提供することを前提とすることはできません。
クロスプラットフォームシェル
Capacitorアプリケーションは、Webcodeとネイティブプラットフォーム機能をブリッジを介して組み合わせます。このブリッジはセキュリティ境界であり、単に便利な層ではありません。 localStorage, IndexedDB、そして通常のWeb設定は、暗号化された秘密ストアとしてデフォルトで扱うべきではありません。チームは、ネイティブストレージプラグインを選択するか、プラットフォームの保護されたキー機能を使用するネイティブモジュールを実装する必要があります。
Electronには異なる脅威モデルがあります。レンダラーはWebコンテンツを処理し、メインプロセスはより広範な特権を持つため、敏感な操作は公開されたレンダラーから外に残す必要があります。Electronの safeStorage can使用オペレーティングシステムの資格情報保護機能ですが、結果はホストオペレーティングシステム、ユーザーアカウント、デスクトップ設定、およびプロセス隔離に依存します。鍵は、モバイルプラットフォームが保護された鍵を自動的にハードウェアで隔離するのと同じ方法で鍵が自動的にハードウェアで隔離されません。
| プラットフォーム | 鍵ストレージ | 暗号化API | デフォルトの脅威モデル |
|---|---|---|---|
| iOS | Keychainと、サポートされている場合のSecure Enclave | Appleプラットフォームの暗号化とData Protection | デバイスとアプリケーションは別々ですが、侵害されたデバイスまたはランタイムが使用を観察できる |
| Android | Keystoreと、サポートされている場合のStrongBox | Androidプラットフォームの暗号化とJetpackセキュリティコンポーネント | ハードウェアとソフトウェアの機能はデバイスによって異なります |
| Capacitor | Native storage selected through plugins or custom bridge code | ウェブAPIとネイティブプラットフォームAPI | Web APIとネイティブプラットフォームAPI |
| Electron | Electron safeStorage |
OS認証機能はAPIとして提供されます | NodeとChromium互換のアプリケーションAPI |
レンダラーの露出とホストレベルのアクセスは主な懸念事項です プラットフォームの差異に対するCapacitorアプローチ プラットフォーム固有の決定は、ブリッジとしての場所で必ずしも視認できる必要があります。
クライアントサイドの機密性の限界とキー管理
暗号化は、キー管理がキーを保護する場合にのみデータを保護します。有用なライフサイクルには、5つのステージがあります。 生成、配布、保存、ローテーション、削除各ステージは異なる障害モードを生じます。
信頼できるプラットフォームまたはサーバー暗号化APIでキーを生成し、認証されたプロトコルを通じて配布するのではなく、パッケージに埋め込まないでください。可能な場合、保護されたプラットフォームファシリティで保存し、ポリシー、リスク、暗号化要件によって要求される場合にローテーションし、デバイス、アカウント、またはセッションがデータを復号する必要がなくなった場合にサーバー制御の認可でアクセスを削除してください。
クライアントはこれらの操作でインフラストラクチャよりも弱いです。ユーザーがデバイスを制御し、潜在的にアプリケーション状態を検査できるためです。ユーザーが生成したパスフレーズで保護されたオフラインデータに対してクライアント保有のキーは意味を持ちますが、提供される回復とユーザビリティの影響を認識する必要があります。API トークンが広範なバックエンドアクセスを許可する場合、ローカルデータベースを暗号化することによっては、攻撃者がトークンを抽出することでトークンが実行できることの制限が生じません。
データ暗号化では、データ暗号化キーとマスターキーを分離します。アプリケーションは、短期間のデータキーでローカルオブジェクトを暗号化できます。サーバーサイドのキーマネジメントサービスまたはHSMバックアップシステムは、ラッピングキーを保護します。リモートキーリリース設計では、デバイス、ユーザー、ポリシー決定、または証明信号が認証されたデバイスに必要な材料をリリースする前に、デバイスに永久に座っている権限を減らします。
OWASPは、ローカルに保存される敏感なデータを、個人情報、暗号化された材料、シークレット、APIキーの個人情報として定義しています。暗号化は、ライフサイクル制御とともに、安全なローカルストレージ、キーローテーション、使用後ゼロ化と関連付けられます。アーキテクチャ的原則は簡単です。
重要なシークレットはチームが管理するシステムに保管し、クライアントに必要な最小限の権限を与えます。
リリースシステムのキーマネジメントには、更新署名と配信も含まれます。チームは、誰がバンドルを署名できるか、署名資格がどこに保管されているか、どのようにアクセスが監査されるか、どのように署名資格が妨害された場合に置き換えられるかを定義する必要があります。指針は OTA更新を暗号化するためのキーマネジメントのガイダンス アプリケーション暗号化と更新ライフサイクルを関連付けることができます。
規制と法的影響
コンプライアンスチームは、"アプリが暗号化を使用している"というstatementだけでは十分な証拠と認めないことが多い。データがどの範囲をカバーしているか、どのアルゴリズムとプロトコルが有効か、キーを管理しているのは誰か、どのようにアクセスが制限されているか、どのように組織が構成変更を検出しているかについて質問する。
GDPRのArticle 32では、暗号化をリスクを減らす適切な技術的措置として扱っており、欧州連合のGDPRのテキストに反映されている。義務はリスクに基づいているため、組織は依然として、個人データの性質と処理環境に応じて、安全対策を接続する必要がある。医療情報、個人情報、または財務記録を取り扱うモバイルアプリには、ローカルストレージ、輸送、アクセス、インシデント対応について、説明責任のある説明が必要である。
HIPAAのセキュリティ規則では、電子保護された健康情報の暗号化を、必ずしも技術的チェックボックスとして扱うのではなく、扱えるセーフガードとして扱っている。つまり、カバーされたエンティティまたはビジネスアソシエートは、暗号化が適切かどうかを評価し、決定を文書化し、実装しない場合は代替措置を適用する必要がある。HHSセキュリティ規則ガイドラインは、適用されるコンテキストを提供している。
PCI DSSでは、カードホルダー情報をストレージからオープンなネットワークを通じてのトランスミッションから分離する。チームは、暗号化の決定を適用可能な要件にマッピングし、不必要に支払いデータをストレージしないようにする。PCIセキュリティスタンダードカウンシルのドキュメントライブラリは、現在の表現と範囲を確認する適切な場所である。
SOC 2 の監査者は、制御が正常に動作していることを証明するための証拠に焦点を当てます。 その証拠には、鍵管理ポリシー、TLS の構成、シーカーの一覧、ログインアクセス、変更承認、インシデントレコード、テスト結果、および署名されたリリースが意図されたプロセスに従っていることを証明する証拠が含まれます。 監視されていない制御は、有効な動作を示すものではありません。
共通のテーマは 証明可能性です。 アプリケーション暗号化を実装する際に、証拠のトレイルを構築するのではなく、審査の週前に行うのではありません。
共通の誤りと強化されたベストプラクティス
暗号化の失敗は、通常のエンジニアリングの決定から始まります。 開発者は起動時にトークンが必要です、チームはオフライン検索が速く感じたい、またはリリースプロセスにはホットフィックスを迅速に配布する方法が必要です。 リスクは、ショートカットが信頼モデルの一部になる時点で現れます。
最近のモバイルリスク調査では 評価されたアプリの 60% 以上が、機密データのための不正または古い暗号化を使用していました、 約 1/3 が初期化ベクトルを再利用していました 、 20% がハードコードされた静的値を使用している それらの発見は、質問を「アプリが暗号化しているか？」から「実際の使用状況下で機密性と完整性を維持できる実装が可能か？」に変えるモバイルアプリリスクに関するSCワールドレポート)
| 共通の誤り | ハード化された実践 |
|---|---|
| ソース、バイトコード、またはバンドルにAPIキーまたは暗号化キーをハードコードする | 高価な資格情報をサーバー側に保管し、デバイススコープの資格情報に保護されたプラットフォームストレージを使用する |
| SQLiteデータベースを暗号化しながら、平文キャッシュ、エクスポート、ログ、またはバックアップを残す | 機密データのすべてのコピーを調べ、臨時アーティファクトに同じストレージポリシーを適用する |
| 通常のウェブストレージにリフレッシュトークンを保存する | プラットフォームバックアップされた資格情報ストレージを使用し、トークンスコープを狭め、サーバーサイドの削除をサポートする |
| カスタム暗号化またはキーオブフュージョンを実装する | 信頼できるプラットフォームAPIと認証された暗号化モードを使用する |
| 接続性問題を解決するために証明書の検証を無効にする | TLSを正しく設定し、テスト済みの復旧プロセスとともにピン設定を評価する |
| 最適化を秘密保護とみなす | クライアントのcodeからシークレットを削除し、逆エンジニアリングコストを上げるためにのみオブフュージョンを使用する |
| アプリの完整性チェックと信頼性の信号を省略する | 適切な場合にリリースの正当性を検証し、権限の調整またはレビューのトリガーとなる信号を使用する |
| 署名されていないまたは弱く制御された更新を許可する | リリースアーティファクトを署名し、署名のクレデンシャルを保護し、更新結果を監視する |
別の脅威レポートでは、SignalとWhatsAppアカウントをスパイウェアグループがアプリケーションを偽造し、電話の下部を悪用することで標的にしていたと述べた。同レポートは、同社のモバイル脅威アセスメントを引用している。 2025年上半期に2024年上半期と比較して29%増加したAndroidスマートフォン攻撃が報告された (The RegisterがCISAに関連するレポートのカバレージを掲載. 例では、暗号化が失敗したということではありません。攻撃者は、保護された暗号化データを回避できるレイヤーであるデバイス、アカウント、セッション、またはアップデートパスを選択することがよくあります。
CIは、知られているシークレットパターンを拒否し、カスタム暗号化codeをフラグし、署名ステップを検証し、バンドル内容を検査し、ストレージまたはトランスポート設定が変更されたときにセキュリティレビューを必要とする自動リリースルールに各ハード化された実践を変換します。目的は、依存関係として出荷される前に悪い決定をキャッチすることです。
すべてを組み合わせて暗号化計画に
暗号化計画は、エンジニアリング契約のように読まなければなりません。アプリケーションが保護するもの、キーがどの場所に存在するか、コンポーネントが平文を参照できるか、チームが制御が有効であることを証明する方法を記載する必要があります。
始めると データ分類. センシティブ性と保持期間の必要性に応じて、レコード、トークン、ドキュメント、ログ、キャッシュ、バックアップ、分析フィールドをマークします。ローカルコピーを最小限に抑える前にアルゴリズムを選択します。デバイスに到達しないデータには、デバイスストレージ設計が必要ありません。
次に、ストレージとトランスポートの決定をドキュメントします:
- 静的スキーム: 認証付き暗号化、プラットフォーム管理されたキー ストレージ、保護されたファイルの場所、バックアップの動作、および削除またはゼロ化のハンドリングを選択します。
- 動的プロトコル: TLS構成、証明書検証、エンドポイントポリシー、および脅威モデルに適切であるかどうかを定義し、ピンニングを定義します。
- 鍵保管: 生成、参照、配布、回転、削除、回復、緊急置換手続き。
- Code と実行時制御: どのオブスキュレーション、完整性チェック、証明、デバッガー検出、敏感画面保護が貢献するかを決定する。
- 監査証拠: 構成のインベントリ、参照ログ、リリース承認、テスト結果、インシデントレコード、例外をキャプチャする。
順序は重要です。データ分類は保護する必要があるものを決定します。 その決定は、ストレージと鍵保管を形作ります。 その後、信頼できるサービスとクライアントの間のパスを保存するために、輸送と更新制御が実行されます。 Capacitor と Electron チームは、各ターゲットごとにこのレビューを繰り返す必要があります。 そうすることで、ネイティブ iOS の鍵ストア、Android のハードウェアバックアップオプション、ブラウザのストレージ API、およびデスクトップのクレデンシャルファシリティは、同等の保証を提供しないからです。
更新チャネルはこの計画の中に含まれるべきであり、計画の後に含まれるべきではありません。署名されたリリースは code の完整性を保存することができ、制御されたターゲット、ロールバック保護、リリースの観察性は、チームが脆弱なビルドまたは構成がユーザーに到達したときに、対応することができます。 この計画をレビューする必要があるのは、アプリがオフラインデータを追加したとき、ストレージ プラグインを変更したとき、バックエンドの許可を新しく導入したとき、または更新が署名され、配信される方法を変更したときです。
CapgoはCapacitorJSおよびElectronアプリケーション向けに署名されたライブアップデートを提供し、JavaScriptcodeとアセットの暗号化されたバンドルサポート、リリースチャンネルの制御、ロールバック保護、デバイスごとのアップデート観察性を提供します。Visit Capgo ライブアップデートの評価に参加してください。
