A digital signature is an encrypted hash code computed using the private key portion of an asymmetric key pair. Anyone can compute digital signatures for any number of hash codes using any number of self-generated key pairs. In addition to the potential for theft or insider misuse of key pairs, this is a real threat to the integrity of digital signatures. Anyone who succeeds in precomputing every possible key pair along with a meaningful signed hash cryptographic transformation using the private key of such a key pair will essentially possess the ability to discover which of the possible key pairs you, or somebody you trust, is actually using.
In principle, it is supposed to take millions of years for a supercomputer cluster to precompute every possible digital signature for every possible hash code given relatively large bit length hashes (e.g., 160 bit for System.Security.Cryptography.SHA1, 256 bit for SHA256, 384 bit for SHA384, 512 bit for SHA512) and large bit length asymmetric ciphers with big keys. By the time anyone devotes enough computing power to the problem, anything digitally signed today will no longer be of importance, we will all have switched to much larger bit length cryptosystems, and there should be no real-world attack possible by virtue of the existence of such comprehensive key space precomputation dictionaries. Nevertheless, the fact that successful precomputation attacks are possible, and that such attacks will be indistinguishable from a replacement signature that appears valid because the replacement signature was computed using the very same trusted key pair already deployed to our boxes, means that diligence in key management and awareness, of the extent to which we already depend on particular keys for security, are crucial.
Since good key management underpins the web of trust tied to a given key, any facility that allows us to better understand and keep track of the keys being used by third parties is a valuable addition to our security capabilities. When we place trust in an SSL server's identity based on certificate chain validation, we explicitly allow any number of third-party Certificate Authorities (CA) to compromise our security either on purpose or by accident.
In an article entitled "Using Trusted Public Keys in SSL Connections" (http://www.windevnet.com/documents/s=8900/win0309a/0309a.htm), I detailed the way in which an SSL server's X.509 certificate details could be analyzed at runtime using .NET's X509Certificate class for the purpose of more reliably establishing the server's identity. There's good reason to apply this same thinking to signed files because we receive these files from what we believe to be a trusted source, and there are ways for attackers to undermine and exploit this belief to deliver to us malicious (yet digitally signed) binaries. Microsoft doesn't SSL-encrypt its download servers, and there is no automatic signature verification process in place to verify files that we download from Microsoft before we execute them. Any attacker could trick us into accepting and executing their code with a simple DNS-based attack to hijack our HTTP or FTP sessions with what we mistakenly believe to be Microsoft's authentic servers.
To properly monitor our risk exposure to poor key-management practices, we must analyze the digital signatures that are attached to published files. The .NET Framework makes this easy enough. Listing 1 shows one way to do it using the X509Certificate class, which contains a CreateFromSignedFile method that gives us easy access to the details of signatures applied to many of the Portable Executable (PE) files published by Microsoft. Somebody should write a suite of forensic security utilities that extract important information like this from files we choose to trust, and help us make better informed trust decisions as we receive future deliveries of similar files from what we believe to be the same trusted source.
Listing 1: Using the CreateFromSignedFile method of the X509Certificate class
using System;<br>using System.Security.Cryptography.X509Certificates;<br>using System.IO;<br>namespace PKInventory {<br>class main {<br>[STAThread] static void Main(string[] args) {<br>X509Certificate xcert = null;<br>try {<br>DirectoryInfo d = new DirectoryInfo(Directory.GetCurrentDirectory());<br>FileInfo[] allFiles = d.GetFiles();<br>foreach (FileInfo f in allFiles) {<br>xcert = X509Certificate.CreateFromSignedFile(f.Name);<br>System.Out.WriteLine(f.Name + "\t" + xcert.GetName() + "\t" +<br>xcert.GetPublicKeyString()); }}<br>catch (Exception e) {System.Out.WriteLine(f.Name + ": Unable to read<br>DER-encoded signature.");}<br>}}}<br>
The output of the PKInventory program could be imported into a spreadsheet program or used as the basis of a simple database application that keeps a comprehensive map of files on the hard drive that include digital signatures, the apparent signer, and the public key used.
Microsoft doesn't help us quantify or keep track of the web of trust that it has deployed around each of its many key pairs. Furthermore, Microsoft can arbitrarily issue new key pairs because it controls several root CA certificates that our Windows boxes trust by default. Microsoft is the definitive source of information about what has been signed, what has actually been published, and which public keys are being used. With that in mind, one would think it would be an obvious and critical need for Microsoft security to produce a simple XML Web service that provides us all with access to this information.
Don’t assume that anything that appears to be signed by Microsoft is necessarily trustworthy. It is no more difficult for a computationally wealthy attacker to discover—or a motivated attacker to steal—one of Microsoft's root CA key pairs than it is for the attacker to target a less important key pair used only for signing individual items. Yet when Microsoft deploys new key pairs, users pay little or no attention. This is dangerous circular logic with a built-in presumption of impenetrability.
Jason Coombs works as forensic analyst and expert witness in court cases involving
digital evidence. Information security and network programming are his areas
of special expertise. He can be reached at [email protected].
