Most companies do not know what level of cryptography is required to properly protect their data lifeblood, nor do they have anyone tasked with assessing the coverage. As a result, most corporations today are not following cryptographic best practices and are potentially exposed.
Most companies do not know what level of cryptography is required to properly protect their data lifeblood, nor do they have anyone tasked with assessing the coverage. As a result, most corporations today are not following cryptographic best practices and are potentially exposed.
The first step in analyzing the required level of cryptography is to assess the value and sensitivity of your data and its associated lifetime. Some data, such as stock trades, may have ephemeral lives and be of little value beyond a few minutes. At the other end of the spectrum are electronic medical records, which may have to last more than 80 years.
Trade-secret data, such as business plans, next-generation pharmaceutical test results, merger and acquisition plans, or advanced CPU designs, will likely be in between these bookends. Some data, such as the remote telemetry commands to program a pacemaker or to open a dam floodgate, may have significant human costs if improperly issued. Data must be protected by cryptography rated for the data's lifetime and sensitivity.
Just as computing capabilities have changed over the years, cryptography also has changed to meet computing developments. For example, in the mid-1980s, Data Encryption Standard (DES) was widely used to protect corporate and financial information. DES is an example of a symmetric cipher in which the same key is used to lock and unlock (encrypt/decrypt) the information, and it used a 56-bit key.
Public key (or asymmetric) algorithms such as RSA and Elliptic Curve Cryptography (ECC) use two keys -- one to encrypt and one to decrypt -- and were used to securely distribute DES keys to communicating parties. In the mid-1980s, RSA key sizes of only 384 bits were considered sufficient for most commercial traffic, with 512 bits reserved for very sensitive data.
Moore's law and crypt-analytic improvements made short work of 56-bit DES and 512-bit RSA keys. By the mid-1990s, we had triple DES (effective key size of 112 bits) and RSA at 1,024 bits, plus RSA at 2,048 bits was also used. In the early 2000s, the National Institute of Standards and Technology (NIST) had formally adopted the Advanced Encryption Standard (AES), with key sizes of 128-, 192- and 256-bits to replace DES.
At the same time on the public-key front, NIST and the American National Standards Institute published guidance that stated: RSA 1,024 should no longer be used to protect sensitive data by 2010; and for AES-128, RSA with a key size of 3,072 bits or ECC with 256 bits should be used.
But users and vendors have largely remained ignorant of these critical guidelines. If you ask how many conference room attendees use VPNs, all hands will be raised. If you ask how many are using AES, most hands will stay raised -- and the same with RSA-1024. If you ask about RSA-3,072, all the hands will drop, despite NIST guidelines and regulatory pressure to ensure appropriate data protection.
With its public announcement in 2005 of the Suite B set of cryptographic algorithms, the U.S. government has raised more awareness around the need for stronger cryptography. Specifically, the National Security Agency defined the algorithms and strengths needed to protect both Sensitive But Unclassified (SBU) and classified information for use in its Cryptographic Modernization program.
It is significant to note that these key lengths are equivalent in strength to RSA key sizes of 3,072 or 7,068 bits, respectively (see NIST SP 800-57). SBU is the lowest classification level for information requiring cryptographic protection. These algorithms are expected to have a usable lifetime well beyond 2031.
NSA's Suite B announcement did ignite interest among certain vendors. Operating system companies such as Microsoft, Red Hat and Sun Microsystems found that ECC offers significant performance improvements over RSA at the Suite B key sizes. At the 2007 RSA Conference, these companies presented benchmark data showing that OpenSSL can run as much as 11 times faster and that Apache HTTPS can deliver up to 3.8 times higher throughput with ECC at Suite B strengths.
In addition, these performance benefits extended to 64-bit architectures. The positive IT impact to business by using ECC in secure protocols is significantly improved server performance. For organizations that outsource IT infrastructure, ECC can mean lower MIPS requirements and thus improved lease costs. ECC solutions at Suite B strengths are available from a variety of companies such as Certicom, Microsoft, Sun, Intel, Freescale, Cavium, Red Hat, Spyrus, Itron and Research in Motion.
As the benchmarks demonstrate, very strong cryptographic security does not need to come at the price of performance. At a minimum, you should select the level of cryptography that matches your information lifetime and sensitivity needs.
Also keep in mind that your cryptographic solution may be deployed for years so the algorithms must match accordingly. A good example is in smart grid applications in which the electricity meter may be deployed for 20 years or more -- the cryptography must still be functional in the outer years. Anyone building smart grid applications should be using Suite B level of cryptography at a minimum. As proof that superior cryptography is commercially practical, the BlackBerry uses AES-256 and ECC-521, which is comparable to RSA-15,360, exceeding Suite B requirements.
As we look to the future, it is important to assess the cryptography used in all your secure protocols, from SSL to IPSec/IKE to SSH. Corporate auditors will begin to look at the cryptographic algorithms employed in your company.
In its IT examination handbook, the Federal Financial Institutions Examination Council has established guidance that encryption implementations should include "encryption strength sufficient to protect the information from disclosure until such time as disclosure poses no material risk."
The NSA's Suite B announcement has redefined what constitutes industry best practices. Companies with significant sensitive proprietary information, such as financial institutions, semiconductor manufacturers, pharmaceutical companies and high-tech product manufacturers, must require their network security solutions implement at minimum Suite B strength algorithms.
Lattin is CTO of Certicom, a Research in Motion company.