When one thinks about signing, I dare to say, many only think about the integrity aspect. That is, a digital signature prevents tampering around with the data without being unnoticed. For example, during installation of some signed software the system could report that the signature is broken. The reasons could be that the data got garbled during transmission, for example while downloading, or that someone modified it.

But even a valid signature is no guarantee for receiving “secure software”. What is also very important is to know with certainty who signed the software. Only if one trusts the signer and the signature is not broken then one can be relatively sure that the software is safe to use. Just think about a criminal who takes some software, adds a virus to it, signs and eventually distributes it. Distribution could occur through the countless “free software sites”, or fake sites, which resemble very closely the original. That person could also hack into the original site and exchange the download package with the manipulated one and probably some checksum on a web site (most normal users do not even think about comparing check sums :).

Users, who install the software, will be told by the system that the software is signed and the signature is valid. That certainly reassures users, so they will continue with the installation and open the door to their systems for viruses or malware which come with the software.

Therefore one should always verify the signer of the software. To make this possible, a signed package typically contains a certificate. This certificate is assigned to a particular person. The certificate was issued by some organization for which exist a certificate as well. That certificate could be issued by another organization, etc. ... The root of this chain is typically installed on the system (firefox, thunderbird also have some built-in root certificates) and is regarded as trusted. Each certificate was signed by the private key which belongs to the certificate of the issuer. Therefore it is impossible to introduce a fake certificate into the chain, without noticing it. Now, the reasoning is, that if I trust the root certificate then I trust all certificates in a chain. When the system checks a signature then it will also check the signer, that is, the certificate. If both validates OK then the user gets the “thumps up” for continuing.

STOP!!!

Here is another lurking trap. Just seeing the properly closed padlock icon or some other icon which indicates a valid certificate is no guarantee either. Many of us use https and know that a secure connection is indicated by the padlock icon. Who of us always clicks on the icon and verifies the name of the signer?

It is easily possible to get test certificates from certificate authorities by just providing an e-mail address and a name. This certificate may also validate OK on your system, because it has the corresponding root certificates. So a criminal may obtain a test certificate and use it to sign (with the corresponding private key) the software.

Therefore one should always check the 'subject name' of the certificate with the expected name of the signer. A subject name typically consists of various part, for example:

CN (Common Name)
OU (Organisational Unit)
L (Location)
O (Organization)
ST (State)
C (Country)
E (E-Mail)

All the certificate authorities where I got a test certificate from did not allow to specify all fields. So if the name contains only an e-mail address or words like “Free” or ”Test” etc. be careful.

Talking about certificates ...

The last days I had a look at different crypto or security APIs in order to find a candidate for use in OOo. One motivation was to find an API which delivers the same results on all platforms. Certificate validation is a very complicated process. Here are a few things, which need to be investigated:

1. unknown critical extension
2. correct chain  
3. valid signatures
4. valid time
5. correct subject name (name constraints )
6. valid policies
7.  path length
8.  key usage (including those of the CA's certificates)
9.  revocation status
10.  ...

Even without understanding the separate items, one gets an idea that the certificate validation is not a simple thing. Adding to that, it is not done with just checking the one certificate but one needs to check a whole chain of certificates. One also speaks of certificate paths. To top it all, there can be multiple certificate paths and not all must validate OK.

Some validation functions are tightly coupled with a certificate store. That is, the validation algorithmus can directly access the store to obtain all certificates which it needs to build the certificate path. The caller of the validation function does not need to provide them. This is different when the validation library does not have direct access. Then the caller need to provide them before the actual validation starts. Although there are ways to obtain the intermediate certificates dynamically, one still needs to add a trusted root certificate. For example: 

 Certificate c = getTrustedCertificateFromSystemKeystore();
 addTrustedCertificateToValidationLibrary(c);
 validateActualCertificate(cert);

Certificate c = getTrustedCertificateFromSystemKeystore();
addTrustedCertificateToValidationLibrary(c);
// injecting the bad certificate 
addTrustedCertificateToValidationLibrary(myRogueCertificate);
// ----
validateActualCertificate(cert);

• load / save documents from a wrong location (https)

• receive manipulated signed documents

• or downloaded manipulated updates (provided that signed updates is implemented)

The last point is interesting, because OOo could be manipulated to download updates from different locations, for example, the hacker's download site. And this way, OOo could obtain the latest versions of viruses/malware, etc. with every update. Let me remind you that the update could be digitally signed - it would not matter.

Now back to the code example. The next idea was that it is better to use a validation API of the system, which has direct access to the certificates in the system's certificate store. It is certainly more difficult to manipulate the operating system itself.

With using the system's API the weak point in our implementation has vanished:

// there is no more to do than validating:
validateActualCertificate(cert);

My conclusion was therefore that OOo should prefer the system API instead. But this conclusion did not hold up for very long.

The question is, how do users perceive the result of the validation or how it is presented to them? The user will probable see a message box, with some text and icon which indicates the result of the validation. Here's a bit more pseudo code:

 
bool validationResult = validateCertificate(cert);
if (true == validationResult)
    showAllIsWellMessageBox();
else
    showThisIsAScamMessageBox();

But what is going to prevent somebody to modify OOo to always accept their own certificate?

bool validationResult = validateCertificate(cert);

if (true == validationResult
   || cert == rogueCert) 
	showAllIsWellMessageBox();
else
    showThisIsAScamMessageBox();

At this point it is clear, that it does not matter if one uses the system's validation API or some other as long as the environments in which they are used are not secure. So all none-system APIs are vindicated :)

Conclusion: To prevent a manipulation, all the code of OOo which validates signature,certificates, and processes and displays the results to the user must be digitally signed.

Then the operating system can check the validity of the signature and the certificate during installation (or whatever the operating system does to verify signed code). As long as the OOo installation sets are not signed users should make sure to use trustworthy sources to obtain it.

Once a manipulated OOo has been installed it is too late. Then, features like

• https for save / load

• digitally signed documents

• digitally signed updates (not implemented yet)

have NO value to users. They cannot be sure that the signer is trusted, even if OOo says it is.

Now the optimists among us could argue that these features still put the hurdle up for attackers and therefore offer reasonable security. In my opinion, however, there is no such thing as “reasonable security”. If there is a security whole then it will be used sooner or later. Or would you have ever imagined that someone gets the idea to “poison” DNS caches?

tags: development security users