クラッシュダンプ（Breakpad、Windowsなど）を暗号化して署名する必要がありますか？
ソフトウェア開発者として、私のクラッシュダンプ（Breakpad、Windowsなどから）を暗号化して署名する必要がありますか？ユーザーがクラッシュダンプを報告したときに問題を特定できるように、クラッシュダンプをエクスポートする機能を提供します。
私の製品の保護に関する私の懸念（攻撃者は製品をハッキングして何かを得たユーザーです）：
- ダンプは、ハッカーがソフトウェアをリバースエンジニアリングしたり、ハッキングしたりするための情報を多すぎます。たとえば、機能やライセンスを有効にしますか？
- ハッカーがソフトウェアをハッキングするために、パスワードとキーがダンプに保存される可能性があります。
- ユーザーが悪意のある不正な形式のダンプを返す可能性があり、マシン上のダンプを解読しようとしたときに大混乱を引き起こします。アプリケーションがダンプに署名した場合、少なくとも自信を持ってファイルを開くことができます。
pdate：最後の箇条書きについては、回答の1つで、データに署名する必要がないことを思い出しました。キーは製品自体に存在する必要があるため、ハッカーが使用できるためです。とにかく署名する。さらに、一時的な仮想マシンを使用することで、悪意のあるダンプの恐れを回避できます。
最後に残っている懸念は、ダンプにアドレスやデータが含まれている場合に、ハッカーがライセンスされた機能などの制限を回避するのにどのように役立つかです。
ダンプは、ハッカーがソフトウェアをリバースエンジニアリングしたりハッキングしたりするのに多すぎる情報を提供します（機能やライセンスを有効にするなど）？
ダンプは、ある時点で、暗号化されていない形式で存在する必要があります。完全なローカルコントロールを持つ攻撃者は、その瞬間にダンプを取得するか、単にそれらを無視して、実行中のアプリケーションのメモリを自由に見ることができます。
Spotifyなどの一部のプログラムは、デバッグ環境で実行されているかどうかを検出し、さまざまな難読化スキームを使用してリバースエンジニアリングの速度を低下させます。これにより、未経験の攻撃者を阻止したり、経験豊富な攻撃者の速度を低下させたりできます。しかし、それはおそらく攻撃者を止めません。これが基本的に、Microsoftのような企業がオンラインライセンス検証を選択する理由です。
ただし、転送中の暗号化はまったく別の問題です。ダンプで利用可能な顧客の資産、または顧客のコンピュータにインストールされたライセンスさえも保護することは、これを適切な提案にして、第三者がダンプにアクセスできないようにします。
また、実装も簡単です。たとえば、httpsでダンプを送信します。ダンプの内容によっては、これによる利益は小さいかもしれませんが、実装するのも非常に安価であり、お客様とお客様の両方のデータに対するリスクを軽減します。顧客はおそらく、製品を評価するよりもデータを評価することを覚えておいてください。
ユーザーが悪意のある不正な形式のダンプを返す可能性があり、マシン上のダンプを解読しようとしたときに大混乱を引き起こします。アプリケーションがダンプに署名した場合、少なくとも自信を持ってファイルを開くことができます。
ファイルに署名するには、アプリケーションhasで秘密鍵にアクセスします。秘密鍵は、ある段階で署名を行うマシンのメモリに存在する必要があります。ソフトウェアのインスタンスごとに配布する必要があります。
攻撃者はキーにアクセスし、悪意のあるダンプファイルに署名できます。
これは、ダンプを攻撃ベクトルとして使用することには役立ちません。
[...]クラッシュダンプを暗号化して署名する必要がありますか？
誰かが、タスクマネージャー、プロセスエクスプローラー、ProcDump、WinDbg、Visual Studio、DebugDiag、WER、AdPlus（およびそれ以上）などのさまざまなツールを使用して、任意の数のクラッシュダンプを作成でき、それらを傍受する可能性はありません。攻撃者は暗号化されたBreakpadクラッシュダンプを使用せず、代わりに独自の定期クラッシュダンプを作成します。
ただし、プライバシー規制を遵守し、許可された担当者のみがクラッシュダンプにアクセスできるようにする必要があります。その場合、暗号化が役立つ可能性がありますが、他のアクセス制御も問題ありません。
ダンプは、ハッカーがソフトウェアをリバースエンジニアリングしたりハッキングしたりするのに多すぎる情報を提供します（機能やライセンスを有効にするなど）？
アプリケーションのライブインスタンスは、さらに多くの情報を提供します。このように考えてください。多くのクラッシュダンプを作成できるため、分析する情報が増えます。
また、クラッシュダンプのサイズに影響を与えることができることを知っていましたか？ MINIDUMP_TYPE オプションに応じて、クラッシュダンプには多少の情報が含まれます。
ユーザーが悪意のある不正な形式のダンプを返す可能性があり、マシン上のダンプを解読しようとしたときに大混乱を引き起こします。
あなたの可能性はありますが、ありそうもありません。他のアプリケーションでは、デバッガーのセキュリティ関連のバグである可能性があります。デバッガーは、クラッシュダンプから情報を読み取るだけで、実行はしません。
攻撃者はどのようにして自分を特定せずにクラッシュダンプを送信しますか？
私の個人的な見解は、それはあなたへの費用/利益に依存するということです。
はい、ファイルにデジタル署名します。作業が減り、実際の顧客からダンプを受け取ることができます。はい、情報の転送について。暗号化されたチャネルを使用する必要があり、それが不可能な場合は、データを暗号化します。 たとえば、httpsを使用して配信する方が簡単だと思います失敗する可能性のあるデータに暗号化の方法を実装する代わりに、.
ローカルでは、それは風景に依存します。
通常、ダンプはデフォルトで許可されるべきではなく、本番サーバーでの特定の問題のトラブルシューティングのためにのみ有効にする必要があります。
有効になっている場合は、ダンプ用に特定のパーティションを構成し、そのパーティションに特権ユーザーへのアクセスを許可し、ダンプデータをシステムに残したままにしないでください。解析。
この状況では、これは制御されたものであり、ここで暗号化を実装しても、実際のメリットはありません。
ダンプを生成して組織に配信する自動化の種類がある場合、ダンプにPIIデータが含まれている可能性がある場合は、暗号化をすべての場所に実装する必要があります。削除または上書きされていない残りのダンプは適切です。サーバー上で実行されているものに関する情報のソース。
本番サーバーではDUMPSを無効にし、DEBUGも無効にする必要があるため、これはベストプラクティスではありません。これは、必要な場合にのみ有効にし、いくつかのsysadminを監視して有効にする必要があります。
暗号化には、費用がかかるいくつかの課題があります。
PKIインフラ：秘密キーを所有している場合、キーを共有しない限り、顧客はローカルでデータにアクセスできません。
顧客が秘密キーを使用してローカルダンプにアクセスできるようにする場合は、顧客ごとに秘密キーを生成する必要があるため、時間がかかる可能性があるキー管理の問題を入力します。
キーを取り消すと、すべての顧客のアプリケーションを更新する必要があります...
同期キー：データの暗号化を可能にするためにシステム内のどこかにキーが存在する必要があるため、あまり意味がありません。
キーを変更することも、困難で時間がかかります。