blcokchain contributor

Cryptographic Key Generation – It’s Time To Pay Attention

Cryptographic Key Generation

When we think about cryptographic keys, we tend to think about closely guarded secrets. Keys are the only thing that keeps the attacker away from your encrypted data. Some keys are usually treated with the appropriate level of respect. Security professionals in the payments industry, or those that have deployed a PKI, know all too well about the importance of defining and auditing certain key management processes.

But in this article I’m focused on all of the other keys: the billions of keys that are created on the fly, automatically, every second. The ones used in SSL, SSH, file and disk encryption and a thousand other applications. How are those keys generated? Who’s responsible for making sure that they’re good enough to do their job? How do we make sure that nothing’s taken for granted?

When I talk about keys being ‘good enough’, what I mean is, are they truly random? When keys are less than perfectly random they start to become predictable, and predictability is the enemy of all cryptography – it makes the attacker’s job a lot easier.

Where Do The Numbers Come From?

Cryptographic Generation

So, where do the random numbers that are used to generate keys come from? In almost all cases they’re generated by the operating system. The trouble is that software only does what it’s programmed to do; it doesn’t do random things.

To help randomize random number generation algorithms, the operating system scavenges randomness (more properly called entropy) from wherever it can, ideally by sampling some aspect of its physical environment; the real world. Entropy can come from many sources, some better (more random) than others. Everything from mouse clicks by the user, to keyboard clicks and timing jitter in the computer hardware can all yield entropy.

The trouble is that capturing entropy and converting it into statistically random numbers (equal proportions of independent ones and zeros) is not easy and it’s getting harder. Random number generation spans the entire stack from the hardware to the OS to the application. It’s a complex picture that is made even harder by virtualization and containerization layers that are specifically designed to abstract the things that need randomness (the applications) for the places where randomness actually exists (the hardware and the local environment).

Unfortunately these various layers are often ‘owned’ by different people or teams. In cloud environments the hardware layer might be completely opaque, owned and operated by a service provider. The trend is strongly oriented towards these highly abstracted deployment models, which raises the question, “Who owns the job of making sure that random number generation is done right?

Looking at the Hardware

The hardware guys have no idea what applications will run on any given box or how much entropy each will require. The OS has no idea how many random numbers will be required or how to prioritize the needs of individual applications (you’d like to believe the crypto apps get the best random numbers). And the applications have no idea if they are getting the quality of random numbers that they asked for, and almost never have the ability to raise alarms if they don’t.

The reality is that each successive layer in the stack makes the assumption that everything below (the hardware, the OS etc.) is doing its job in creating, capturing and processing entropy. Worse still, the existing tools for assessing the quality of entropy and the randomness of random numbers are notoriously unreliable and hard to use. In practice there’s no easy way to find out if the various layers are doing their job. The end result is that applications that use random numbers to generate keys have no ability to attest to their quality – either in real-time or retrospectively.

It would be nice to think that the security team will save the day. After all, it is their job to take a holistic view. But is that realistic? How many security teams know the specifics of how individual applications access and use random numbers to generate keys? How can they possibly know how commercial software or security appliances work at that level of detail? Could a CISO ever answer the question of how many VMs or containers are running at any point in time, never mind what proportion of them are satisfying the entropy demands of their crypto apps? How many organizations have a policy about such apparently mundane tasks as generating random numbers?

Actually, some really do. Some require product security certifications such as FIPS 140, which includes provisions for random number generation, and a subset of these organizations invest in dedicated devices such as hardware security modules (HSMs). But now we are in the territory of those special, regulated applications I mentioned at the beginning.

If we return to the mainstream – the millions of SSL stacks whirring away across the datacenter, the SSH keys generated on almost every system, the corporate web of VPNs – we need a generic solution, a solution that deals with random number generation and entropy on a grand scale. It will soon be hard to find an application that doesn’t need random numbers, and most will need crypto-strength randomness. Entropy sourcing and random number generation shouldn’t be left to chance; a best effort activity.

Entropy starvation and poor random number generation is a basic security hygiene issue and taking proactive steps to ensure that keys are truly random is a standard of due care.

By Richard Moulds

Richard Moulds

Richard Moulds, General Manager of Whitewood Security.

Richard has more than 16 years in-depth experience in the areas of cryptography, encryption, PKI, key management and all forms of data protection, payment processing and identity management. Richard is a frequent public speaker and authored “Dummies” guides on key management and PCI DSS data protection.

View Website

Security Audits, Cyberattacks and other Potential Front Line Issues

Security Audits, Cyberattacks and other Potential Front Line Issues

Defending the Organization When people talk about security audits in an organization, thoughts immediately go to malware, cyberattacks and other front line issues. These appear as the most obvious types of threats and are consequently given the greatest attention. As ...

SPONSORS

HPE

IoT: Connected Manufacturing Leads To Service as a Product

Connected Manufacturing A car is driven back to its home garage for the night, and its data port is plugged ...
Scale your Windows Azure application

Understanding The Importance Of A Flexible Hybrid Cloud Solution

Flexible Hybrid Cloud Solution The cloud computing revolution continues to gather pace, and more and more businesses are coming on-board ...

Cloud Community Supporters

(ISC)²
AWS
HPE
CA Technologies
Cisco

Cloud community support comes from sponsorship, service opportunities and collaborative network partnership initiatives.

Cloud Developers are Using the Programmable Infrastructure

Cloud Developers are Using the Programmable Infrastructure

In the past few years, we have seen a surge of advancement in cloud development. New platforms, developer tools, and cloud services have become available, and developers have responded by building innovative cloud-based applications, services, and businesses. In my opinion, we’ve only unleashed the beginning
Great Data Scientists Don’t Just Think Outside the Box, They Redefine the Box

Great Data Scientists Don’t Just Think Outside the Box, They Redefine the Box

Redefine the Box Special thanks to Michael Shepherd, AI Research Strategist, Dell EMC Services, for his co-authorship. Learn more about Michael at the bottom of this post. Imagine you wanted to determine how much solar energy could be generated from adding solar cells to a

"Top 100 Brand Influencer, Cloud”
-ONALYTICA

"Best Cloud Computing Blog"
-SYSADMIN MAGAZINE

"Top 10 Sites For Cloud Computing"
-DIGITALISTMAG SAP

"Top 10 Cloud Computing Blogs”
-MARKETING ENVY

"Top 25 Must Read Cloud Blogs"
-CLOUDENDURE