• United States



The hardware roots of trust

Apr 27, 20154 mins

Can you still trust your hardware encryption?

One question that frequently pops up in evaluating security systems is whether to use hardware-based or software-based encryption systems. Typically, hardware-based encryption is considered more secure because the encryption keys are embedded in the hardware and would require a very sophisticated attack at the hardware layer to acquire the encryption keys. In addition to better security, hardware-based encryption systems do not require system resources which results in much faster performance for cryptographic operations. Software-based encryption, on the other hand, are more vulnerable to hacking attacks particularly from virtual rootkits which penetrate the operating system. These rootkits are a primary threat to corporate systems with root kit malware being delivered to desktops using the attack vectors of social engineering and phishing emails.

This conventional wisdom of hardware being better than software for cryptography was recently called into question when secret documents procured by Edward Snowden were leaked which revealed that the National Security Agency (NSA) was working with chipmakers to insert backdoors and cryptographic weaknesses into their products, presumably for the NSA to access as the need arose. The processors of some manufacturers were thought to no longer be trusted because the random number generators (RNGs) needed to generate cryptographic keys had been sufficiently weakened to the point of failing to provide strong, near unbreakable encryption. In addition to deliberate sabotage, there is always a possibility, however slight, that some chips were faulty to the point of introducing vulnerabilities into the encryption process.

So do these doubts being raised mean that hardware encryption is no longer the preferred method of encryption? No. What it does mean, however, that extra precautions must be taken before blindly accepting a hardware based encryption system. There should be a due diligence evaluation process to ensure that the hardware based encryption system will worked with the needed levels of security. This is especially important for applications security sensitive data or high value transactions.

A first step should be to ensure that the product has been tested by an independent third party laboratory and has been certified against a known standard such as the Federal Information Processing Standard (FIPS) 140-2 or the Common Criteria for Information Technology Evaluation. FIPS 140-2 sets security requirements for cryptographic modules and has designated 4 levels of security certification with each level detailing the standards that must be met for increasing levels of security assurance.   The standard reviews the basic design and documentation, physical security measures, cryptographic algorithms and module interfaces. Certification can only be achieved through rigorous testing handled by third-party laboratories that are accredited as Cryptographic Module Testing laboratories.

The other accreditation process mentioned above, the Common Criteria for Information Technology Security Evaluation (or Common Criteria for short) as a much wider scope of review than FIPS, and covers the product from its inception, to final product and overall use.  Common Criteria reviews the software, hardware, and firmware of a device, as well as the overall development process of the product from planning to commercial release.  Almost every aspect and process which goes into the design, development, release, and support of the product is reviewed. Like FIPS, there are several levels of achievement based on the level of complexity, security and functionality necessary and Common Criteria has 7 levels of increasing security assurance.

So would obtaining these certification address the cited allegations of backdoors raised in documents leaked by Snowden? Maybe, but to be sure you could also introduce addition sources of randomness to the RNGs to ensure the encryption keys generated are sufficiently strong. This would also help guard against the possibility that faulty chips were generating less than random encryption keys. Thus, in general relying on multiple sources of randomness is a good practice.

The amount of money and effort invested in the due diligence should be commiserate with the level of security needed for the application. In layman’s terms, don’t go spending more on the bicycle lock than the bicycle is worth. That’s why hardware security encryption systems with advanced levels of FIPS or EAL certification are usually reserved for national security or financial applications.

In summary, using hardware based encryption is still your best choice for secure transactions at higher processing speeds. However, one must perform the proper due diligence by ensuring the hardware has been certified by an independent testing laboratory and, if needed, using additional random number generators. These measures alone cannot guarantee absolute security, but they can make security breaches far less likely to occur. They also demonstrate the due diligence and high levels of assurance needed for high end security applications.


Paul Raines is the Chief Information Security Officer for the United Nations Development Programme. In that capacity he is responsible for the information security and disaster recovery planning for the Organisation’s 177 locations around the world. Previously, he worked for the Organisation for the Prohibition of Chemical Weapons (OPCW) and, like all current and former members of the organization, shared in the 2013 Nobel Peace Prize. Prior to working for the United Nations he was the Chief Information Security Officer for Bloomberg LP and the Federal Reserve Bank of New York. He is a graduate of the United States Air Force Academy and Harvard’s Kennedy School of Government. For relaxation he enjoys opera, Shakespeare, French wine and sometimes just sitting in a cafe with an espresso and croissant reading a good book on Roman history.

The opinions expressed in this blog are those of Paul Raines and do not necessarily represent those of IDG Communications, Inc., its parent, subsidiary or affiliated companies.

More from this author