API
__CAPGO_KEEP_0__ データ保護のためのチームの決定は、データが保存されているときに保護される方法、システム間でデータが移動する方法、キーがどの場所に存在するか、攻撃者がアプリケーション パッケージから何を学ぶことができるか、ランタイムが詐欺にどのように反応するか、署名された更新がそれらの保証を維持する方法についてです。有効な開始点は、敏感なデータ、信頼の境界、クライアントの機能、可能性のある悪用パスをマッピングするアプリケーションリスクアセスメントです。 アプリケーションリスクアセスメント モバイルとクロスプラットフォームアプリケーションは、通常よりも特に脆弱な環境にあります。デバイスはオフィスを離れ、ビルドはコピーまたはサイドロードされ、ローカルファイルは検査され、逆アセンブルツールは広く利用可能です。以下のセクションでは、保存と輸送からプラットフォームキー保護、クライアントサイドシークレット、コンプライアンス、リリースオペレーションまで、モデルを段階的に構築します。
目次
アプリケーション暗号化の重要性
- リストア中の暗号化と移動中の暗号化
- リストア中の暗号化
- iOS、Android、Code、Electronのプラットフォームに関する考慮事項
- Platform Considerations for iOS, Android, Capacitor, and Electron
- 鍵管理とクライアントサイドの機密性の限界
- 規制と法的要件の意味
- 共通の誤りとハード化されたベストプラクティス
- すべてを組み合わせて暗号化計画
アプリケーション暗号化の重要性
ウェブアプリケーションは、組織が制御するインフラストラクチャ上に多くの敏感なロジックと秘密情報を保持します。モバイルアプリケーションは、code、資産、構成、データハンドリングロジックを、誰かの所有するデバイスに送信します。エレクトロンアプリケーションは、類似の問題があります。なぜなら、そのJavaScript、リソース、パッケージされたファイルは、実行アプリケーションを実行できるユーザーによって検査できます。
セキュリティ境界が変わる クライアントは便利ですが、安全な宝箱ではありません。 暗号化は、無意識の検査から情報を保護し、盗まれたファイルを利用できないようにしますが、アプリケーションは、ある程度の時点で平文にアクセスする必要があります。デバイスを制御する攻撃者は、入力値を観察する、メモリを検査する、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オプションと、暗号化ファイルを管理するのに役立つライブラリを提供しています。デスクトップアプリケーションは、オペレーティングシステムのクレデンシャルとローカルアクセス制御に依存しています。Chromium Embedded Framework環境でファイルを取り扱うチームは、 CEFドキュメントの保存に関するベストプラクティスを参照してください これにより、シフラの境界を超えたストレージの境界を検討することができます。
移動中の暗号化
移動中の暗号化は、ネットワークを渡ってリクエストとレスポンスを保護します。適切に構成されたTLS接続は、中間者がアプリケーショントラフィックを読み取ったり変更したりするのを防ぎますが、クライアントがサーバーを正しく検証し、バックエンドが信頼された証明書を提示する場合にのみ機能します。証明書の検証を無効にしたり、安全なフォールバックを使用したり、誤って明示的なクリアテキストエンドポイントを使用したりすると、意図された保護を損なう可能性があります。
証明書ピンニングは、特定のモバイルシナリオで、チームが証明書の操作を制御し、回転の回復計画を持っている場合に、別の検証レイヤーを追加できます。ただし、正しいTLSの代わりではありません。誤ったピンは、有効なユーザーをブロックする可能性があります。Capacitorで構築しているチームは、 Capacitorアプリ用のSSLピンニングを検討する ピンニングの運用上のトレードオフが、自分のアプリケーションに合っているかどうかを判断する前に、
失敗モードは補完的です。Transport Securityは、紛失したデバイスからデータベースをコピーした場合に保護されません。Storage Encryptionは、妨害された接続を通じてパスワードを送信した場合に保護されません。両方のパスを設計し、テストし、プレーンテキストが現れるポイントをテストするには、ログ、スクリーンショット、テンポラリファイル、クラッシュレポート、クリップボードコンテンツ、同期キューを含めます。
Code、データ、シークレットの保護
チームは、同じ制御を表すように「暗号化」、「オブフュージョン」、「ハーデニング」を使用することがよくありますが、実際にはそれらは異なる制御です。混同は、誤った自信を生み出します。
オブフュージョンと最適化 codeを読むのが難しくします。アプリケーションをクローンするコストやビジネスロジックを理解するコストを上げることができますが、秘密をアプリケーションが使用する必要がある場合に秘密を利用できないようにすることはできません。APIキーがJavaScriptバンドルに含まれている、署名資格がアーカイブに含まれている、予測可能な関数によって再構築された値が含まれている場合でも、引き出せることができます。HermesバイトコードとElectron asar アーカイブはソースファイルよりも検査が不便になるかもしれませんが、パッケージングは秘密とは同じではありません。
データ暗号化 ユーザー コンテンツとローカル クレデンシャルを保存中に保護します。プラットフォームの暗号化 API とキーの Keychain、Keystore、Secure Enclave、StrongBox、または利用可能な場合の等価なオペレーティング システムの機能で保持する必要があります。OWASP の暗号化テスト ガイドラインは、ソース code にパスワードまたはキーを置かないように警告し、クライアント上のシークレットが抽出されることを強調しています。OWASP MASTG暗号化テスト).
実行時保護 ジャイルブレイクやルート信号、デバッガー検出、実行環境の検証、証明書検証など、攻撃をより難しくする条件や自動化されたアビューズのリスクを高める条件を探します。ただし、信頼できるデバイスにするものではありません。決意のある攻撃者はチェックを変更し、正当なユーザーはヒューリスティックをトリガーする可能性があります。
| 保護層 | 保護対象 | 対象外 |
|---|---|---|
| Code オブフュージョン | アプリケーション ロジックの読みやすさと無作為の複製 | アプリケーションがアクセスできるシークレットの抽出 |
| データ暗号化 | 選択された保存データの機密性と完全性 | 有効なデコード後、平文の露出 |
| 実行時保護 | 一部の改ざん、デバッグ、自動的な悪用 | 実行環境を制御する高度な攻撃者 |
より安全な設計では、サーバー上で高価なシークレットを保持し、クライアントに狭いスコープの資格情報を与え、オフラインアクセスが必要なローカルデータのみを暗号化します。トークンストレージには、有効期限、削除、更新、プラットフォームバインディングの動作を含む独自のレビューが必要です。 モバイル開発者向けの安全なトークンストレージガイド 実装要件にそれらの決定を転換するのに役立ちます。
無知なアプローチは失敗することがあります。なぜなら、それらは秘密のライフサイクルではなく、秘密の外観を保護しているからです。ソースcodeで値をXORする、キーを複数のファイルに分割する、またはJavaScriptのミニファイションに依存することは、実行中のアプリケーションが値を再構築して使用する必要があることを変えることはありません。
iOS、Android、Capacitor、Electron向けのプラットフォーム考慮事項
同じ暗号化設計は、各プラットフォームが異なるキーストア、API、隔離境界、復元メカニズムを公開しているため、実行環境によって異なる動作を示します。クロスプラットフォームの抽象化は、アプリケーションcodeを簡素化できるかもしれませんが、異なる差異を消去することはできません。
ネイティブモバイルプラットフォーム
iOSでは、Keychainは保護された資格情報の保存を提供し、 Secure Enclave 主なアプリケーションプロセッサから特定のキー操作を分離できる。アプリケーションは、利用性の要件に合ったアクセス制御を選択する必要があります。たとえば、デバイス認証後にデータが利用可能になるか、ユーザーが認証した後にのみ利用可能になるかなど。
Android Keystoreはサポートされているデバイス上でハードウェアバックアップされたパスを提供し、 StrongBox 利用可能な場合、より強固な隔離された環境を提供できます。Androidチームは、デバイスの機能、バックアップの動作、認証要件、および証明信号を考慮する必要があります。ハードウェアのサポートは均一ではないため、アプリケーションには定義されたフォールバックポリシーが必要であり、すべてのデバイスが同等の保護を提供することを前提にしないようにします。
クロスプラットフォームシェル
Capacitorアプリケーションは、Webcodeとネイティブプラットフォーム機能をブリッジで組み合わせます。そのブリッジはセキュリティの境界であり、単に便利な層ではありません。 localStorageIndexedDBや通常のWebプリファレンスは、デフォルトでは暗号化されたシークレットストアとして扱うべきではありません。チームは、ネイティブストレージプラグインを選択するか、プラットフォームの保護されたキー機能を使用するネイティブモジュールを実装する必要があります。
Electronには別の脅威モデルがあります。レンダラーはWebコンテンツを処理し、メインプロセスにはより広い特権があります。敏感な操作は、公開されたレンダラーから外に出す必要があります。Electronの safeStorage OSのクレデンシャル保護機能を利用できますが、結果はホストOS、ユーザーアカウント、デスクトップ設定、プロセス隔離に依存します。キーは、モバイルプラットフォームが保護されたキーを隔離する方法と同様に、自動的にハードウェア隔離されません。
| プラットフォーム | キーストレージ | APIの暗号化 | デフォルトの脅威モデル |
|---|---|---|---|
| iOS | Keychainと、サポートされている場合のSecure Enclave | Appleプラットフォームの暗号化とData Protection | デバイスとアプリケーションは別々ですが、侵害されたデバイスまたはランタイムが使用を観察できる |
| Android | Keystoreと、サポートされている場合のStrongBox | Androidプラットフォームの暗号化とJetpackセキュリティコンポーネント | ハードウェアとソフトウェアの機能はデバイスによって異なります。 |
| Capacitor | Native storage selected through plugins or custom bridge code | Web APIとネイティブプラットフォームAPI | Webアセットはネイティブシェル内で実行され、安全なストレージを自動的に継承しない |
| エレクトロン | OS認証機能を提供するAPI safeStorage |
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 World のモバイルアプリリスクに関するレポート)
| 共通の落とし穴 | ハードコーディングされた __CAPGO_KEEP_0__ キーまたは暗号化キーをソース、バイトコード、またはバンドルに |
|---|---|
| Hardcoding API keys or encryption keys in source, bytecode, or bundles | SQLite データベースを暗号化しながら、平文キャッシュ、エクスポート、ログ、またはバックアップを残す |
| 機密データのすべてのコピーをインベントリ化し、臨時アーティファクトに同じストレージポリシーを適用 | 通常のウェブストレージにリフレッシュトークンを保存する |
| プラットフォームバックアップされた資格情報ストレージを使用し、トークンスコープを狭め、サーバーサイドの削除をサポート | カスタム暗号化またはキーオブフュージケーションを実装する |
| Common Pitfall | 信頼できるプラットフォーム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とアセットの暗号化されたバンドルサポート、制御されたリリースチャンネル、ロールバック保護、デバイスごとのアップデート観察性を提供します。 Capgo Martin Donadieu
