Didier Stevens

Update: if you don’t have access to a machine with OpenSSL, I created a website to generate certs using the procedure described here. Read through the procedure, and then use the website listed at the end. And if you don’t want your private key generated on a server you don’t own, download my tool I created for Windows that doesn’t require installation: CreateCertGUI.

I also made a video showing the full procedure.

Ever wanted to make your own public key certificate for digital signatures? There are many recipes and tools on the net, like this one. My howto uses OpenSSL, and gives you a cert with a nice chain to your root CA.

First we generate a 4096-bit long RSA key for our root CA and store it in file ca.key:

openssl genrsa -out ca.key 4096

Generating RSA private key, 4096 bit long modulus
...................................................................................++
........................................................................++
e is 65537 (0x10001)

If you want to password-protect this key, add option -des3.

Next, we create our self-signed root CA certificate ca.crt; you’ll need to provide an identity for your root CA:

openssl req -new -x509 -days 1826 -key ca.key -out ca.crt

You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:BE
State or Province Name (full name) [Berkshire]:Brussels
Locality Name (eg, city) [Newbury]:Brussels
Organization Name (eg, company) [My Company Ltd]:https://DidierStevens.com
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:Didier Stevens (https://DidierStevens.com)
Email Address []:didier stevens Google mail

The -x509 option is used for a self-signed certificate. 1826 days gives us a cert valid for 5 years.

Next step: create our subordinate CA that will be used for the actual signing. First, generate the key:

openssl genrsa -out ia.key 4096

Generating RSA private key, 4096 bit long modulus
.....++
.............................................................................++
e is 65537 (0x10001)

Then, request a certificate for this subordinate CA:

openssl req -new -key ia.key -out ia.csr

You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:BE
State or Province Name (full name) [Berkshire]:Brussels
Locality Name (eg, city) [Newbury]:Brussels
Organization Name (eg, company) [My Company Ltd]:https://DidierStevens.com
Organizational Unit Name (eg, section) []:Didier Stevens Code Signing (https://DidierStevens.com)
Common Name (eg, your name or your server's hostname) []:
Email Address []:didier stevens Google mail

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Next step: process the request for the subordinate CA certificate and get it signed by the root CA.

openssl x509 -req -days 730 -in ia.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out ia.crt

Signature ok
subject=/C=BE/ST=Brussels/L=Brussels/O=https://DidierStevens.com/OU=Didier Stevens Code Signing (https://DidierStevens.com)/emailAddress=didier stevens Google mail
Getting CA Private Key

The cert will be valid for 2 years (730 days) and I decided to choose my own serial number 01 for this cert (-set_serial 01). For the root CA, I let OpenSSL generate a random serial number.

That’s all there is to it! Of course, there are many options I didn’t use. Consult the OpenSSL documentation for more info. For example, I didn’t restrict my subordinate CA key usage to digital signatures. It can be used for anything, even making another subordinate CA. When you buy a code signing certificate, the CA company will limit its use to code signing.

To use this subordinate CA key for Authenticode signatures with Microsoft’s signtool, you’ll have to package the keys and certs in a PKCS12 file:

openssl pkcs12 -export -out ia.p12 -inkey ia.key -in ia.crt -chain -CAfile ca.crt

Enter Export Password:
Verifying - Enter Export Password:

To sign executables in Windows with the signtool: install file ia.p12 in your certificate store (e.g. double click it), and then use signtool /wizard to sign your PE file.

I’ve used this process to generate certs for my own code signing, and for my Authenticode Challenge.

Update: don’t have OpenSSL? Use my website https://toolbokz.com/gencert.psp

The title of this post is inspired by Mark Russinovich‘s posts. I explain why there is a category of executables with a digital signature that don’t show a “Digital Signatures” tab in the properties dialog, and I release a tool to manipulate digital signatures.

Executables (PE files) can have a digital signature, Microsoft calls this signature AuthentiCode. There are 2 different ways to sign a PE file: by adding a digital signature to the PE file (embedded digital signature) or by adding a hash of the PE file to a security catalog file (filetype .CAT).

The Properties dialog of a file hosts a Digital Signatures tab when the PE file has an embedded digital signature, like this Windows patch from Microsoft:

But when a file is signed via a security catalog file, the Digital Signatures tab is not displayed. Notepad is a good example:

To check the digital signature of this category of files, one uses Microsoft’s signtool or Mark’s sigcheck utility:

These tools will calculate the hash of the file, look it up in the appropriate security catalog file and check the signature of the security catalog file. One can find security catalog files in directory C:\windows\system32\catroot:

For an embedded digital signature, the location of the signature is at the end of the signed file. Look for DATA_DIR Security in IMAGE_DATA_DIRECTORIES of the optional PE header. It has a pointer (4 bytes) to the signature and the length (4 bytes) of the signature. The pointer is just the offset in the binary file. When these bytes are all zero (0x00), the PE file has no embedded digital signature.
Here is the PE header of another Windows patch:

In this patch, the signature entry can be found at offset 0xF4E00 in the file and is 0x2428 bytes long:

The first 4 bytes of the signature entry is the size, the following 4 bytes is a constant (0x00020200), and the rest is the PKCS7 signature. This signature can be extracted with a binary editor and parsed with openssl:

Finally, I wrote a small Python program to manipulate embedded digital signatures. Features of disitool:

• delete a signature: disitool.py delete signed-file unsigned-file
• copy a signature: disitool.py copy signed-source-file unsigned-file signed-file
• extract a signature: disitool.py extract signed-file signature
• add a signature: disitool.py add signature unsigned-file signed-file

As a Belgian citizen, the federal government issued me an electronic ID (eID). It’s essentially a smart card with personal data, my picture (jpeg) and a couple of X.509 certificates for authentication and digital signing.

One of its applications is authentication on web sites. And this is already possible now, provided I’ve a smart card reader and I install the necessary software provided by the federal government.

Now take a look at the properties of the Windows setup file for the eID client software:

Now I expect to see something here, but it’s missing. Do you miss it too? Here’s a hint:

That’s right, the installation program is not digitally signed (AuthentiCode). Neither are any of the executables installed by the installation program.

I’m surprised that the government invests in a PKI to issue IDs to all its citizens, yet it doesn’t deem it necessary to invest in a delivery mechanism that certifies the origin and integrity of the client software.