If Outlook cannot decrypt an S/MIME e-mail it displays the error message “Your digital ID name cannot be found by the underlying security system” which does not give any clues as to why. When this happens there is no easy way in Outlook to examine the message and see what certificates it was encrypted for.

To get this information I wrote a small program to scan through an encrypted message and look for data structures that resemble ASN1 sequences and print the Certificate Authority name and the certificate serial numbers. To use it copy the message to a file using click and drag from Outlook to Explorer and run the program in a CMD.EXE window giving the message file as input.

BITS (Background Intelligent Transfer Service) uses available bandwidth to transfer files in the background. Most use is downloading such as by Windows Update but it can also be used to upload files to an IIS server that has the BITS service enabled. The program “bitsadmin.exe” is included in the XP SP2 Support Tools available for download from Microsoft.com

If you have several similar large files to upload over a slow link you can use ‘rdiff’ to optimise the transfer. ‘rdiff’ compares files block by block and produces a delta file that contains only the blocks that differ.
It is therefore of most use when the two files are mostly similar but some parts different such as powerpoint product presentations targeted for two different customers.

In this example we have two similar but different documents:

$ dir *.doc

643,584 document-edition-two.doc
634,880 document-original.doc

Generate an MD5 hash to be used later to verify the file integrity
$ md5 document-edition-two.doc
8280AEAFABC0833D5FEC64CE5FEF6237 document-edition-two.doc

Prepare a “signature” file which contains hash codes of each block in the base file.

$ rdiff signature document-original.doc document.sig

Next I use that signature file to see which blocks are different in the second file and extract them to a delta file.

$ rdiff delta document.sig document-edition-two.doc document.delta

$ dir document.delta

78,504 document.delta

Note that the “delta” file is only 12% of the size of “document-edition-two.doc”, the relative file size depends on how similar the two documents are.

Now I upload the files “document-original.doc” and “document.delta”

On the server I (or the recipients of the files) run ‘rdiff’ to generate the second document from the first and the delta.
$ rdiff patch document-original.doc document.delta document-edition-two-reconstructed.doc

Check the MD5 hash to confirm that the second document has been faithfully reproduced.

How many times has someone forgotten to renew an SSL certificate? Often it is because a previous admin has moved to another function. Here is a program that I wrote to check the ‘time to live’ of certificates on servers remotely using OpenSSL. Read the source code for details on how to call it. Download it here and put it in a daily cronjob that sends you e-mail if renewal time is near.

Another way to prove the authenticity of the Root Certificate is to publish it signed by a certificate issued by a previously trusted PKI. This can be useful in the case where a PKI is being established to replace a legacy system.

I have previously used the Mozilla NSS tool CMSUTIL to sign a data file but this time I decided to write a program using the Microsoft CryptoAPI on Windows because that it less sensitive to expired certificates. NSS CMSUTIL will not validate the signature if the signing certificate has expired and that could be a problem in this case as we are using a certificate from a legact PKI to sign the Root Certificate of the replacement PKI.

When a company establishes a PKI they usually publish their Root Certificate on their web site. Often they publish cryptographic hashes of the Root Certificate so that people who download it can verify that it has not been tampered with. The problem is that if anyone was able to tamper with the published Root Certificate (by compromise of the web page or a man in the middle attack) then they would also be able to tamper with the published hashes.

I was involved in establishing a PKI and that set me thinking about how best to prove the authenticity of the Root Certificate. There are several ways. An obvious one is to use SSL on the web page. Another is to publish the hashes on multiple web sites, like this blog for example. So, here they are: Root Certificate hashes

This morning I was testing a program that builds a certificate request (for S/MIME encryption) and submits it to a CA in our new MS PKI. The tests went well and I generated, installed and deleted some certificates. Later my colleague Thomas ran the program to install a certificate and sent me a signed (and encrypted) e-mail. I was surprised to find that I could not read it in Outlook.

This is how Outlook tels you that you do not have the private key needed to decrypt the message.

Fortunatly I had backed up my certificates (this was Windows XP so I used “certmgr.msc” to export the certs, with private keys) before the tests. Rather than re-install all the certificates I decided to see what certificate Thomas had encrypted the e-mail for but Outlook stubbornly refused to let me inspect the e-mail in any way or to save it to a file.

As we have IMAP enabled in our Exchange environment I used Thunderbird to download the e-mail and save it to a file which I then edited to remove the headers. That left just the base64 encoded S/MIME part.

I decoded that by “base64 -d thomas.b64 > thomas.bin” which left me with an encrypted blob that contains a few strings in that tells you which Certificate Authority issued the certificates that it is encrypted for but no indication of the recipients. S/MIME uses CMS format which identifies the intended recipients by only two attributes: the issuing CA name and the serial numer of the certificate.

CMS uses ASN1 so you can parse this blob using the ASN1 parser in OpenSSL:

openssl asn1parse -in thomas.bin -inform DER > thomas.txt

View the output and you will find some lines like this repeated for each recipient :

The third line is the serial number of the certificate (the MS Certificate Authority adds some “randomness” to the high bytes of the serial numbers). Then I went through my backup and sure enough found that I have an encryption certificate serial number ….001A and once I had re-installed that cert Outlook was able to decrypt the e-mail.

The BBC 3 program “The Real Hustle” is an excelent presentation of just how easy you could be scammed out of your money or confidential information.
The three presenters have real experience scamming and now they are showing their skills on television so that you can avoid being conned.

One of my favourites is the WiFi scam and it is one that is often targeted at the business traveller. It works best in a business hotel or at an airport.

The next time you connect to a WiFi network in a hotel or cafe think of this video clip and don’t type in your credit card number or company passwords.