How do you deploy your own Authenticode Timestamping Service?

Question

I would like to timestamp my DLL file with my own Authenticode Timestamping Service. Is this possible? How could I achieve this?

Elijaheliminate

Answer 1

You can develop your own timestamping service. You can write TSP (RFC 3161) server but Authenticode doesn't use RFC 3161 but PKCS#7/PKCS#9 formats as described in MSDN article (which you can implement as well). Our SecureBlackbox components include timestamping server component which supports both formats. Update: recent updates to Authenticode use standard RFC 3161 timestamps.

But the problem is to get the certificate which you will use to sign timestamps. This certificate must be issued by one of the CAs and as I understand, there exist severe requirements regarding management and infrastructure aspects of running a timestamp server. In particular you need to have a secure timestamping hardware. I didn't dig deep into this question, but these aspects are much more complicated then writing a piece of code.

Still if you run your own PKI infrastructure (have your own trusted root certificates and CA certificates), then the problem of having a trusted timestamping certificate is solved automatically - you can generate your own certificate.

Toomey

Answer 2

You need to write a custom HTTP Timestamp server. It should follow RFC 3161 Time-Stamp Protocol (TSP) rules.

When you sign your DLL for authenticode with a tool such as Signtool.exe from the Windows SDK, you can specify the url of the timestamp server (with the /t swich. See also /tr and /td). You would then point to your server.

See here on SO for a related question: Trusted Timestamps - understanding the format (rfc3161)

and also: Alternative timestamping services for Authenticode

Flickertail

Authenticode doesn't use RFC 3161. It uses PKCS#7/PKCS#9 formats. – Prying

Answer 3

You can set up your own Time-stamping Authority (TSA) supporting Authenticode time-stamps (and/or RFC#3161) using SignServer.

See https://www.signserver.org for the download and the installation instructions. In summary the important steps are:

1. Make sure you have the pre-requisites:

   • Java
   • An application server (i.e. WildFly)
   • Apache Ant for deploying

2. Download the 4.0 release from https://signserver.org or https://sourceforge.net/projects/signserver/files/signserver/4.0/ .

3. Configure application server

   • For HTTPS (optional)
   • To make web services work
   • Patch with the latest security fixes

4. Configure SignServer deployment

   • Set database.name=nodb and database.nodb.location=/an/empty/folder/as/db in conf/signserver_deploy.properties

5. Deploy SignServer

   • export APPSRV_HOME=/opt/wildfly-9/
   • bin/ant deploy
   • Start application server /opt/wildfly-9/bin/standalone.sh

6. Check that server started

   • bin/signserver getstatus brief all

7. Setup a crypto token

   • bin/signserver setproperties doc/sample-configs/keystore-crypto-configuration.properties
   • bin/signserver reload 1
   • bin/signserver getstatus brief all

8. Setup a sample time-stamp signer

   • bin/signserver setproperties doc/sample-configs/qs_timestamp_configuration.properties
   • bin/signserver reload 2
   • bin/signserver getstatus brief all

9. Test the time-stamp signer

   • bin/signclient timestamp http://localhost:8080/signserver/process?workerName=TimeStampSigner

Wawro

The 'download the latest release' part is likely to invalidate many of the other instructions here more speedily than simple link-rot. It's a little naive to expect the poster to return here and update the instructions for any new releases, so I feel a simple link would have been more appropriate. – Hokanson

Thanks. I updated the link to specify the 4.0 version matching the instructions (and currently is the latest version). – Wawro

Answer 4

Assuming you are wanting this for testing, if you are happy to use signtool.exe with the /tr switch, you don't have to look at the RFC, because openssl implements enough of this for you. Simply write an HTTP POST handler in your favourite language, pass the posted data into "openssl ts -reply" verbatim, send back the openssl TS response data. This is good enough to fool "signtool.exe verify /pa", even if it isn't strictly following the RFC.

EDIT: It seems the open-source Java Signserver project gives you a server handling MSauthenticode (/t) and rfc3161 (/tr) timestamping out of the box. Configuration of Signserver involved too many dependencies for me, so I instead hacked its unit test for MSAuthenticode timestamping, bolted on a small HTTP server to the test case, and with little work - my Java skills are mediocre at best - have a running authenticode timestamp server for development use, and have verified that the timestamps thus created are not subject this issue. I cannot release the source code, however following this tip should get you something working pretty quickly.

Hokanson