タイム スタンプ Authenticode Signatures
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 が含まれます。
暗号化タイム スタンプについて
これまでは、さまざまな暗号タイムスタンプ方式が提案されてきました。 たとえば、 Cryptology ジャーナル (1991 年) の Haber と Stornetta の 「デジタル ドキュメントをTime-Stampする方法」、および「One-Way アキュムレータ: デジタル署名の分散化された代替手段」の「 Springer-Verlag Computer Science Vol. 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 に加え、コンテンツまたはコンテンツへの参照と等しい)
- OPTIONAL Certificates (使用されるすべての証明書のコレクション)
- 省略可能な CRL (すべての CRL のコレクション)
- SignerInfo 署名ブロック (1 つ以上の SignerInfo 署名ブロックで構成される実際の署名)
SignerInfo (署名ブロック)
- バージョン (PKCS #7、一般バージョン 1)
- 証明書 ( SignedData で署名者の証明書を一意に識別するための発行者とシリアル番号)
- DigestAlgorithm と DigestEncryptionAlgorithm にダイジェスト (ハッシュ)、EncryptedDigest (実際の署名) を加えたもの
- OPTIONAL AuthenticatedAttributes (この署名者によって署名されたなど)
- OPTIONAL 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 の一覧を公開および更新します。 発行する準備ができたら、SignTool ツールで適切なコマンド ライン パラメーターを使用して、オブジェクト ファイルに署名とタイムスタンプが設定されます。 SignTool 操作の結果は、常に PKCS #7 形式 の SignedData になります。
SignTool は、署名およびタイムスタンプが設定される未加工のバイナリ データ、または以前に署名されたバイナリ データをタイムスタンプ付きとして入力として受け入れます。 以前に署名されたデータには、 signtool timestamp コマンドを使用してタイムスタンプを付けることができます。
| 引数 | 説明 |
|---|---|
| /tHTTPAddress | ファイルにタイムスタンプが設定されることを示します。 タイム スタンプ サーバーのアドレスを指定する URL を指定する必要があります。 /t は、 signtool sign コマンドと signtool timestamp コマンドの両方で使用できます。 |
このコンテキストで役立つ可能性のあるツールの詳細については、「 Cryptography Tools and SignTool」を参照してください。
実装の詳細とワイヤ形式
SignTool は 、Windows Authenticode の実装に依存して、署名とタイム スタンプ署名を作成します。 Authenticode は、.cab、.exe、.dll、.ocx などのバイナリ ファイルで動作します。 Authenticode は最初に署名を作成し、PKCS #7 SignedData を生成します。 PKCS #9 で説明されているように、この SignedData に対して署名する必要があります。
反署名プロセスは、次の 4 つの手順で行われます。
- PKCS #7 SignedData の SignerInfo から署名 (つまり encryptedDigest) をコピーします。
- コンテンツが元の署名であるタイム スタンプ要求を作成します。 これを TimeStampRequest としてエンコードされたタイム スタンプ サーバー Abstract Syntax Notation One (ASN.1) に送信します。
- タイム スタンプ サーバーから返される 2 つ目の PKCS #7 SignedData として書式設定されたタイムスタンプを受け取ります。
- タイムスタンプの SignerInfo を、PKCS #9 の反署名 (つまり、元の SignerInfo の認証されていない属性) として、元の PKCS #7 SignedData に直接コピーします。
タイム スタンプ要求
タイム スタンプ要求は、HTTP 1.1 POST メッセージ内で送信されます。 HTTP ヘッダーでは、CacheControl ディレクティブはキャッシュなしに設定され、Content-Type ディレクティブは application/octet-stream に設定されます。 HTTP メッセージの本文は、タイムスタンプ要求のDistinguished Encoding Rules (DER) エンコードの base64 エンコードです。
現在は使用されていませんが、Content-Length ディレクティブは HTTP メッセージの構築にも使用する必要があります。これは、要求が HTTP POST 内の場所をタイム スタンプ サーバーで見つけるのに役立ちます。
他の 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 (signature) で、タイムスタンプを付ける必要があります。
タイム スタンプ応答
タイム スタンプ応答は、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 がサーバーからタイム スタンプを受け取った後、Authenticode は、カウンター署名として元の PKCS #7 SignedData にタイム スタンプを組み込みます。 これを実現するために、返された PKCS #7 SignedData の ContentInfo が破棄され、返されたタイム スタンプの SignerInfo が、元の PKCS #7 SignedData の SignerInfo に反署名としてコピーされます。 タイム スタンパーの証明書チェーンは、元の署名者の認証されていない属性として、元の PKCS #7 SignedData の証明書にもコピーされます。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示