タイム スタンプ Authenticode 署名

  • [アーティクル]

Microsoft Authenticode 署名は、バイナリ データの作成者と整合性の保証を提供します。 Authenticode タイム スタンプは、標準の PKCS #7 カウンター署名に基づいています。 Microsoft の署名ツールを使用すると、開発者は Authenticode 署名を貼り付けるのと同時にタイムスタンプを貼り付けることができます。 タイムスタンプを使用すると、署名に使用される証明書の有効期限が切れた後でも Authenticode 署名を検証できます。

Authenticode の概要

Authenticode は、デジタル署名テクノロジを適用して、インストール可能なソフトウェアなどのバイナリ データの作成者と整合性を保証します。 クライアント Web ブラウザーまたは他のシステム コンポーネントは、Authenticode 署名を使用して、ソフトウェアのダウンロードまたはインストール時にデータの整合性を確認できます。 Authenticode 署名は、.cab、.exe、.ocx、.dll など、多くのソフトウェア形式で使用できます。

Microsoft では、公開認証機関 (CA) の一覧を保持しています。 Authenticode 証明書の発行者には現在、SSL.com、Digicert、Sectigo(Comodo)、GlobalSign などがあります。

暗号化タイム スタンプについて

これまで、さまざまな暗号化タイム スタンプ手法が提案されてきました。 たとえば、Haber 氏と Stornetta 氏による『暗号学ジャーナル』の「デジタル ドキュメントにタイムスタンプを付ける方法」 (1991 年) や、Benaloh 氏と de Mare 氏による『Springer-Verlag コンピューター サイエンス講義ノート』第 765 巻 (EUROCRYPT '93) の「一方向アキュムレータ: デジタル署名の分散型代替手段」などです。 この記事の他の抜粋は、Microsoft Research から入手できます。 (これらのリソースは、一部の言語や国または地域では入手できない場合があります)。時間は数学的量ではなく物理的量であるため、これらの方法は一般に、オブジェクトの作成順序を決定できるようにオブジェクトをリンクする方法、または同時に作成されたと説明できるオブジェクトを効率的にグループ化する方法に関係するものです。

時間を量として認証しようとするシステムには、常に何らかの形の信頼が必要です。 敵対的な状況が強い状況では、複雑なプロトコルを使用して、ある程度の同期を確保できます。 ただし、これらのプロトコルでは、影響を受ける当事者間の広範なやり取りが必要になります。 実際には、信頼できるソースからの時間の証明書のみ必要な場合、そのソースは、指定された時間にオブジェクトが署名のために提示されたことを示す署名入りの声明 (証明書) を提供することで、公証人として機能するだけで済みます。

以下に実装されているタイムスタンプの副署名方式により、署名証明書の有効期限が切れたり、取り消されたりした後でも署名を検証できます。 タイムスタンプにより、検証者は署名が付与された時刻を確実に知ることができ、その時点で署名が有効であったかどうかを信頼できます。 タイム スタンパーには信頼性が高く保護されたタイム ソースが必要です。

PKCS #7 署名済みドキュメントと副署名

PKCS #7 は、署名されたデータ、証明書、証明書失効リスト (CRL) などの暗号化データの標準形式です。 タイムスタンプのコンテキストで関心のある特定の PKCS #7 の種類は、PKCS #7 で定義された SignedData コンテンツ タイプに対応する署名付きデータです。

PKCS #7 パッケージは、実際のコンテンツとそれに関する特定の情報および SignerInfo 署名ブロックを識別する SignedData で構成されます。 SignerInfo 自体に副署名が含まれている場合があります。これは、再帰的には別の SignerInfo です。 原則として、このような副署名のシーケンスが存在する場合があります。 副署名は、SignerInfo 内の署名に関する認証されていない属性です。つまり、元の署名の後に付加される場合があります。 アウトライン形式:

SignedData (PKCS #7)

  • バージョン (PKCS #7。通常はバージョン 1)
  • DigestAlgorithms (最適化された処理のために SignerInfo 署名ブロックによって使用される、すべてのアルゴリズムのコレクション)
  • ContentInfo (contentType は、SignedData に加え、コンテンツまたはコンテンツへの参照と等しくなります)
  • 省略可能な証明書 (使用されるすべての証明書のコレクション)
  • 省略可能な CRL (すべての CRL のコレクション)
  • SignerInfo 署名ブロック (1 つ以上の SignerInfo 署名ブロックで構成される実際の署名)

SignerInfo (署名ブロック)

  • バージョン (PKCS #7。通常はバージョン 1)
  • 証明書 (SignedData で署名者の証明書を一意に識別するための発行者とシリアル番号)
  • DigestAlgorithm に DigestEncryptionAlgorithm、ダイジェスト (ハッシュ)、EncryptedDigest (実際の署名) を加えたもの
  • 省略可能な AuthenticatedAttributes (この署名者によって署名されたなど)
  • 省略可能な UnauthenticatedAttributes (この署名者によって署名されていないなど)

認証された属性の例としては、署名時刻 (OID 1.2.840.113549.1.9.5) が挙げられます。これは、タイムスタンプ サービスが署名する内容の一部です。 認証されていない属性の例としては、署名後に付加できる副署名 (OID 1.2.840.113549.1.9.6) が挙げられます。 この場合、SignerInfo 自体には SignerInfo (Countersignature) が含まれています。

Note

副署名で署名されたオブジェクトは、元の署名 (つまり、元の SignerInfo の EncryptedDigest) です。

 

SignTool と Authenticode プロセス

SignTool は、Authenticode 署名とバイナリ データのタイムスタンプに使用できます。 このツールは、Microsoft Windows ソフトウェア開発キット (SDK) インストール パスの \Bin フォルダーにインストールされます。

バイナリ データの署名とタイム スタンプは、SignTool を使用すると比較的簡単です。 発行元は、商用コード署名 CA からコード署名証明書を取得する必要があります。 便宜上、Microsoft は、Authenticode 証明書を発行する CA を含む、公開 CA の一覧を公開および更新しています。 発行する準備ができたら、SignTool ツールで適切なコマンド ライン パラメーターを使用し、オブジェクト ファイルに署名とタイムスタンプが付与されます。 SignTool 操作の結果は、常に PKCS #7 形式 SignedData になります。

SignTool は、署名およびタイムスタンプが付与される生のバイナリ データ、または以前に署名されたバイナリ データにタイムスタンプを付与する入力として受け入れます。 以前に署名されたデータには、signtool timestamp コマンドを使用してタイムスタンプを付けることができます。

引数 説明
/t HTTPAddress ファイルにタイム スタンプが付与されることを示します。 タイム スタンプ サーバーのアドレスを指定する URL を指定する必要があります。 /t は、signtool sign コマンドと signtool timestamp コマンドの両方で使用できます。

 

このコンテキストで役立つ可能性があるツールについて詳しくは、「暗号化ツール」と「SignTool」をご覧ください。

実装の詳細とワイヤ形式

SignTool は、署名の作成とタイムスタンプ追加の点でWindows Authenticode の実装に依存しています。 Authenticode は、.cab、.exe、.dll、.ocx などのバイナリ ファイルで動作します。 Authenticode は最初に署名を作成し、PKCS #7 SignedData を生成します。 PKCS #9 で説明されているように、この SignedData に対して副署名を行う必要があります。

副署名プロセスは、次の 4 つの手順で行われます。

  1. PKCS #7 SignedData の SignerInfo から署名 (つまり encryptedDigest) をコピーします。
  2. コンテンツが元の署名であるタイム スタンプ要求を作成します。 TimeStampRequest としてエンコードされたタイムスタンプ サーバー Abstract Syntax Notation One (ASN.1) に送信します。
  3. タイム スタンプ サーバーから返される 2 つ目の PKCS #7 SignedData として書式設定されたタイム スタンプを受け取ります。
  4. タイムスタンプの SignerInfo を、PKCS #9 副署名 (つまり、元の SignerInfo 内の認証されていない属性) として、元の PKCS #7 SignedData に直接コピーします。

タイム スタンプ要求

タイム スタンプ要求は、HTTP 1.1 POST メッセージ内で送信されます。 HTTP ヘッダーでは、CacheControl ディレクティブは no-cache なしに設定され、Content-Type ディレクティブは application/octet-stream に設定されます。 HTTP メッセージの本文は、タイムスタンプ要求の Distinguished Encoding Rules (DER) エンコードの base64 エンコードです。

現在は使用されていませんが、Content-Length ディレクティブは、タイムスタンプ サーバーが HTTP POST 内の要求の場所を見つけるのに役立つため、HTTP メッセージの構築にも使用する必要があります。

他の HTTP ヘッダーも存在する可能性があり、要求側またはタイム スタンプ サーバーにより認識されない場合は無視する必要があります。

タイム スタンプ要求は、ASN.1 でエンコードされたメッセージです。 要求の形式は次のとおりです。

TimeStampRequest ::= SEQUENCE {
   countersignatureType OBJECT IDENTIFIER,
   attributes Attributes OPTIONAL, 
   content  ContentInfo
}

countersignatureType はオブジェクト識別子 (OID) であり、これをタイム スタンプの副署名として識別し、正確な OID 1.3.6.1.4.1.311.3.2.1 である必要があります。

現在のところ、タイム スタンプ要求には属性は含まれていません。

コンテンツは、PKCS #7 で定義されている ContentInfo です。 コンテンツは、署名対象のデータです。 署名タイムスタンプの場合、ContentType は Data であり、コンテンツはタイムスタンプが付与される PKCS #7 コンテンツの SignerInfo からの encryptedDigest (署名) である必要があります。

タイム スタンプ応答

タイム スタンプ応答も HTTP 1.1 メッセージ内で送信されます。 HTTP ヘッダーでは、Content-Type ディレクティブも application/octet-stream に設定されます。 HTTP メッセージの本文は、タイム スタンプ応答の DER エンコードの base64 エンコードです。

タイム スタンプ応答は、タイム スタンパーによって署名された PKCS #7 署名付きメッセージです。 PKCS #7 メッセージの ContentInfo は、タイム スタンプで受信される ContentInfo と同じです。 PKCS #7 コンテンツには、署名時間認証属性 (PKCS #99、OID 1.2.840.113549.9.5 で定義されています) が含まれます。

Authenticode はサーバーからタイムスタンプを受信すると、そのタイムスタンプを元の PKCS #7 SignedData に副署名として組み込みます。 これを実現するため、返された PKCS #7 SignedData の ContentInfo は破棄され、返されたタイムスタンプの SignerInfo は元の PKCS #7 SignedData の SignerInfo に副署名としてコピーされます。 タイム スタンパーの証明書チェーンも、元の署名者の認証されていない属性として、元の PKCS #7 SignedData の証明書にコピーされます。