Timestamp for Microsoft Authenticode?

[Walter H.]

Hello,

has anybody got an idea, how to programm/get such a timestamp server -
is not RFC 3161 conform -
with using OpenSSL on Linux;

attached are the ASN.1 dump of the received and sent package - in this
case the signtool.exe sends the query to
http://timestamp.verisign.com/scripts/timestamp.dll and receives from
there the reply;
- send (request): mssendts-asn1.text
- receive (reply): msrecvts-asn1.text
(these I recorded with wireshark)

I thought of this:

openssl smime -pk7out -in received.der -inform DER -sign -out
pkcs7reply.der -outform DER -md sha1 -signer cert.pem -inkey key.pem
-passin file:passphrase

but there I'm missing the original 256 bytes of the received query,
and the SECTION with OID 1.2.840.113549.1.9.15 (sMIMECapabilities) is
too much;
see the 3rd attachment: pkcs7reply-asn1.text

below is the "spec" from MSDN;

how can I achieve this?

Thanks,
Walter


Time Stamp Request

The time stamp request is sent within an HTTP 1.1 POST message. In the
HTTP header, the CacheControl directive is set to no-cache, and the
Content-Type directive is set to application/octet-stream. The body of
the HTTP message is a base64 encoding of /Distinguished Encoding Rules/
<http://msdn.microsoft.com/en-us/library/windows/desktop/ms721573%28v=vs.85%29.aspx#_security_distinguished_encoding_rules_gly>
(DER) encoding of the time stamp request.

Although not currently used, the Content-Length directive should also be
used in constructing the HTTP message because it helps the time stamp
server locate where the request is within the HTTP POST.

Other HTTP headers may also be present and should be ignored if they are
not understood by the requestor or time stamp server.

The time stamp request is an ASN.1 encoded message. The format of the
request is as follows.

Copy

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

The countersignatureType is the /object identifier/
<http://msdn.microsoft.com/en-us/library/windows/desktop/ms721599%28v=vs.85%29.aspx#_security_object_identifier_gly>
(OID) that identifies this as a time stamp countersignature and should
be the exact OID 1.3.6.1.4.1.311.3.2.1.

No attributes are currently included in the time stamp request.

The content is a ContentInfo as defined by PKCS #7. The content is the
data to be signed. For signature time stamping, the ContentType should
be Data, and the content should be the encryptedDigest (signature) from
the SignerInfo of the PKCS #7 content to be time stamped.


Time Stamp Response

The time stamp response is also sent within an HTTP 1.1 message. In the
HTTP header, the Content-Type directive is also set to
application/octet-stream. The body of the HTTP message is a base64
encoding of DER encoding of the time stamp response.

The time stamp response is a PKCS #7 signed message signed by the time
stamper. The ContentInfo of the PKCS #7 message is identical to the
ContentInfo received in the time stamp. The PKCS #7 content contains the
signing time authenticated attribute (defined in PKCS #99, OID
1.2.840.113549.9.5).

After Authenticode receives the time stamp from the server, Authenticode
incorporates the time stamp into the original PKCS #7 *SignedData*
<http://msdn.microsoft.com/en-us/library/windows/desktop/aa387722%28v=vs.85%29.aspx>
as a countersignature. To accomplish this, the ContentInfo of the
returned PKCS #7 *SignedData* is discarded, and the SignerInfo of the
returned time stamp is copied as a countersignature into the SignerInfo
of the original PKCS #7 *SignedData*. The certificate chain of the time
stamper is also copied into Certificates in the original PKCS #7
*SignedData* as an unauthenticated attribute of the original signer.

[Jakob Bohm]

I have written a few posts about this timestamp format on this list
before, here are my supplemental comments to your description and

Post by Walter H.
Hello,
has anybody got an idea, how to programm/get such a timestamp server -
is not RFC 3161 conform -
with using OpenSSL on Linux;

The RFC 3161 protocol postdates the MS format and produces responses
that are useless as PKCS#7/CMS countersignatures (RFC2985#5.3.6), this
may be a "feature" of RFC 3161 due to the horrible patent landscape it
was created in.

The parts of RFC2985/PKCS#9 used by this protocol seem to have been
part of the original 1991 PKCS#9 v1.0.

Post by Walter H.
attached are the ASN.1 dump of the received and sent package - in this
case the signtool.exe sends the query to
http://timestamp.verisign.com/scripts/timestamp.dll and receives from
there the reply;
- send (request): mssendts-asn1.text
- receive (reply): msrecvts-asn1.text
(these I recorded with wireshark)
openssl smime -pk7out -in received.der -inform DER -sign -out
pkcs7reply.der -outform DER -md sha1 -signer cert.pem -inkey key.pem
-passin file:passphrase

Won't work (as you saw), this function doesn't take the actual
ContentInfo structure as input, but data which it will (mis)treat
as an e-mail and then wrap in its own ContentInfo. Notice how the
messageDigest in your result is not the one in the result from the
original RSADSI/VeriSign/Thawte/Symantec server.

When the input specifies a content type of "data", you could use
the bytes inside the inner OCTET STRING as input to cms like this
openssl cms -sign -binary -content filewithrawdata.bin -outform DER
to get something close to the right response, but this won't work
if the request specifies a different content type.

Post by Walter H.
but there I'm missing the original 256 bytes of the received query,
and the SECTION with OID 1.2.840.113549.1.9.15 (sMIMECapabilities) is
too much;
see the 3rd attachment: pkcs7reply-asn1.text
below is the "spec" from MSDN;
how can I achieve this?

I think there was a SourceForge project related to this
(http://sf.net/projects/osslsigncode/)
But I don't know its status.

Post by Walter H.
Thanks,
Walter
Time Stamp Request
The time stamp request is sent within an HTTP 1.1 POST message. In the
HTTP header, the CacheControl directive is set to no-cache, and the
Content-Type directive is set to application/octet-stream. The body of
the HTTP message is a base64 encoding of /Distinguished Encoding Rules/
<http://msdn.microsoft.com/en-us/library/windows/desktop/ms721573%28v=vs.85%29.aspx#_security_distinguished_encoding_rules_gly>
(DER) encoding of the time stamp request.
Although not currently used, the Content-Length directive should also be
used in constructing the HTTP message because it helps the time stamp
server locate where the request is within the HTTP POST.
Other HTTP headers may also be present and should be ignored if they are
not understood by the requestor or time stamp server.
The time stamp request is an ASN.1 encoded message. The format of the
request is as follows.
Copy
TimeStampRequest ::= SEQUENCE {
countersignatureType OBJECT IDENTIFIER,
attributes Attributes OPTIONAL,
content ContentInfo
}
The countersignatureType is the /object identifier/
<http://msdn.microsoft.com/en-us/library/windows/desktop/ms721599%28v=vs.85%29.aspx#_security_object_identifier_gly>
(OID) that identifies this as a time stamp countersignature and should
be the exact OID 1.3.6.1.4.1.311.3.2.1.
No attributes are currently included in the time stamp request.
The content is a ContentInfo as defined by PKCS #7. The content is the
data to be signed. For signature time stamping, the ContentType should
be Data, and the content should be the encryptedDigest (signature) from
the SignerInfo of the PKCS #7 content to be time stamped.

ContentInfo is defined in RFC2315#7 (PKCS#7) and in RFC5652#3 (CMS)
SignerInfo is defined in RFC2315#9.2 (PKCS#7) and in RFC5652#5.3 (CMS)

Post by Walter H.
Time Stamp Response
The time stamp response is also sent within an HTTP 1.1 message. In the
HTTP header, the Content-Type directive is also set to
application/octet-stream. The body of the HTTP message is a base64
encoding of DER encoding of the time stamp response.
The time stamp response is a PKCS #7 signed message signed by the time
stamper. The ContentInfo of the PKCS #7 message is identical to the
ContentInfo received in the time stamp. The PKCS #7 content contains the
signing time authenticated attribute (defined in PKCS #99, OID
1.2.840.113549.9.5).

This is RFC2985#5.3.3 signingTime, The OID in the MSDN spec is a
misprint, it is 1.2.840.113549.1.9.5 according to both
the RFC and my dumps of real signatures.

This is also specified in RFC5652#11.3 (CMS).

Post by Walter H.
After Authenticode receives the time stamp from the server, Authenticode
incorporates the time stamp into the original PKCS #7 *SignedData*
<http://msdn.microsoft.com/en-us/library/windows/desktop/aa387722%28v=vs.85%29.aspx>
as a countersignature. To accomplish this, the ContentInfo of the
returned PKCS #7 *SignedData* is discarded, and the SignerInfo of the
returned time stamp is copied as a countersignature into the SignerInfo
of the original PKCS #7 *SignedData*. The certificate chain of the time
stamper is also copied into Certificates in the original PKCS #7
*SignedData* as an unauthenticated attribute of the original signer.

This spec matches my observations and dumps, note that counterSignature
is exactly as defined in RFC2985#5.3.6 and the MS timeStamping protocol
is designed to return a signature that can be used for this.

counterSignature is also specified in RFC5652#11.4 (CMS), however
contrary to the text of RFC5652#11.4, it is acceptable for the
counterSignature to specify a "ContentType" attribute with a value
of "data" (1.2.840.113549.1.7.1), as would be caused by the time
stamping server blindly complying with RFC5652#5.3 as its response is
technically not a counterSignature attribute until after manipulation
by the client.

Enjoy

Jakob

[Ryan Hurst]

Also this might be useful for implementers:
http://msdn.microsoft.com/en-us/library/windows/desktop/bb931395(v=vs.85).as
px

-----Original Message-----
From: owner-openssl-users-MCmKBN63+***@public.gmane.org
[mailto:owner-openssl-users-MCmKBN63+***@public.gmane.org] On Behalf Of Jakob Bohm
Sent: Tuesday, March 19, 2013 12:07 PM
To: openssl-users-MCmKBN63+***@public.gmane.org
Subject: Re: Timestamp for Microsoft Authenticode?

I have written a few posts about this timestamp format on this list before,
here are my supplemental comments to your description and

Post by Walter H.
Hello,
has anybody got an idea, how to programm/get such a timestamp server -
is not RFC 3161 conform - with using OpenSSL on Linux;

The RFC 3161 protocol postdates the MS format and produces responses
that are useless as PKCS#7/CMS countersignatures (RFC2985#5.3.6), this
may be a "feature" of RFC 3161 due to the horrible patent landscape it
was created in.

The parts of RFC2985/PKCS#9 used by this protocol seem to have been
part of the original 1991 PKCS#9 v1.0.

Post by Walter H.
attached are the ASN.1 dump of the received and sent package - in this
case the signtool.exe sends the query to
http://timestamp.verisign.com/scripts/timestamp.dll and receives from
there the reply;
- send (request): mssendts-asn1.text
- receive (reply): msrecvts-asn1.text
(these I recorded with wireshark)
openssl smime -pk7out -in received.der -inform DER -sign -out
pkcs7reply.der -outform DER -md sha1 -signer cert.pem -inkey key.pem
-passin file:passphrase

Won't work (as you saw), this function doesn't take the actual
ContentInfo structure as input, but data which it will (mis)treat
as an e-mail and then wrap in its own ContentInfo. Notice how the
messageDigest in your result is not the one in the result from the
original RSADSI/VeriSign/Thawte/Symantec server.

When the input specifies a content type of "data", you could use
the bytes inside the inner OCTET STRING as input to cms like this
openssl cms -sign -binary -content filewithrawdata.bin -outform DER
to get something close to the right response, but this won't work
if the request specifies a different content type.

Post by Walter H.
but there I'm missing the original 256 bytes of the received query,
and the SECTION with OID 1.2.840.113549.1.9.15 (sMIMECapabilities) is
too much;
see the 3rd attachment: pkcs7reply-asn1.text
below is the "spec" from MSDN;
how can I achieve this?

I think there was a SourceForge project related to this
(http://sf.net/projects/osslsigncode/)
But I don't know its status.

Post by Walter H.
Thanks,
Walter
Time Stamp Request
The time stamp request is sent within an HTTP 1.1 POST message. In the
HTTP header, the CacheControl directive is set to no-cache, and the
Content-Type directive is set to application/octet-stream. The body of
the HTTP message is a base64 encoding of /Distinguished Encoding Rules/

<http://msdn.microsoft.com/en-us/library/windows/desktop/ms721573%28v=vs.85%
29.aspx#_security_distinguished_encoding_rules_gly>

Post by Walter H.
(DER) encoding of the time stamp request.
Although not currently used, the Content-Length directive should also be
used in constructing the HTTP message because it helps the time stamp
server locate where the request is within the HTTP POST.
Other HTTP headers may also be present and should be ignored if they are
not understood by the requestor or time stamp server.
The time stamp request is an ASN.1 encoded message. The format of the
request is as follows.
Copy
TimeStampRequest ::= SEQUENCE {
countersignatureType OBJECT IDENTIFIER,
attributes Attributes OPTIONAL,
content ContentInfo
}
The countersignatureType is the /object identifier/

<http://msdn.microsoft.com/en-us/library/windows/desktop/ms721599%28v=vs.85%
29.aspx#_security_object_identifier_gly>

Post by Walter H.
(OID) that identifies this as a time stamp countersignature and should
be the exact OID 1.3.6.1.4.1.311.3.2.1.
No attributes are currently included in the time stamp request.
The content is a ContentInfo as defined by PKCS #7. The content is the
data to be signed. For signature time stamping, the ContentType should
be Data, and the content should be the encryptedDigest (signature) from
the SignerInfo of the PKCS #7 content to be time stamped.

ContentInfo is defined in RFC2315#7 (PKCS#7) and in RFC5652#3 (CMS)
SignerInfo is defined in RFC2315#9.2 (PKCS#7) and in RFC5652#5.3 (CMS)

Post by Walter H.
Time Stamp Response
The time stamp response is also sent within an HTTP 1.1 message. In the
HTTP header, the Content-Type directive is also set to
application/octet-stream. The body of the HTTP message is a base64
encoding of DER encoding of the time stamp response.
The time stamp response is a PKCS #7 signed message signed by the time
stamper. The ContentInfo of the PKCS #7 message is identical to the
ContentInfo received in the time stamp. The PKCS #7 content contains the
signing time authenticated attribute (defined in PKCS #99, OID
1.2.840.113549.9.5).

This is RFC2985#5.3.3 signingTime, The OID in the MSDN spec is a
misprint, it is 1.2.840.113549.1.9.5 according to both
the RFC and my dumps of real signatures.

This is also specified in RFC5652#11.3 (CMS).

Post by Walter H.
After Authenticode receives the time stamp from the server, Authenticode
incorporates the time stamp into the original PKCS #7 *SignedData*

<http://msdn.microsoft.com/en-us/library/windows/desktop/aa387722%28v=vs.85%
29.aspx>

Post by Walter H.
as a countersignature. To accomplish this, the ContentInfo of the
returned PKCS #7 *SignedData* is discarded, and the SignerInfo of the
returned time stamp is copied as a countersignature into the SignerInfo
of the original PKCS #7 *SignedData*. The certificate chain of the time
stamper is also copied into Certificates in the original PKCS #7
*SignedData* as an unauthenticated attribute of the original signer.

This spec matches my observations and dumps, note that counterSignature
is exactly as defined in RFC2985#5.3.6 and the MS timeStamping protocol
is designed to return a signature that can be used for this.

counterSignature is also specified in RFC5652#11.4 (CMS), however
contrary to the text of RFC5652#11.4, it is acceptable for the
counterSignature to specify a "ContentType" attribute with a value
of "data" (1.2.840.113549.1.7.1), as would be caused by the time
stamping server blindly complying with RFC5652#5.3 as its response is
technically not a counterSignature attribute until after manipulation
by the client.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark. Direct [phone]
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Walter H.]

Hi,

thanks for your infos

can you please tell me, where I can find your postings to this topic,
you made in the past?

Post by Jakob Bohm
Won't work (as you saw), this function doesn't take the actual
ContentInfo structure as input, but data which it will (mis)treat
as an e-mail and then wrap in its own ContentInfo. Notice how the
messageDigest in your result is not the one in the result from the
original RSADSI/VeriSign/Thawte/Symantec server.
When the input specifies a content type of "data", you could use
the bytes inside the inner OCTET STRING as input to cms like this
openssl cms -sign -binary -content filewithrawdata.bin -outform DER

how should this work, because when calling openssl like this expects
input from stdin ...

Post by Jakob Bohm
to get something close to the right response, but this won't work
if the request specifies a different content type.
I think there was a SourceForge project related to this
(http://sf.net/projects/osslsigncode/)
But I don't know its status.

this is a good project, but I already have signcode.exe / signtool.exe;
I want to create the timestamp server part ..., using OpenSSL

I havn't used the OpenSSL source before ...

Thanks for any help,
Walter

[Jakob Bohm]

(No need to CC me, I get the list e-mails in the same inbox).

You could use any of the archives of the mail lists that are mentioned
on openssl.org.

However, I think I have repeated all the stuff you didn't already
discover in
todays post, just to keep everything together in one place.

Post by Walter H.
Hi,
thanks for your infos
can you please tell me, where I can find your postings to this topic,
you made in the past?

Post by Jakob Bohm
Won't work (as you saw), this function doesn't take the actual
ContentInfo structure as input, but data which it will (mis)treat
as an e-mail and then wrap in its own ContentInfo. Notice how the
messageDigest in your result is not the one in the result from the
original RSADSI/VeriSign/Thawte/Symantec server.
When the input specifies a content type of "data", you could use
the bytes inside the inner OCTET STRING as input to cms like this
openssl cms -sign -binary -content filewithrawdata.bin -outform DER

how should this work, because when calling openssl like this expects
input from stdin ...

Post by Jakob Bohm
to get something close to the right response, but this won't work
if the request specifies a different content type.
I think there was a SourceForge project related to this
(http://sf.net/projects/osslsigncode/)
But I don't know its status.

this is a good project, but I already have signcode.exe / signtool.exe;
I want to create the timestamp server part ..., using OpenSSL
I havn't used the OpenSSL source before ...
Thanks for any help,
Walter

--
Jakob Bohm, CIO, partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark. direct: [phone]
<call:[phone]>
This message is only for its intended recipient, delete if misaddressed.
WiseMo - Remote Service Management for PCs, Phones and Embedded
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Walter H.]

Hello,

I got two more replies of public time stamp servers,

- msrecv01ts-asn1.text
- msrecv02ts-asn1.text (used a different source, so the hash differs)
- msrecv03ts-asn1.text

the structure of these 3 replies look nearly the same as my two generated

- myreply01cms-asn1.text
- myreply02cms-asn1.text

but with mine there is shown an error

"the connection has reached the time limit or the reply of the time
stamp service is invalid"

here is my command:

openssl cms -sign -in octet.bin -binary -out reply.der -outform DER (
-noattr ) -nosmimecap -nodetach -signer ts.crt -inkey ts.key -passin
file:ts.pass

( octet.bin is only the extracted hash of the request,
reply.der is the output,
ts.crt is the timestamp cert.
ts.key is the private key of the timestamp cert.
ts.pass is the pass phrase for the private key of the timestamp cert. )

both variants fail: with -noattr or without -noattr

what went wrong?
can someone please help me?

Thanks,
Walter

[Jakob Bohm]

Post by Walter H.
Hello,
I got two more replies of public time stamp servers,
- msrecv01ts-asn1.text
- msrecv02ts-asn1.text (used a different source, so the hash differs)
- msrecv03ts-asn1.text
the structure of these 3 replies look nearly the same as my two generated
- myreply01cms-asn1.text

This one lacks the data part, it seems to have been generated without
the "-nodetach" option.

Post by Walter H.
- myreply02cms-asn1.text

This one has the data part, but lacks the "signingTime" attribute which
is the whole point of this exercise.

Post by Walter H.
but with mine there is shown an error
"the connection has reached the time limit or the reply of the time
stamp service is invalid"
openssl cms -sign -in octet.bin -binary -out reply.der -outform DER (
-noattr ) -nosmimecap -nodetach -signer ts.crt -inkey ts.key -passin
file:ts.pass
( octet.bin is only the extracted hash of the request,

I presume you mean the data in the request, not the hash.

Post by Walter H.
reply.der is the output,
ts.crt is the timestamp cert.
ts.key is the private key of the timestamp cert.
ts.pass is the pass phrase for the private key of the timestamp cert. )
both variants fail: with -noattr or without -noattr
what went wrong?
can someone please help me?
Thanks,
Walter

Enjoy

Jakob

[Walter H.]

Post by Jakob Bohm
This one lacks the data part, it seems to have been generated without
the "-nodetach" option.

Post by Walter H.
- myreply02cms-asn1.text

This one has the data part, but lacks the "signingTime" attribute which
is the whole point of this exercise.

how can I correct this?

myreply03cms-asn1.text doesn't work either, same error

Thanks,
Walter

[Raghav Varadan]

Hi,

I'm getting the following failure when trying to build FIPS capable openssl
in windows:

ectest
Curve defined by Weierstrass equation
y^2 = x^3 + a*x + b (mod 0x17)
a = 0x1
b = 0x1
Point is not on curve: x = 0xD, y = 0xFFFFA41E
.\crypto\ec\ectest.c:318: ABORT
problems.....

The operating system I'm in Windows 7 and following are the steps I did:

1) ms\do_fips no-asm

2) perl Configure VC-WIN32 fips --with-fipslibdir=c:\fips\path

3) ms\do_nasm

4) ms\do_nt

5) nmake -f ms\nt.mak

6) cd out32
..\ms\test


The crypto test passes if do the normal build. That is changing step 2: to
:perl Configure VC-WIN32

I'm kinda lost with this and thought would get some help from the user
group.

Thanks

Raghav