自己署名証明書のフィンガープリントを確認すると、セキュリティが向上しますか？
現在、ローカルエリアネットワーク内のデバイスとTCPデバイスとの通信を行うアプリケーションのコンポーネントを開発しています。データの暗号化、統合、および承認を提供するためにTLSを使用しています。ただし、セルフ5年以上有効期限のない署名付き証明書。
自己署名証明書を使用すると、アプリケーションが中間者攻撃にさらされるため、証明書のフィンガープリントをアプリケーションにハードコーディングすることを考えていました。デバイスが自分の証明書を送信すると、その証明書のフィンガープリントとハードコードされたフィンガープリントを比較します。
これにより、アプリケーションのセキュリティが向上しますか？攻撃者が同じフィンガープリントを持つ自分の自己署名証明書を作成することは可能ですか？また、TLSハンドシェイク中にデバイスに送信するクライアント証明書の使用も計画しています。デバイスは私の証明書のフィンガープリントをチェックする必要があります。
このソリューションは有効ですか？
ご回答ありがとうございます！
SSL/TLS では、クライアントはサーバーの公開鍵を使用します。 一般にクライアントはサーバーの公開鍵を事前に知らないため、 Public Key Infrastructure ：サーバーの魔法を通じてそれを取得することを期待しています公開鍵は証明書で提示され、クライアントは次のことを確認できます。
- 証明書の内容が本物である（つまり検証：署名と名前、および証明書の拡張子が正しく、信頼されたルートにリンクされている）;
- 証明書は目的のサーバーが所有しています（予期されるサーバー名は
Subject Alt Name証明書の拡張子、またはSAN拡張子）がない場合はその共通名。
これで、クライアントがすでに公開鍵を知っている場合、これらすべてが不必要に複雑になります。そのキーが既知aprioriの場合、クライアントはそれを使用して、サーバーから送信された証明書を単に無視できます。
プロトコルの正式な仕様との互換性のため、および既存のライブラリと実装をより簡単に再利用するために、提案することを実行するほうがおそらく簡単です。つまり、サーバーの証明書が期待される証明書とビット対ビットであることを確認します。コードから公開鍵を抽出します。 「フィンガープリント」は、2番目のプリイメージに耐性のあるハッシュ関数（SHA-1など）で計算された場合、そのチェックに使用できます。これで結構です。
あなたの場合、私はサーバーがdeviceであり、クライアントがあなたのアプリケーションであることを理解しています。攻撃者がデバイスの秘密キーを危険にさらした、つまりデバイスから抽出していない限り、アプリケーションはだまされません（偽のデバイスと通信します）。 severalデバイスがある場合、各デバイスには独自の秘密鍵と公開鍵のペアが必要です。すべてのデバイスが同じ鍵ペアを持っている場合、秘密鍵は「秘密」と見なすことはできません。2人または3人以上が知っている秘密は秘密ではなく、うわさです。
「安全な」方法は、制御された条件下で何らかの初期化フェーズを行うことです。この場合、アプリケーションインスタンスは、その後接続するデバイスのフィンガープリントを学習します（おそらくアプリケーションが生成します公開/秘密鍵のペアと自己署名証明書、およびそれらをデバイスにインポートします）。
これは [〜＃〜] ssh [〜＃〜] で使用されるセキュリティモデルです。クライアントから特定のサーバーへの最初の接続には明示的な確認が必要です（クライアントはサーバーの公開鍵のフィンガープリントを表示しますが、人間のユーザーは、たとえばサーバーsysadminに電話をかけることでそれを確認することになっています）;その後、フィンガープリントを覚えているため、クライアントはその公開鍵を信頼します。
「キーを覚える」モデルは適切に機能しますが、revocationと呼ばれるPKI機能が失われることに注意してください：帯域外、損傷抑制情報を伝達する自動メカニズム。いずれかのデバイスの秘密鍵が危険にさらされた場合、泥棒はその後偽のデバイスを実行し、アプリケーションをだましてそれに接続させることができます。この状況が続くのを回避するには、アプリケーションに何らかの方法で、所定の証明書のフィンガープリントを受け入れないように警告する必要があります。定期的に発行されるCRLまたはOCSP応答による失効チェックは、それを行う自動方法です。指紋を覚えている場合、PKIはないため、CRLはありません。しかし、ニーズはまだそこにあるかもしれません。
証明書のフィンガープリントが埋め込まれているPKIを使用しない場合は、CRLによって通常実行されるジョブを確実にするために何かが必要かどうかを判断する必要があります。
ここで行っていることは、 certificate pinning に似ています。状況によっては、CAが発行した証明書を使用するよりも実際にセキュリティが向上する場合があります（CAを信頼する必要がないため）。
欠点は、証明書の管理（失効、再発行など）を手動のプロセスにすることです。これは、ユースケースによっては、実際の問題になる可能性があります。
はい、これは事実上、証明書の自己署名に使用されるルート証明書を信頼することと同じです。証明書の検証プロセスは、拇印を取得して、信頼できるCAから取得した署名が拇印と一致することを確認することです。サムプリントを直接確認することは同等のアクションです。