モバイルアプリとクロスプラットフォームチーム向けのアプリ暗号化の解説

アプリの暗号化は、設計されたセキュアなモバイルワークフローを設計するのに月単位の時間を費やしたヘルスケアスタートアップが、テスターの電話がジャイルブレックされていた場合に、パーソナルデータがスクリーンショットやローカルキャッシュを通じて漏洩するのと同じです。同時に、チームのElectron管理パネルを含むデバッグビルドが、APIキーの埋め込みを含むパッケージを配信した場合もあります。両方のインシデントは暗号化に関連していますが、どちらも暗号化ライブラリを追加することで解決されません。

アプリの暗号化は、決定のシステムです。 データ保護のためのチームは、データが保存されているときに保護される方法、システム間でデータがどのように移動するか、キーがどこに存在するか、攻撃者がアプリケーション パッケージから何を学ぶことができるか、ランタイムが改ざんに対してどのように反応するか、署名されたアップデートがそれらの保証を維持する方法について決定する必要があります。有効な開始点は、敏感なデータ、信頼境界、クライアント機能、そして可能性のある悪用パスをマッピングするアプリケーションリスクアセスメントです。 アプリケーションリスクアセスメント モバイルとクロスプラットフォームアプリケーションは、通常よりも特に脆弱な環境にあります。デバイスはオフィスを離れ、ビルドはコピーまたはサイドロードされ、ローカルファイルは検査され、逆アセンブルツールは広く利用されています。以下のセクションでは、ストレージとトランスポートからプラットフォームキー保護、クライアントサイドシークレット、コンプライアンス、リリースオペレーションまで、モデルを段階的に構築します。

目次

アプリケーション暗号化の重要性

• リストア中の暗号化と移動中の暗号化
• リストア中の暗号化
  • 移動中の暗号化
  • アプリケーション内の__CAPGO_KEEP_0__、データ、シークレットの保護
• iOS、Android、Code、Electronのプラットフォームに関する考慮事項
• Platform Considerations for iOS, Android, Capacitor, and Electron
  • アプリケーション暗号化の重要性は今よりも大きくなっています。
  • クロスプラットフォームシェル
• クライアントサイドシークレットの限界とキー管理
• 規制と法的要件
• 共通の誤りと強化されたベストプラクティス
• 暗号化計画にすべてを組み込む

アプリケーション暗号化の重要性

ウェブアプリケーションは、組織が制御するインフラストラクチャ上に多くの敏感なロジックと秘密情報を保持します。モバイルアプリケーションは、code、資産、構成、データハンドリングロジックを、別の人が所有するデバイスに送信します。エレクトロンアプリケーションは、同様の問題があります。なぜなら、そのJavaScript、リソース、パッケージファイルは、実行アプリケーションを実行できるユーザーによって検査できます。

セキュリティ境界が変わります。 クライアントは便利ですが、セキュリティのためのVaultではありません。 暗号化は、無作為の検査から情報を保護し、盗まれたファイルが有用性を失うようにしますが、アプリケーションは、ある程度の時点で平文にアクセスする必要があります。デバイスを制御する攻撃者は、入力値を観察する、メモリを検査する、APIをインストルメントする、または実行を変更することができます。

医療の例を考えてみましょう。データベースを暗号化すると、ディスクからコピーされたレコードを保護できますが、コンパウンドされたランタイムから表示された暗号化されたレコードを防ぐことはできません。ネットワークトラフィックを暗号化すると、クリニックのリクエストを保護できますが、ローカルに保存された非保護キャッシュから保護することはできません。ミニファイズされたJavaScriptに隠されたキーは、必要に応じて使用する場合に回復可能です。

実用的なルール: すべてのクライアント側の保護を、信頼できるデバイスであると考えるのではなく、露出を減らす層として扱う。

通常の設計では、以下の要素を組み合わせる。

• 静的保護データベース、ファイル、キャッシュ、設定、ダウンロードしたドキュメントなど、静的データの保護。
• 動的保護リクエスト、同期、更新配信、サービス間通信など、動的データの保護。
• プラットフォームキーストレージ暗号化キーが通常のアプリケーションファイルに残らないようにするため。
• Code と実行時保護オブフュージョン、整合性チェック、デバッグ対策、適切な証明書検証などを含む。
• 制御された更新チャネル署名されたリリースは、前のバージョンに組み込まれたセキュリティ上の仮定を維持する必要があるため。
• ドキュメントされたコンプライアンスコントロール、所有権、証拠、監視、対応手順を含む。

規制義務は圧力をかけますが、エンジニアリングの規範も改善します。GDPR、HIPAA、PCI DSS、SOC 2は暗号化をuniversalチェックボックスに変えるのではなく、チームが保護するものを理解し、鍵の制御方法、そして安全対策が意図どおりに機能することを示す方法を理解することを要求します。

リストア対移動の暗号化

信頼性の高い文書を郵便で送信したとします。封筒が封印されている間、メッセージは送信者と受信者間を移動します。受信者が封筒を開けた後、文書はまだ安全なファイルカビネットが必要です。 移動の暗号化は移動を保護します。リストアの暗号化は保存を保護します。 封筒とファイルカビネットは異なる問題を解決します。

リストアの暗号化

リストアの暗号化は、デバイス、サーバーディスク、バックアップ、データベース、または外付けボリュームにデータが保存されているときに適用されます。モバイルプラットフォームでは、オペレーティングシステムの保護はデバイスの一部を暗号化することができますが、安全な保存場所、アクセス制御、鍵の使用を選択するにはアプリケーションは依然として必要です。敏感なアプリケーションファイルは、プラットフォームサポートされた暗号化と鍵を保護されたストアに保持するのではなく、暗号化されたデータの横に書かれた鍵を使用しないようにします。

認証された暗号化はここで重要です。OWASPは、プラットフォーム暗号化API、ハードウェアバックアップされた鍵ストレージが利用可能な場合、認証モードであるAES-GCMまたはAES-CCMを推奨しています 認証された暗号化はここで重要です。OWASPは、プラットフォーム暗号化API、ハードウェアバックアップされた鍵ストレージが利用可能な場合、認証モードであるAES-GCMまたはAES-CCMを推奨しています、データの盗難や改ざんを検出するのに役立つだけでなく、コンテンツを隠すこともできます。同様のガイドラインでは、静的データと動的データの両方を保護することを推奨し、プライベートなデータを内部ストレージに格納し、プラットフォームの実装を優先することで、独自の暗号化アルゴリズムを使用しないことを勧めています（OWASPモバイルアプリケーションセキュリティのチートシート).

実際の詳細はプラットフォームによって異なります。iOSはData ProtectionとKeychainサービスを提供します。AndroidはKeystore-backedオプションと、暗号化されたファイルを管理するのに役立つライブラリを提供します。デスクトップアプリケーションは、オペレーティングシステムのクレデンシャルとローカルアクセス制御に依存します。CEF環境でファイルを取り扱っているチームは、 CEFドキュメントの保存に関するベストプラクティスを確認する 暗号化の境界を超えて、シーカー自身の境界を検討する

動的データの暗号化

動的データの暗号化は、ネットワークを渡るリクエストとレスポンスを保護します。適切に構成されたTLS接続は、中間者がアプリケーショントラフィックを読み取ったり変更したりするのを防ぎますが、クライアントがサーバーを正しく検証し、バックエンドが信頼された証明書を提示する場合にのみ機能します。証明書の検証を無効にしたり、安全なフォールバックを無効にしたり、誤って明示的なクリアテキストエンドポイントを使用したりすると、意図された保護を損なう可能性があります。

Certificate pinning can add another verification layer in selected mobile scenarios, especially where the team controls certificate operations and has a recovery plan for rotation. It isn’t a replacement for correct TLS, and an incorrect pin can block legitimate users. Teams building with Capacitor can examine Capacitorアプリ用のSSLピン設定 SSLピン設定を実施する前に、__CAPGO_KEEP_0__アプリの運用上のトレードオフを検討する必要があります。

エラーの発生モードは補完的です。Transport Securityは、紛失したデバイスからコピーされたデータベースを保護しません。Storage Encryptionは、コンプロミットされた接続を通じて送信されたパスワードを保護しません。両方のパスを設計し、テストし、プレーンテキストが表示されるポイントを検討してください。ログ、スクリーンショット、テンポラリファイル、クラッシュレポート、クリップボードコンテンツ、同期キューを含みます。

Code、データ、シークレットの保護

チームは、単に同じ制御を表すと考えている「暗号化」、「オブフュージョン」、「ハーデニング」を使用することがよくあります。実際には、それらは異なる攻撃者アクションを対処するものです。混同は、誤った自信を生み出します。

オブフュージョンとミニファイ codeを読みにくくします。アプリケーションのクローン化やビジネスロジックの理解のコストを上げることができますが、秘密をアプリケーションが使用する必要がある場合には、秘密を利用できないようにしません。APIキーがJavaScriptバンドルに含まれている、署名資格がアーカイブに含まれている、予測可能な関数によって再構築された値が含まれている場合でも、引き出しが可能です。HermesバイトコードとElectron asar アーカイブはソースファイルよりも検査が不便になるかもしれませんが、パッケージングは秘密とは同じではありません。

データ暗号化 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 (OWASP MASTG暗号化テスト).

実行時保護 攻撃や自動化された悪用の可能性を引き起こす条件を探します。ジャイルブレイクとルートの信号、デバッガー検出、適用性の確認、証明書検証など、攻撃を難しくするか、応答信号を提供することができます。どれも、デバイスを信頼できるものにすることはありません。決意のある攻撃者はチェックを変更し、有効なユーザーはヒューリスティックをトリガーする可能性があります。

より安全な設計では、サーバー上で高価な秘密を保持し、クライアントに狭いスコープの資格情報を与え、オフラインアクセスが必要なローカルデータのみを暗号化します。トークンストレージには、有効期限、削除、更新の動作、およびプラットフォームのバインディングのレビューが必要です。 モバイル開発者向けの安全なトークンストレージガイド 実装要件にそれらの決定を転換するのに役立ちます。

Naive approaches fail because they protect the appearance of secrecy rather than the secret’s lifecycle. XOR-ing a value in source code, splitting a key across several files, or relying on JavaScript minification doesn’t change the fact that the running application must reconstruct and use the value.

iOS、Android、Capacitor、およびElectronのプラットフォームに関する考慮事項

The same encryption design behaves differently across runtimes because each platform exposes different key stores, APIs, isolation boundaries, and recovery mechanisms. A cross-platform abstraction can simplify application code, but it can’t erase those differences.

ネイティブモバイルプラットフォーム

iOSでは、Keychainは保護された資格情報の格納を提供し、 Secure Enclave 主なアプリケーションプロセッサから特定のキー操作を分離できる。

アプリケーションは、利用性の要件に合ったアクセス制御を選択する必要があります。例えば、デバイス認証後にデータが利用可能になるか、ユーザーが認証した後にのみ利用可能になるかなど。 Android Keystoreはサポートされるデバイスでハードウェアバックアップされたパスを提供し、 StrongBox

利用可能な環境を提供します。Androidチームは、デバイスの機能、バックアップの動作、認証要件、証明信号などを考慮する必要があります。ハードウェアのサポートは均一ではないため、アプリケーションは、すべてのデバイスが同等の保護を提供することを前提にしないでください。代わりに、明確なフォールバックポリシーを定義する必要があります。

Capacitor applications combine web code with native platform capabilities through a bridge. That bridge is a security boundary, not merely a convenience layer. localStorage__CAPGO_KEEP_0__アプリケーションは、Web__CAPGO_KEEP_1__とネイティブプラットフォームの機能をブリッジを介して組み合わせます。そのブリッジはセキュリティの境界であり、単に便利な層ではありません。

IndexedDBや通常のWebの設定は、デフォルトでは暗号化された秘密の格納庫として扱うべきではありません。チームは、ネイティブストレージプラグインを選択するか、またはプラットフォームの保護されたキー機能を使用するネイティブモジュールを実装する必要があります。 safeStorage OSのクレデンシャル保護を利用できますが、結果のセキュリティはホストOS、ユーザーアカウント、デスクトップ設定、プロセス隔離に依存します。キーは、モバイルプラットフォームが保護されたキーを隔離する方法と同様に、自動的にハードウェア隔離されません。

チームは、各ターゲットごとに動作をドキュメント化し、製品を「すべてのプラットフォームで暗号化されている」と説明するのではなく プラットフォームの差異に対する Capacitor のアプローチ プラットフォーム固有の決定が明らかになる場所としてブリッジをフレームする

クライアントサイドの秘密の限界と鍵管理

暗号化は、鍵管理が鍵を保護する場合にのみデータを保護します。有用なライフサイクルには、5つの段階があります。 生成、配布、保存、回転、削除。各段階は異なる障害モードを生じます。

信頼できるプラットフォームまたはサーバー暗号化APIで鍵を生成します。bundleに埋め込むのではなく、認証済みプロトコルを通じて配布します。可能な場合、保護されたプラットフォームファシリティで保存します。ポリシー、リスク、暗号化要件によって要求される場合に回転します。サーバー制御の認可を通じて、デバイス、アカウント、またはセッションがデータを復号する権限を削除します。

クライアントは、これらの操作ではインフラストラクチャよりも弱いです。ユーザーがデバイスを制御し、潜在的にアプリケーション状態を検査できるためです。ユーザーが生成したパスフレーズで保護されたオフラインデータに対して、クライアントが保持する鍵は意味をなすかもしれません。ただし、製品が回復とユーザビリティの影響を受け入れることを認識している場合です。API トークンが広範なバックエンドアクセスを許可する場合、ローカルデータベースを暗号化することによって、トークンがリモートで行うことができることの制限にはなりません。

データ暗号化では、データ暗号化キーとマスターキーを分離します。アプリケーションは、短期間のデータキーでローカルオブジェクトを暗号化できます。サーバーサイドのキー管理サービスまたはHSMバックアップシステムは、ラッピングキーを保護します。リモートキーリリース設計では、デバイス、ユーザー、ポリシー決定、または証明信号が認証されたデバイスに必要な材料をリリースする必要があります。これらのパターンは、侵害されたクライアントを安全にしないですが、デバイスに永久に座っている権限の割合を減らします。

OWASPは、ローカルに敏感なデータを個人情報、暗号化された材料、シークレット、APIキーの個人情報として特定しています。暗号化は、ライフサイクル制御として安全なローカルストレージ、キー回転、使用後ゼロ化と関連付けられます。アーキテクチャ的原則は簡単です。

重要なシークレットをチームが管理するシステムに保管し、クライアントに現在のタスクに必要な最小限の権限を与えます。

リリースシステムの場合、キー管理はアップデートの署名と配信にも適用されます。チームは、誰がバンドルを署名できるか、署名資格情報がどこに保管されているか、どのようにアクセスが監査されるか、どのように署名資格情報が侵害された場合に置き換えられるかを定義する必要があります。キー管理の指針は OTAアップデートのセキュリティを確保するための指針 アプリケーション暗号化とアップデートライフサイクルを関連付けることができます。

規制と法的影響

{"text":"Compliance teams don’t usually accept the statement \"the app uses encryption\" as sufficient evidence. They ask what data is covered, which algorithms and protocols are active, who controls the keys, how access is restricted, and how the organization detects configuration drift.","context":"blog"}

{"text":"GDPR Article 32 treats encryption as an appropriate technical measure for reducing risk, as reflected in the European Union’s GDPR text. The obligation is risk-based, so the organization still needs to connect its safeguards to the nature of the personal data and processing environment. A mobile app that handles medical information, identity data, or financial records needs a defensible explanation of local storage, transport, access, and incident response.","context":"blog"}

{"text":"HIPAA’s Security Rule treats encryption for electronic protected health information as an addressable safeguard rather than a universal technical checkbox. That means a covered entity or business associate should assess whether encryption is reasonable and appropriate, document the decision, and apply alternative measures where it doesn’t implement the safeguard. The HHS Security Rule guidance provides the governing context.","context":"blog"}

{"text":"PCI DSS separates stored cardholder data from transmission across open networks. Teams should map encryption decisions to the applicable requirements and avoid storing payment data unnecessarily. The PCI Security Standards Council document library is the appropriate place to verify the current wording and scope.","context":"blog"}

SOC 2 の監査者は、制御が正常に動作していることを証明するための証拠に焦点を当てます。 その証拠には、鍵管理ポリシー、TLS の構成、シーカーの一覧、ログアクセス、変更承認、インシデントレコード、テスト結果、および署名されたリリースが意図されたプロセスに従っていることを証明する証拠が含まれます。 監視されていない制御は、有効な動作を示すことはできません。

共通のテーマは 証明可能性。 アプリケーション暗号化を実装する際に証拠の連鎖を構築するのではなく、審査の週前に行うことです。

共通の誤りと強化されたベストプラクティス

暗号化の失敗はほとんどの場合、通常のエンジニアリングの決定から始まります。 開発者は起動時にトークンが必要であると考える、チームはオフライン検索が速く感じたい、またはリリースプロセスがホットフィックスを迅速に配布したいと考えることがあります。 しかし、短絡が信頼モデルの一部となるとリスクが生じます。

最近のモバイルリスク調査では 60%以上の評価されたアプリが機密データのための不安全または古い暗号化を使用していることを報告しました、 約 1/3 が初期化ベクトルを再利用 、そして 20%がハードコードされた静的値を使用している その発見は、”アプリが暗号化しているか？”という質問から、「実用的な使用状況下で機密性と完整性を維持できる実装が可能か？”という質問に変える。モバイルアプリリスクに関するSCワールドレポート)

別の脅威レポートでは、SignalとWhatsAppアカウントをスパッフォングアプリケーションと電話の下で悪用するスパイウェアグループが標的となっていることを記載した。同レポートは、 2025年上半期に比べて2024年上半期に比べて29%増加したAndroidスマートフォン攻撃についてのモバイル脅威アセスメントを記載した (The RegisterがCISAに関連するレポートのカバレッジを掲載した. その教訓は、暗号化が失敗したことではありません。攻撃者は、保護されたシフタテキストを回避できるレイヤーであるデバイス、アカウント、セッション、またはアップデートパスを選択することがよくあります。

CI は、知られているシークレットパターンを拒否し、カスタム暗号化 code をフラグし、署名ステップを検証し、バンドル内容を検査し、ストレージまたはトランスポート設定が変更されたときにセキュリティレビューを必要とする自動リリースルールに各ハード化された実践を変換する必要があります。目的は、依存関係として出荷される前に悪い決定を捕捉することです。

すべてを組み合わせて暗号化計画に

暗号化計画は、エンジニアリング契約のように読まなければなりません。アプリケーションが保護するもの、キーが保存されている場所、プラインテキストを表示するコンポーネント、チームが各リリース後にもう一度制御が有効であることを証明する方法を説明する必要があります。

始めましょう。 データ分類. センシティブ性と保持期間の必要性に基づいて、レコード、トークン、ドキュメント、ログ、キャッシュ、バックアップ、分析フィールドをマークします。ローカルコピーを最小限に抑える前に、アルゴリズムを選択します。デバイスに到達しないデータには、デバイスストレージ設計が必要ありません。

次に、ストレージとトランスポートの決定をドキュメントします:

1. 静的ストレージスキーム: . 認証付き暗号化、プラットフォーム管理されたキー ストレージ、保護されたファイルの場所、バックアップの動作、削除またはゼロ化のハンドリングを選択します。
2. 移動中のプロトコル: . TLS の構成、証明書の検証、エンドポイントポリシー、脅威モデルに適切であるかどうかを定義し、ピンニングを定義します。
3. 鍵保管: 生成、参照、配布、回転、削除、復元、緊急置換手続き。
4. Code と実行時制御: どのオブフュージョン、完整性チェック、証明、デバッガー検出、敏感画面保護が貢献するかを決定する。
5. 監査証拠: 構成のインベントリ、参照ログ、リリース承認、テスト結果、インシデントレコード、例外をキャプチャする。

順序は重要です。データ分類は保護する必要があるものを決定します。 その決定は、ストレージと鍵保管を形作ります。 その後、信頼できるサービスとクライアントの間のパスを保存するために、輸送と更新制御が実行されます。 Capacitor と Electron チームは、各ターゲットごとにこのレビューを繰り返す必要があります。 そうすることで、ネイティブの iOS キーストア、Android ハードウェアバックアップオプション、ブラウザ ストレージ API、およびデスクトップ認証情報の保管庫は、同等の保証を提供しません。

アップデートチャンネルはこの計画の中にあります。 それが終わった後ではありません。署名されたリリースは code の完整性を保存できます。 また、制御されたターゲット、ロールバック保護、リリースの観察性は、脆弱なビルドまたは構成がユーザーに到達したときにチームが対応できるようにします。 この計画をレビューする必要があるのは、アプリがオフラインデータを追加したとき、ストレージ プラグインを変更したとき、バックエンドの許可を新しく導入したとき、またはアップデートが署名され、配信される方法を変更したときです。

CapgoはCapacitorJSおよびElectronアプリケーション向けに署名されたライブアップデートを提供し、JavaScriptcodeとアセットの暗号化されたバンドルサポート、制御されたリリースチャンネル、ロールバック保護、デバイスごとのアップデート観察性を提供します。Visit Capgo ライブアップデートの評価に参加して、制御されたアップデートパスがアプリケーション暗号化とリリース管理計画をサポートする方法を評価してください。