証明書の有効期限が切れた後、システムはどのようにして盗まれたコード署名証明書から保護しますか？
このシナリオを想像してください：
2014年12月1日-証明書が盗まれ、2014-12-01タイムスタンプでマルウェアに署名するために使用されます。
2014年12月15日-証明書は取り消されます。マルウェアは、CRLをチェックするシステムによって実行されなくなります。
2014年12月31日- この回答 -「証明書はCRLから削除されます」。
2015年1月1日-署名タイムスタンプが証明書が署名時に有効であったことを示すため、マルウェアを再度実行できるようになりました。これは、システムが署名を信頼するかどうかを決定するときに使用します。
これは可能ですか、それともコード署名の仕組みについて何かを誤解していますか？ステップ4で仮定を行っていますか？ Javaドキュメントなどのソースは、これがどのように機能するかを示唆しているようです -"通常、署名証明書は毎年期限切れになるため、これはJ2SE 5.0以降では、jarsignerはタイムスタンプを含むシグネチャを生成できるため、システム/デプロイヤ（Javaプラグインを含む）を有効にできます）署名証明書がまだ有効な間にJARファイルが署名されたかどうかを確認します。 "
これが、マイクロソフトがCRLから期限切れのコード署名証明書を削除しないことを推奨する理由です。別のシナリオ：攻撃者は、証明書の有効期限が切れる前にマルウェアに署名します。それらが未発見の過去の証明書の有効期限を維持できる場合、その証明書は発見時にもCRLに追加されず、マルウェアがブロックされることはありません。したがって、コード署名証明書の失効ステータスは永久に追跡する必要があります。
Microsoftの コード署名のベストプラクティス ドキュメントから：
ほとんどのPKI展開では、まだ期限が切れていない証明書のみがCRLに配置されます。つまり、失効した証明書の有効期限が切れると、最終的にはCRLから削除されます。ただし、タイムスタンプにより、Authenticode署名を無期限に有効なままにすることができます。その結果、取り消されたコード署名証明書をCRLから削除しないでください。このホワイトペーパーでは、公開されたソフトウェアの署名に使用された不正使用された証明書を常に無効にし、これらのエントリをCRLで無期限に維持することをお勧めします。
Microsoft Certificate Serverを使用すると、管理者はCAを構成して、失効したすべての証明書をCRLに保持できます。ただし、CAはコード署名証明書と他の証明書を区別しません。このため、管理者は、コード署名の運用証明書を処理することのみを目的としてCAを割り当てる必要があります。
したがって、あなたの質問に答えるために-はい、コード署名証明書のCRLが適切に管理されていなければ、マルウェアは再び実行される可能性があります。
デジタル署名の処理は、一目で想像できるよりも複雑です。
シナリオは正しいです。署名の日付/時刻の証明がない場合、証明書の失効と有効期限が切れた後に署名が行われていないことを確認できません。また、証明書が失効していない場合でも、証明書の有効期限が切れた後に行われた署名は有効とは見なされないことに注意してください。
最初の解決策
ソフトウェア署名にタイムスタンプを追加します。このタイムスタンプはsignature time-stampと呼ばれます。このタイムスタンプは、署名が特定の日付に存在したことを証明します。証明書の有効期限が切れる前に署名が計算されたことが証明されます。しかし、2番目の問題は解決しません。証明書が取り消された場合はどうなりますか？
第二の解決策
署名のタイムスタンプとともに、CRL（またはOCSP応答）のコピーを署名に添付することもできます。署名が作成されたときに証明書が取り消されなかったことを証明します。
ただし、タイムスタンプトークンとCRLも署名付きオブジェクトです。それらも検証する必要があります。それで、署名タイムスタンプが有効な証明書によって署名されたことを証明するCRLも取得する必要がありますか？短い答え：はい、物事はより複雑になるようです。
3番目のソリューション
一部の署名標準（ CAdES など）は、より良いソリューションを提案しています。署名のタイムスタンプとともに、署名の検証に必要なすべてのアイテムを収集する必要がありますoff-line（追加のオブジェクトをダウンロードせずに証明書を検証できること）すべての中間CA証明書とCRLが含まれます。最終的に1つまたは複数の信頼できるルートCAに到達するため、これは無限のプロセスではありませんが、かなり複雑になる可能性があります（適切なX.509検証アルゴリズムは、これらすべての項目を証明書の有効性ステータスとともに出力する必要があります）。そして、これらすべてのオブジェクトをフェッチした後、それにタイムスタンプを付ける必要があります。このタイムスタンプはと呼ばれますアーカイブタイムスタンプ
署名検証プロセスは次のとおりです。
- グローバルタイムスタンプオンラインを検証します。つまり、タイムスタンプ署名が有効であることを確認するために必要なすべての要素をダウンロードします。これで、含まれているすべてのオブジェクト（CRL ...）がアーカイブのタイムスタンプの日付に存在していたことが証明されました。
- 署名off-lineは、アーカイブタイムスタンプでカバーされた要素でのみ検証します。現在の日付は、アーカイブのタイムスタンプの日付でした。
このソリューションでは、署名検証者が署名の日付で証明書の有効期限と有効性のステータスを証明するため、提示したシナリオは不可能です。
このソリューションは現在、長期のドキュメント署名の検証のために実装されていますが、残念ながら、コード署名の検証のためではありません。今日のベンダーは、盗んだ証明書のブラックリストなど、実装が簡単な他のメカニズムを使用しています。
UPDATE 2014年9月25日（@maureenコメントを読んだ後）
まず、プロセスの理解は正しいです。すべての証明書は有効期限後にCRLから削除されるため、過去に証明書が失効しているかどうかを評価することはできません。したがって、証明書の有効期限が切れた後に署名を検証することはできません。
ただし、証明書が侵害された場合（または、たとえば顧客がUSB暗号トークンを失ったために単に取り消された場合）であっても、以前に作成されたすべての署名は有効であると見なされます。私の回答で説明したプロセスは、todayに（つまり、証明書の有効期限が切れた後でも）どのように答えることができるかを説明しようとします：「署名は有効でしたか作成した"。