eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
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.”
Cryptographic Key Reuse Exposed, Leaving Users at Risk
Angel Grant, senior manager at RSA, the security division of EMC, noted that security key management has always been a challenge and will continue to propagate as the Internet of things (IoT) expands.
“There currently is no model of trust between machines, so organizations need to pause and think about the potential attack vectors that will leverage the potential computing power of IOT to create things like a Botnet of Things (BOTOT) or Thing in the Middle (TITM),” Grant told eWEEK.
Best Practices
There are a number of things that vendors can and should do to limit the risk of cryptographic key reuse. In many cases, however, the challenge lies with the actual end users of devices.
“The problem with this sort of vulnerability is that the device owner [user] actually can’t do anything other than replace the device,” Lindell said. “It’s also not necessarily the case that a vendor can issue a simple firmware update. This is because not all of these devices may support such a remote update securely.”
Grant suggests that if an organization is using one of the impacted devices internally, it should closely monitor its traffic as an attacker can manipulate this vulnerability when located within the same network segment.
“Moving forward, it will become more critical that organizations use the best practice of ensuring each device uses unique cryptographic keys,” Grant said.
Kevin Bocek, vice president of security strategy and Threat intelligence at Venafi, said his company along with the National Institute of Standards and Technology (NIST) recently issued a new publication titled Security of Interactive and Automated Access Management using Secure Shell (SSH). The NIST document provides guidance on several critical aspects of SSH, including its underlying technologies, inherent vulnerabilities and best practices for managing SSH keys throughout their life cycle.
“All SSH access depends on the proper management and security of SSH keys,” Bocek said. “If your organization does not have an active SSH key management and security project, it is at risk.”
There is also a short-term fix that can help to limit the risk of being exposed to reused cryptographic keys.
“As far as protecting today’s vulnerable devices, moving them off the general Internet and into a VPN controlled network is probably the best short-term solution,” Beardsley suggested. “VPNs are an increasingly important component of modern enterprise networks. There are pretty easy-to-use interfaces on laptops, tablets and phones today, and their use is getting more normalized on otherwise public networks.”
Sean Michael Kerner is a senior editor at eWEEK and InternetNews.com. Follow him on Twitter @TechJournalist.