• United States




How to improve your crypto-agility

Aug 02, 20187 mins
CybercrimeData and Information SecurityEncryption

As the sheer number of connected devices continues to rise, securing these devices, and becoming “crypto agile” is a key component of an organization’s effort to become more agile. Read on to discover how to improve your organization’s cyrpto-agility.

A common enterprise goal is to improve business agility. Becoming better at adapting quickly to market changes gives an organization a competitive advantage. Information is an organization’s lifeblood, and the information security department is responsible for establishing and maintaining secure connections between IT systems and all external devices. Crypto technology is often used between diverse systems that have to interoperate and require encrypted links to protect the information they’re trading. As the sheer number of connected devices continues to rise, becoming “crypto agile” is a key component of an organization’s effort to become more agile.

Unfortunately, becoming crypto agile is more complicated than it might seem. Too often the approach is similar to changing the tires on your car: “I have crypto algorithms I use today, and I can simply swap out old ones for new ones when I have to.” The trouble is, a crypto algorithm rarely works one day and then suddenly needs replacing the next day.

Consider the SHA-1 (Secure Hash Algorithm 1). Last year, researchers were able to achieve the first real-world collision attack against the SHA-1 hash function, producing two different PDF files with the same SHA-1 signature. The weakness they discovered enables an attacker to forge digital fingerprints and use them to create a rogue software update that would be accepted and executed by an update mechanism that validates updates by checking digital signatures.

That sent up a red flag that organizations should discontinue using the algorithm for security-sensitive functions. When Google launched Chrome version 56 last year, it marked all SHA-1-signed HTTPS certificates as unsafe. The U.S. National Institute of Standards and Technology in 2010 banned all U.S. federal agencies from using of SHA-1, and digital certificate authorities have not been allowed to issue SHA-1-signed certificates since Jan. 1, 2016, with some exceptions. Yet, organizations still rely on the SHA-1 algorithm to validate credit card transactions, electronic documents, email PGP/GPG signatures, open-source software repositories, backups and software updates.

Algorithm security is not a black and white issue. It used to be algorithms would transition quickly from useful to not, but now they are dying slow deaths. Yes, SHA-1 can be broken, but it remains extremely difficult to break. The analogy of changing vehicle tires is not too far off. Research shows many people keep driving on their aging tires because they cannot determine when they’re going bald and wait to install new ones until one goes flat or their mechanics sound a warning. Achieving crypto-agility involves planning and being able to transition to stronger algorithms before a major security event requires it—when it may be too late.  

Poor visibility limits agility

A common issue CSOs wrestle with is not having a full understanding of where crypto is being used throughout the IT infrastructure. Maintaining a software inventory is something CSOs are familiar with, and they need to develop the same insight into all the devices, including the ever-growing number of connected devices.

How security conscious a hardware vendor is can play a role in helping organizations retain crypto-agility. If you have a vendor with a history being slow to roll out security updates, that creates a risk. If you work with vendors that provide regular updates, disclose what crypto they’re using and support the latest algorithms, you minimize risk and improve your crypto-agility level. That will enable your organization to more quickly respond to a large crypto threat and mitigate any potential damage.

Achieving crypto-agility requires all of your hardware vendors to incorporate crypto technologies into the devices that you rely on for mission-critical communications and data sharing. Among the most common is TLS (Transport Layer Security), often referred to as SSL (Secure Sockets Layer), a standard security technology for establishing an encrypted link between a server and a client. To establish this secure connection, the browser and the server need a TLS/SSL Certificate. The necessary components are asymmetric and symmetric keys, which work together to create a TLS-encrypted connection.

Asymmetric encryption (or public-key cryptography) uses a separate key for encryption and decryption. Anyone can use the encryption key (public key) to encrypt a message. However, decryption keys (private keys) are secret. This way only the intended receiver can decrypt the message. The most common asymmetric encryption algorithm is RSA.

Symmetric encryption (or pre-shared key encryption) uses a single key to both encrypt and decrypt data. Both the sender and the receiver need the same key to communicate. Symmetric key sizes are typically 128 or 256 bits—the larger the key size, the harder the key is to crack. A ‘brute force’ attack, in which an attacker tries every possible key until they find the right one, would require quite a bit of time to break a 128-bit key. Whether a 128-bit or 256-bit key is used depends on the encryption capabilities of both the server and the client software. TLS Certificates do not dictate what key size is used.

TLS uses both asymmetric and symmetric encryption via Public Key Infrastructure (PKI), which is the set of hardware, software, people, policies, and procedures that are needed to create, manage, distribute, use, store, and revoke digital certificates. PKI is also what binds keys with user identities by means of a Certificate Authority (CA). PKI uses a hybrid cryptosystem and benefits from using both types of encryption. For example, in TLS communications, the server’s TLS Certificate contains an asymmetric public and private key pair. The session key that the server and the browser create during the TLS Handshake is symmetric.

What crypto-agility is not

Crypto-agility is not just the ability to use different algorithms for critical functions (e.g., hashing, signing, encrypting, etc.). If it were, achieving crypto-agility would be relatively easy and not worth discussing beyond simply asking “does your software support LatestGreatest-16384?”

SHA-2, the successor to SHA-1, contains the same cryptographic weakness (although its increased length offers better protection against breaking). Still, SHA-3 is the recommended replacement for SHA-1 and SHA-2, but the problem is that almost no hardware or software products support it yet. 

Simply trying to get the supported algorithms into place everywhere they need to be can be a tall order, and that makes striving to achieve crypto-agility more difficult. Most crypto transitions happen at Internet scale and transitioning off of one crypto algorithm to a new one requires working with all of your vendors.

Crypto-agility best practices

The first step is to create a plan how your organization will migrate to new algorithms as they become available. Your vendors need to be able to provide you with information how they will support your plan. Make it your policy to work with vendors which use the best current cryptography and add support for modern standards and improved algorithms within a reasonable timeframe. Software and firmware need to be upgradable in a reasonable timeframe, and with a reasonable amount of effort. This will enable you to quickly replace anything from previous crypto eras that leave your organization open to security vulnerabilities.

Finally, you need to start at least thinking about the transformation of your IT infrastructure that quantum computing will drive in the not-too-distant future. Quantum computing will enable computers and IoT devices to run calculations much faster than what is possible today. It promises to fundamentally change the way we approach everything from researching cures for cancer to alleviating traffic in urban centers. But realizing those visions requires overcoming the new IoT security challenges quantum computing will create.

Today, connected devices rely on RSA or ECC cryptography to protect the confidentiality, integrity and authenticity of electronic communications. Web browsers also use RSA and ECC signature verification to establish a secure connection over the Internet or validate digital signatures. However, NIST and other security industry watchdogs predict that within a decade, large-scale quantum computing will break RSA public-key cryptography.

The benefits and risks quantum computing presents will affect virtually every industry, including financial services, healthcare, energy and manufacturing. The realization of quantum computing-driven IT systems may still be at least 5-10 years down the road, but it’s something to consider now as you work to improve your crypto-agility levels today and tomorrow.


Dan Timpson was promoted to Chief Technology Officer in January 2015 after serving as DigiCert’s VP of Technology for two years. As CTO, Timpson is responsible for DigiCert’s technology strategy and plays a key role in leading the security industry by driving new initiatives. At DigiCert, Timpson’s team is constantly working to simplify certificate management for DigiCert customers and strengthen the security of DigiCert’s products against evolving threats. Additionally, Timpson contributes strategic oversight and program management to DigiCert’s products and features.

Prior to joining DigiCert, Timpson worked for Microsoft Corporation, where he managed a Security Development Lifecycle (SDL) team to evaluate the security of Microsoft software. Before that, Timpson managed a team at Novell that tested identity and access management systems and their underlying PKI framework. Timpson has a BS in Computer Science & Information Technology and an MBA from Westminster College.

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