モバイルアプリの秘密鍵を保護できない場合はどうすればよいですか？
IOS用のモバイルアプリがあり、Android AppleおよびGoogle Playストアで入手できます。アプリはHTTPS経由でサーバーのWebサービスと通信します。
アプリのトラフィックを偽装できる攻撃者がいます。これはおそらく、攻撃者が Fiddler などのツールを使用してHTTPSで暗号化されたWebサービスの要求/応答を復号化および監視していることを意味します。
次のステップは、モバイルアプリ内を暗号化することです。 HMACでCBCモードのAESを使用して、双方向でWebサービスペイロードを暗号化します。これは、サーバーとダウンロード可能なモバイルアプリの両方が共有の秘密鍵（実際には、少なくとも2つ）を持っていることを意味します。
問題は、iOSまたはAndroidモバイルアプリをリバースエンジニアリングして秘密鍵を取得することはかなり可能であることです。確かに、私たちはより高いレベルのセキュリティを持っています。リバースにはより多くの専門知識が必要です。 Fiddlerを介してHTTPSトラフィックを監視するよりもモバイルアプリを設計します。
私たちは、秘密鍵の取得に悩む誰にとっても十分に大きなターゲットではないかもしれません。しかし、攻撃が価値のあるところまで成長したいと思います！
私が知っているすべての鍵交換プロトコルでは、モバイルアプリがプロセスのどこかに秘密鍵を持っている必要があります。アプリはApple App StoreとGoogle Playから無料でダウンロードできますが、その秘密を秘密にしておく方法はありません。
Arxan.com 攻撃者になる可能性のある人からキーを隠すのに十分に複雑なプロセスのように見えるエンタープライズグレードのソリューションを提供すると主張しています。価格について質問する準備がまだできていません。
一見したところ、私の質問は、「実際のモバイルアプリで秘密キーを保護するにはどうすればよいですか？」私は2つの明確な答えを見てきました。
- できません。
- HTTPSを使用します。ただし、これを行っているため、トラフィックが引き続き監視されていることは明らかです。
したがって、私の質問は承認ではなく認証の1つになると思います。サーバー側では、モバイルアプリを装った攻撃者とアプリからの正当なトラフィックをどのように区別すればよいですか？
HMACを暗号化して正しく使用していると仮定すると、有効なメッセージで次のことがわかります。
- メッセージは変更されていません。
- 送信者が共有秘密鍵を所有しています。
この時点までのすべては、秘密鍵が危険にさらされていないことに依存しています。
これまでに考えた唯一の答えは、トラフィック分析です。ブルートフォース攻撃トラフィックおよびその他の特定のトラフィックプロファイルを検出します。さまざまな形のリプレイ攻撃を検出します。
このようにして、秘密鍵が侵害されたと推測し、その鍵を無効化することができます（したがって、実際のすべてのモバイルインストールが無効化されます）。しかし、攻撃者が1つの秘密鍵を見つけ出すことができれば、その攻撃者が次の鍵も見つけ出すことができるのは当然のことです。また、正当なインストール済みアプリのユーザーベース全体を無効にしたくありません。
アプリ内に証明書をインストールできますが、それで問題は解決しますか？もしそうなら、どのように？アプリにリバースエンジニアリングとスプーフィングが行われるという同じ問題はありませんか？
編集：何を保護しようとしていますか？
攻撃者は、アプリのユーザーログインWebシーケンスを偽装して、パスワードリストを実行することができます。攻撃者はアプリを終了するときにHTTPSトラフィックを監視できるため、攻撃者はWebサービス要求と認証を構築する方法を知っています。
アプリを離れる前に、ログイン（およびその他の）情報を暗号化できます。これにより、攻撃者が暗号化で使用される秘密鍵を所有していないと想定して、スニッフィングとスプーフィングの両方を防ぐことができます。
（サーバーへの）インバウンドトラフィックを保護することがより重要であることを考えると、公開鍵暗号化は可能性があります。サーバーのみがそれを復号化できました。ただし、キーは公開されているため、攻撃者はアプリを装ったパスワードリストを実行する可能性があります。
では、何を保護しようとしているのでしょうか。攻撃者がWebサービスを介してユーザーアカウントに侵入することから身を守ろうとしています。具体的には、モバイルアプリを実際にリバースエンジニアリングするのに十分な動機を持つ攻撃者からどのようにして身を守ることができるでしょうか。
2番目の編集：問題をもう一度説明してみましょう。
堅牢で安全なWebサービスAPIをどのように設計すればよいでしょうか？攻撃者になる可能性のある人による観察に耐えることができなければなりません。攻撃者になる可能性のあるユーザーからの偽のメッセージを区別して拒否できる必要があります。
具体的には、次のことを行います。
攻撃者がWebサービスAPIを使用してパスワードリストを実行し、場合によってはメンバーアカウントにログインできないようにします。他にもブルートフォース検出対策を講じていますが、このような攻撃から直接APIを保護したいと考えています。
攻撃者がWebサービスAPIを使用して他の攻撃の可能性についてサーバーを調査するのを防ぎます。
私はあなたの懸念を解決する手助けができると思います。
では、何を保護しようとしているのでしょうか。攻撃者がWebサービスを介してユーザーアカウントに侵入することから身を守ろうとしています。具体的には、モバイルアプリを実際にリバースエンジニアリングするのに十分な動機を持つ攻撃者からどのようにして身を守ることができるでしょうか。
できません。とても簡単です。不可能なことをしようとすることがあなたの懸念を引き起こしています。代わりに、クライアントがアプリであるか、未知の悪意のあるクライアントである可能性があるという想定の下で、サーバーを設計して実装します。これらの前提条件でアプリを保護できない場合は、安全でないアプリを出荷するか（おそらく悪い選択である可能性が高い）、または物理的に制御できる場所にクライアントを置く必要があります（選択も悪い可能性があります）。
特定のステートメントのいくつかを取り上げましょう。
私はモバイルバンキングアプリがこれを理解していると仮定しなければなりません。しかし、彼らはここでその知識を共有する可能性はそれほど高くありません！
いいえ、これは間違っています。これらの秘密のモバイルバンキングアプリデベロッパーが誰なのかはわかりませんが、このサイトの多くの人がモバイルなどのバンキングアプリを開発し、それらを保護する手助けをしたことは間違いありません。
攻撃者は、アプリのユーザーログインWebシーケンスを偽装して、パスワードリストを実行することができます。攻撃者はアプリを終了するときにHTTPSトラフィックを監視できるため、攻撃者はWebサービス要求と認証を構築する方法を知っています。
絶対的に正しい。攻撃者は、サーバーに対してブルートフォースパスワード攻撃を実行できます。アカウントロックアウト、 指数関数的遅延 、および [〜＃〜] captcha [〜＃〜] などの手法は、これに対する防御に役立ちます。
アプリを離れる前に、ログイン（およびその他の）情報を暗号化できます。これにより、攻撃者が暗号化で使用される秘密鍵を所有していないと想定して、スニッフィングとスプーフィングの両方を防ぐことができます。
（サーバーへの）インバウンドトラフィックを保護することがより重要であることを考えると、公開鍵暗号化は可能性があります。サーバーのみがそれを復号化できました。
SSLを信頼します。それは十分にテストされ、うまく機能します。 MiTM攻撃 から保護するためにアプリベースの暗号化を行う必要はありません。 Fiddlerのようなデバッグプロキシを接続し、暗号化されていると思われるトラフィックをクリアテキストで表示するのはおかしいことですが、セキュリティ上の問題ではありません。これはユーザーのデータであり、必要に応じて表示できます。そして、サーバーは、クライアントが実行しているアプリを決して知ることができないという概念で書かれているため、プロトコルは、攻撃者になる可能性のあるユーザーによる検査に耐えることができるはずです。サードパーティのMiTM攻撃を防ぐために、適切なSSL検証を行う必要があることに注意してください。
したがって、SSLを使用する場合は、HMACとクライアント側のアプリの暗号化をスキップしてください。代わりに、堅牢で安全なAPIを作成してください。私がそう言うからではなく、他に選択肢がないからです。あなた自身の分析がこれを証明しました。
編集：
攻撃者がWebサービスAPIを使用してパスワードリストを実行し、場合によってはメンバーアカウントにログインできないようにします。他にもブルートフォース検出対策を講じていますが、このような攻撃から直接APIを保護したいと考えています。
OWASPガイド がDOSで使用できるため、アカウントロックアウトについては以前に触れましたが、あまり好ましくないと思われます。繰り返し失敗した試みに対する応答の遅延について言及していません。
ガイドは続けて言う：
ブルートフォース攻撃を完全に阻止することは困難ですが、ログインに失敗するたびにWebサーバーログにHTTP 401ステータスコードが記録されるため、簡単に検出できます。ブルートフォース攻撃、特に攻撃者が有効なパスワードを見つけたことを意味する200のステータスコードが混在しているログファイルを監視することが重要です。
ユーザーがハッキングされることを誰も望まない一方で、成功したパスワード攻撃を認識して対応することで、攻撃のコストを劇的に削減できます。監視により、（一時的に）IPアドレスをロックアウトして悪意のあるユーザーを終了させることもできます（強力な攻撃は多くのIPアドレスから行われる可能性が高いため、これを行うのは困難です）。
二要素認証は、盗まれたパスワードの影響を軽減します。
攻撃者がWebサービスAPIを使用して他の攻撃の可能性についてサーバーを調査するのを防ぎます。
申し訳ありませんが、物理的なセキュリティがなければ、これを実際に行うことはできません。アプリにシークレットを埋め込んだり、難読化したりすることもできますが、アプリをより安全にするものはありません。バックワードエンジニアリングが可能なため、攻撃のコストが高くなるだけです。したがって、これらの戦略を実装するかどうかにかかわらず、攻撃者がシークレットとコードにアクセスできるかのようにAPIを設計する必要があります。
私は SASTとDAST の両方の大ファンです。静的分析を実行し、すべての展開前にすべての高/重要な問題を解決します。動的スキャンでも同じです。脆弱性スキャナーは、既知の脆弱性や不適切な構成がないかサイトをチェックすることもできます。
あなたの問題はまだあまり意味がありません。
ユーザーアカウントを列挙やブルートフォースパスワードから保護しようとしているようです。これはクライアントとは関係ありません。
ブルートフォースパスワード攻撃から保護するには、 https://stackoverflow.com/questions/30369529/block-request-for-multiple-unsuccessful-logins-for-a-period-of-time/30382110#を参照してください3038211
ユーザー名の列挙から保護するには、ユーザー名が存在するかどうかに関係なく、登録またはパスワードのリセットで同じ「成功」メッセージを返します。
潜在的なソリューションを提供せずに、解決したい実際の問題を明確に示してください。
攻撃者はフィドラーなどのプロキシツールを使用している必要があるため、アプリのトラフィックを盗聴できます。これはアプリケーションの問題ではありません。これが、これらのプロキシツールの動作方法です。アプリ開発者は、そのことを理解し、それに応じてセキュリティコントロールを実装する必要があります。これを回避したい場合は、証明書のピン留めを使用することもできますが、これも確実な方法ではありません。常に最悪のシナリオを想定してコードを開発する必要があります。すべてのセキュリティコントロールとビジネスロジックをサーバー側に配置し、機密情報をクライアント側に格納しないでください。
証明書のピン留めは、転送中のデータ攻撃に対してよく使用されるもう1つのコントロールです。クライアント（モバイルアプリ）の既知のピンリスト内にある公開キーをクライアントが受信しない場合、TLSハンドシェイクは開始されません。
ペイロードの暗号化を補完するものとして、Cert Pinningを使用しました。おそらく、次のものが機密モバイルアプリデータの基本標準になりつつあるのでしょうか。ツイートとFacebookのステータス更新では3つすべてが使用されているようです。
- 証明書のピン留め
- ペイロード暗号化
- TLS
これらはすべて倒すことができます。しかし、私たちは多層防御のゲームに参加しておらず、攻撃者を遅くしているのではないでしょうか？
あなたは問題を完全に要約しました。モバイルアプリがあることをどうやって知っていますかPostmanやPawの自動化リクエストのようなツールかもしれません。ペイロード暗号化の秘密鍵がわかっている場合、これはすべてを無効にします。