WebBrowser コントロールを使用して WebInterface を C# アプリに追加しています。そのようなアプリのみが SSL クライアント証明書を使用して Web サーバーに接続できることを確認したいと考えています。
私の考えは、クライアント証明書をアプリに埋め込み、アプリ経由で接続するときに使用することでした。誰でもこれを行う方法について提案がありますか? または、それを機能させる唯一の方法は、X509Store にキーをロードすることです。
X509Store に配置すると、キーを Internet Explorer の一般的な使用法で利用できるようになりますか?
だから、ここでいくつかの考え：
「エリクソン」に同意します。現在の設計では、アプリのみがアプリと通信できることを検証することはほとんど不可能です。誰かがあなたのアプリをリバース エンジニアリングし、ゲーム オーバーになるのは時間の問題です (それが唯一のセキュリティ手段である場合)。あなたのアプリと有効なユーザーであることを検証したい場合は、ユーザーを認証するだけでなく、問題のアプリの署名をチェックする何らかのメカニズムが必要です (クライアントサーバーモデルでは可能ではないと思います. ..結局のところ、私の「hackyou」アプリは「realapp」と同じ署名を持っており、サーバー側からはそれを確認できないといつでも嘘をつくことができます）
WebBrowser コントロールは本質的に IE のラッパーであることを思い出してください。そのため、いくつかのトリック (すぐに説明します) がなければ、証明書をユーザー ストアに追加する必要があります。
あなたが求めていることを達成するためのハッキーな方法は次のとおりです（それは悪い考えですが）：
これは基本的に、サーバーとの間の要求と応答を処理するためにいくつかのラッパー クラスを作成する必要があり、WebBrowser を使用して HTML の表示を処理するだけであることを意味します。
実際には、対処しようとしている脅威を再設計して確認する必要があります。
これでよろしいですか？秘密鍵をアプリケーションに埋め込むと (アプローチに必要な場合)、攻撃者はそれを抽出し、不正なソフトウェアの認証に使用できます。
サーバーはクライアント ソフトウェアを認証できません。クライアントが何らかの秘密を持っているかどうかのみをテストできます。秘密鍵をクライアントに埋め込んで配布すると、秘密ではなくなります。
ソフトウェア自体ではなく、ソフトウェアのユーザーを認証することをお勧めします。パスワードであろうと秘密鍵であろうと、ユーザーに独自の秘密を生成させ、それを保護するインセンティブを与える必要があります。
キーを使用する目的は、ユーザーを検証することではなく、WebBrowser を使用する代わりにアプリのユーザーへのアクセスを制限することです。これは、公共のインターネットを介したイントラネットの動作の一種です。
これは貧乏人のDRMです。キーを抽出することによる損失はそれほど重要ではありません。これが起こるリスクは低く、失うものは最小限だと思います。
それにもかかわらず、WebServerへのアクセスをアプリのユーザーのみに制限する他のアイデアがあれば、私はどんな提案も受け付けています. 基本的には誰でも読めるように公開WebServerを公開したいのですが、公共のネットワークを介してさまざまな場所からアクセスする必要があるため、イントラネットのインフラを構築することもできません。