Windows exe /バイナリの場合の証明書、署名、および拇印の違いは何ですか？
Windows実行可能ファイルとバイナリのコンテキストでの署名、拇印、証明書の違いを理解しようとしています。この質問を投稿する前にインターネットで調べましたが、簡潔な区別はありませんでした。そもそも、3つの用語に対する私の理解は、最初ははっきりしていません。誰かが私を助けてくれますか？
これは長いです。役立つ可能性のある例が下部にあります。
A Signatureは、少し小さめのデータ（ほとんどの場合、メッセージ、ファイル、またはその他のデータBLOBの暗号化ハッシュ（SHA256など））ダイジェストを取得してから、 秘密鍵を使用した（署名と呼ばれる）操作。秘密鍵にアクセスできるのはあなただけなので、そのデータに正確な署名を生成できるのはあなただけです。ただし、公開鍵を持っている人は誰でもその署名を確認できます。つまり、秘密鍵で作成されたことを確認できます。また、メッセージ/ファイル/ブロブを再度ハッシュする必要があるため署名される前のダイジェストを取得するために、メッセージが変更されたかどうかも確認できます。
バイナリのコンテキストでは、プロセスは次のようになります。誰か（Microsoftとしましょう）がバイナリをコンパイルします。次に、そのバイナリを取得してハッシュし、SHA256ダイジェストのようなものを生成します。次に、そのハッシュを取得し、Microsoftだけが持っている秘密鍵で署名します。これで、Microsoftはファイルを配布でき、Microsoftの公開鍵を持っている人はだれでも、Microsoftがファイルに署名したこと、およびファイルが署名されてから改ざんされていないことを知ることができます（実際にそうであると想定しています）。署名は、ファイル自体、またはファイルをハッシュして署名を検証するときに含まれない最後の小さなblobに保存できます（そうでない場合、署名を追加すると自動的に無効になります！）、または署名は別のファイルに保存されるか、帯域外で送信されます。
Certificateは、IDを公開キー（どこかに対応する秘密キーがある）に関連付けます。証明書が有効であることを認識している-つまり、証明書に含まれているキーは、実際にそれが識別する人または組織に属している-証明書がに署名されているに対応する（秘密）キーである（公開鍵）信頼できる証明書。証明書への署名は、バイナリまたはその他のファイルへの署名と同じように機能します。証明書（証明書が識別する名前、有効な日付、証明書の使用目的、証明書に関連付けられている公開鍵を含む）アイデンティティと目的）がハッシュされ、そのダイジェストが信頼できる誰かの秘密鍵を使用して署名され、署名（変更されたダイジェスト）が証明書の特別な場所に戻されます。もちろん、誰が証明書に署名したかを特定するには、それらの証明書が必要です。これは信頼の連鎖と呼ばれ、明示的に信頼された証明書に到達するまで続きます。信頼できる証明書は、証明書とその所有者を個人的に識別したもの、またはソフトウェアベンダーが識別したもの（認証局の証明書、またはMicrosoftが独自の証明書を信頼できるものとして出荷する方法などのベンダー自身の証明書など）です。 Windowsの1つ）、またはそのような何か。
バイナリとコード署名のコンテキストでは、証明書は、バイナリに署名した人、および署名が何を意味するかを知るのに役立ちます（つまり、Microsoftは、Windows Phoneのコアパーツであるバイナリに署名するときに別の証明書と署名キーを使用します。常にサンドボックス化する必要があるアプリのバイナリではなく、サンドボックスなしで実行することが許可されています）。署名は秘密鍵で作成されますが、公開鍵で検証されるため、特定の証明書の公開鍵が特定のバイナリの署名を正常に検証すると、2つのことがわかります。事柄：バイナリは署名されてから変更されていません（これにより署名が破損し、検証されなくなります）および秘密鍵の所有者（証明書の信頼性を疑う理由がない限り、おそらく誰が証明書で識別されるエンティティです）バイナリに署名した人です。
Windows Authenticode署名の場合、証明書は通常バイナリに含まれているため、他の場所から証明書を取得する必要はなく、署名をすぐに確認できます。バンドルされた証明書は信頼できる署名者によって署名されるため、バイナリは偽造された証明書を入れたランダムなschmoeによって署名されただけではないことがわかります。
Thumbprintは、暗号化されたハッシュダイジェストであり、通常はキーまたは証明書を識別するために使用されます。たとえば、証明書のない署名済みデータのblobがあるとします。各証明書の公開鍵をチェックして、署名が遅く、ばかげていることを確認できるかどうかを確認します。代わりに、署名には、ほぼ確実に、署名の検証に使用できる公開鍵を識別する拇印があります。すべての公開鍵を使用して計算コストの高い検証を試みるのではなく、それらのサムプリント（証明書に格納されている鍵と鍵自体、ただし鍵をハッシュして取得することもできます）を確認するだけです。一致するキーを見つけ、それを使用して検証を試みます。
バイナリでサムプリントが便利なもう1つの場所は、カタログファイルです。カタログファイルには2つの部分があります。 1つ目は、他のファイルのハッシュダイジェスト（つまり、拇印）のリストです。 2番目の部分は、これらすべての拇印の署名です。このようにして、受信者があなたのものであり、改ざんされていないことを受信者に確実に知らせたい一連のファイル（一部はバイナリではなく、署名を付けるための標準がない）を配布できます。カタログ（.cat）すべてのファイルのサムプリントを含み、キーで署名されたファイル。ファイルのいずれかが変更された場合、それらのハッシュダイジェストはカタログのサムプリントの1つにはなりません。誰かがカタログを編集しようとすると、その署名は検証されなくなります。誰かがカタログの署名を置き換えようとすると、元の署名者の秘密鍵がないため、元の署名者の証明書で検証できる署名を生成できません。
例： Microsoftは署名したいバイナリ、Windowsドライバを持っています。それらには、2048ビットのRSA公開鍵、Microsoftの名前、およびドライバーの署名に使用できることを示す使用情報を含む証明書（Windowsに含まれています）があります。 Windowsを使用しているため、この証明書があり、自動的に信頼されます。マイクロソフトは、ドライバーバイナリのSHA256ハッシュダイジェストを計算します。次に、その証明書の公開鍵に対応するRSA秘密鍵を取得し、秘密鍵を使用してダイジェストに署名します。検証できる公開鍵の変更されたダイジェスト（署名）とダイジェスト（拇印）は、バイナリの最後の特別な領域に配置されます。その後、そのバイナリを公開します。
ドライバをダウンロードしてインストールしようとすると、Windowsはバイナリの署名をチェックします。署名が存在することを確認すると、そのトラストストア（信頼できる証明書のリスト）をチェックして、署名に含まれているものと同じフィンガープリントを持つ公開鍵を持つ証明書を探します。一致する証明書を見つけると、Windowsは証明書が信頼できるドライバーを示すために使用できることを確認し、次にバイナリのSHA256ダイジェストを再計算します（署名がある最後の部分は無視します）。次に、Windowsは証明書のRSA公開鍵を使用し、署名時にその公開鍵を使用して操作を実行します。操作の結果がWindowsが計算したばかりのダイジェストと一致する場合、バイナリがMicrosoftによって署名されたことがわかり（Microsoftだけがその公開キーに適切な秘密キーを持っているため）、バイナリはそれ以降変更されていません。したがって、バイナリが信頼できるものであり、ドライバとしてロードできると判断します。
お役に立てば幸いです。