[Java, Security] Understanding why Java signed code needs to be re-signed periodically (even if time-stamped)

原文はこちら。
https://blogs.oracle.com/java-platform-group/signed-code-needs-to-be-re-signed

Javaランタイムには、別のコンピュータからコードを受け入れるためのメカニズムがあります。コードは実行前に安全ではないネットワークを通過する可能性があるため、これらのメカニズムは、プログラムが信頼できるエンティティによって作成され、改ざんされていないことを検証するためのデジタル署名(コード署名)に依存しています。デジタル署名コードにはコード署名証明書が必要です。デフォルトでJavaランタイムが受け入れるのは、信頼できる認証局(CA)が発行した証明書のみです。セキュリティ上の理由から、証明書の発行日から1年間から3年間の限られた期間のみ有効です。
デジタル署名が有効とみなされるためには、署名自体の有効期限が切れていなくても、コード署名証明書が有効な間に署名をしなければなりません。有効期限が切れた証明書で作成された署名は有効とみなされません。署名がいつ作成されたかを知ることが重要です。残念ながら、ファイルのファイル作成日"プロパティを信頼することはできません。その値が偽造された可能性があるからです。
コード署名証明書の有効期間中に署名されたことを確認する1つの方法として、署名チェック時に有効な証明書で署名されたコードのみを受け入れる方法がありますが、このアプローチの問題は、たとえコード自体が変更されていなくても、1年に1回、コードを再署名して再配布する必要がある点です。
証明書の有効期限内に署名が作成されたかどうかを検証する場合、タイムスタンプをつかうとよいでしょう。タイムスタンプの付与には、信頼できるサードパーティであるTSA(Time-Stamping Authority、タイムスタンプ局)が、与えられた署名が所定の日付以前に作成されたことを確認する必要があります。このタイムスタンプは、コード署名証明書が失効する前に署名が行われたという証明として、署名済みコードに追加されます。
タイムスタンプ自体は、開発者のコード署名証明書ではなく、タイムスタンプの権限証明書を使用した別の電子署名に過ぎませんが、依然として考慮しなければならない同じ規則と独自の有効期限がある点を見落としがちです。理想的には、タイムスタンプ局は、コード署名証明書よりもずっと後に期限が切れる証明書を使用します。
タイムスタンプサーバーの証明書が失効すると、証明書の有効期限内にタイムスタンプが作成されたことを信頼できなくなってしまいます。コード署名証明書が失効する前に元の署名が作成されたかどうかを確認できなくなります。
有効期限は、署名が信頼されなくなる理由の1つにすぎません。コード署名やタイムスタンプに関わる証明書は、それらが侵害された場合、もしくは証明書の有効期限が切れる前に、それらの作成に使用されたアルゴリズムがクラックされる場合、取り消される可能性があります。コード署名証明書を無効にするものは、コードの署名に影響します。タイムスタンプ証明書を無効にするものは、タイムスタンプを無効にします。
タイムスタンプサービスは、遠い将来に有効期限が切れる証明書が常に使用し、長期間有効であると考えられるアルゴリズムと鍵長でのみ署名すると信じられていますが、後方互換性のために中期的には安全でないと思われるアルゴリズムを使用してタイムスタンプを生成することが必要なこともあります。その場合タイムスタンプ局は有効期限の短いタイムスタンプ証明書の利用を選択する可能性があります。
開発者は、依存している各タイムスタンプサービスの長所や短所、コードの署名が有効でなくなったときの状況を把握し、混乱を避けるための十分な時間をもってコードを再署名して十分に再配布する手順を踏むことが重要です。
コード署名とタイムスタンプがより低いレベルでどのように機能するか、もっと詳しく知りたい場合は、以下のエントリをご一読ください。
Understanding Digital Certificates and Code Signing
http://www.oracle.com/technetwork/java/javase/documentation/digitalcerts-codesigning-4312830.html

0 件のコメント:

コメントを投稿