Cryptographic Key Reuse Exposed, Leaving Users at Risk

By Sean Michael Kerner  |  Posted 2015-11-30 Print this article Print
security worries

A lack of unique keys in embedded devices is revealed, leaving such devices subject to impersonation, man-in-the-middle or passive decryption attacks.

The promise of encryption is that it keeps information hidden from public view. But what happens when multiple devices share the same encryption key? According to a report from security firm SEC Consult, millions of devices are at risk because vendors have been reusing HTTPS and Secure Shell (SSH) encryption keys.

"Research by Stefan Viehböck of SEC Consult has found that numerous embedded devices accessible on the public Internet use non-unique X.509 certificates and SSH host keys," CERT warns in vulnerability note #566724. "Vulnerable devices may be subject to impersonation, man-in-the-middle, or passive decryption attacks."

Viehböck looked at more than 4,000 devices from 70 vendors and found only 580 unique private keys were in use. There is a significant amount of reuse across keys that SEC Consult has estimated to impact approximately 50 vendors and 900 products. CERT's vulnerability note explains that for the majority of vulnerable devices, vendors reused certificates and keys across their own product lines.

"There are some instances where identical certificates and keys are used by multiple vendors," CERT's vulnerability note states. "In these cases, the root cause may be due to firmware that is developed from common SDKs (Software Development Kits), or OEM (Original Equipment Manufacturer) devices using ISP-provided firmware."

Tod Beardsley, research manager at Rapid7, is not surprised at the SEC Consult findings. When auditing inexpensive embedded devices, his No. 1 complaint is when the administrative interface isn't encrypted at all, he said.

"However, even when I do see that there is an encrypted interface, they're often vulnerable to the shared key problem detailed by VU#566724," Beardsley told eWEEK. "The problem here is that it's difficult for low-end, low-margin device managers to implement unique key generation on individual devices."

Plus, generating unique keys as part of the manufacturing process cuts into a vendor's already thin margins, and designing something that generates a key on first use is going to require some development and quality assurance effort, Beardsley said.

"The problem is that software developers and security architects haven't yet come together to design an easy-to-use, push button library that embedded devices leverage routinely," he said. "As technologists, we need to get ahead of this problem and design encryption solutions that are not only secure, but easy to implement."

Using hardcoded private keys is a security disaster, according to Dr. Yehuda Lindell, co-founder and chief scientist at Dyadic. Lindell sees a number of reasons why the private keys may have been left exposed and reused by multiple vendors.

"Sometimes, keys are hardwired for the purpose of development and testing, and are just forgotten when moving the software into production," Lindell told eWEEK. "Other times, developers don't know where to put the keys and mistakenly think that hardwiring them is a good idea."


Submit a Comment

Loading Comments...
Manage your Newsletters: Login   Register My Newsletters

Rocket Fuel