Review of Hardware Encryption vulnerability of Kingston and SanDisk USB flash drives
The Kingston Technology company, a leader in the production of safe USB drives, and one of the first ones that started producing USB flash drive with hardware encryption (Kingston DataTraveler Secure) announced that some of its models of USB flash drives with hardware protection feature are vulnerable. The announcement was posted on the company’s web site saying that with the help of some tools you can access this USB drive (i.e. hack it without a password). News regarding some models of Kingston being prone to cracking is very surprising because these flash drives have been certified in compliance with FIPS 140-2.
Everything started with the fact that the German company SySS published a document entitled “Companies SySS hacked USB flash drive with hardware encryption Kingston certified FIPS 104-2”. In this document they describe in details the authentication protocol between the drive and the program (the user), which they found on the basis of intercepted USB traffic + vulnerability that was discovered. And also some screenshots of the utility, which is embedded in the process of authentication program for USB drives, and as a result – we may enter any password and access will be granted.
Thus data strongly encrypted by the hardware, but there is an external utility, which performs authentication (checking / changing the password and settings) using a certain protocol (API + algorithm utility). This protocol was not protected, and a vulnerability was found.
The same thing was found and described for USB flash drives with hardware encryption (hardware based encryption) by SanDisk.
The most interesting discussion on this topic developed in the blog of Bruce Shneier – famous cryptology and computer security expert.
The most interesting summary of the comments in this blog:
- Standard FIPS 140-2 has nothing to do with it. It just does not cover\ check those places where the vulnerability has been found.
- Vendors use as a cover this standard, FIPS 140-2, to persuade users that the level of data protection is high enough. And thus discredit the standard. Although, it really just checks / tests cryptographic module, but not the whole product as a whole.
- The fact that a similar vulnerability was found in USB drives of various devices tells us that this technology (along with the vulnerability) whether goes from hand-to-hand between the large companies. Or it may be developed by somebody else (outsourcing), and many companies use that person’s services.
- The most correct authentication protocol in this case would be –
- Password must encrypt the key
- The key is to encrypt data on the device.
- It is now clear why Sandisk refused to provide the Linux community with documentation on the USB protocol host-to-drive for its USB device. In the case of the publication it would be obvious that you may have access using a constant command.
Conclusion – any drive that has no documentation (USB protocol) on how to create a Linux-driver is potentially vulnerable. In particular IronKey.
* For reference: this bug would be like selling locks and safes with the same key for all of them.
We’d like to remind you that in the past this authentication scheme was actually used by many biometric USB flash drives, i.e. authentication process takes place at the level of the program, after which a constant signal is transmitted to the hardware to open access to the USB device.
Research workers have found that signal to the USB-device controller and the whole defense was a solid vulnerability.
In our last review of BioSlimDisk, biometric flash drive with hardware encryption, we gave illustrations regarding difference between hardware and software authentication of such devices.
In addition, we want to mention the most important, in our opinion, safety criteria for USB devices:
- Protection of the internal configuration.
Many USB drives, tokens and other authentication devices imply changes to their features, such as – authentication settings, passwords, etc. This configuration should be accordingly protected. - External management utility is potentially vulnerable.
If there are applications that can operate the device from outside, and control access to data on the device, there may be attacks on on their protocols. The same applies to the remote control \ deletion of the devices. These protocols should not be exposed to all sorts of REPLY attacks. - Active devices can be potentially dangerous.
Recently, have appeared tokens that look like USB-keyboard (generating OTP password in plain text). When connecting these tokens there is auto-navigation function – which is capable of opening on the computer a certain web site. And since there are obviously malicious websites, it can infect your PC.
Despite the possibility of the presence of many other vulnerabilities in USB devices, life can not stand still. Therefore, we want to demonstrate you a very interesting principle, which arose in the forums and blogs when discussing the different programs and devices for data protection and authentication. This principle states that “encryption is not enough” (in the original ‘Encryption is not enough’) means –
- In addition to the fact that data is encrypted encoding, or even somehow blocked – there are many places where the same data can be intercepted – unprotected Backups, temporary files, infected PCs with spyware, mean colleagues or family members, etc.
- Protocol of protection and its implementation should be open (open source if possible).
- There is no trust to self-developed encryption algorithms. You can count only on algorithms that are recognized by cryptologists’ community and passed the test of time.
- There should be an open community of this product, so people could find vulnerabilities in new versions of software or protocol implementation timely, and report it all. As progress is not static, as well as people who do it, each new version should be considered in terms of security again.
If a particular product complies with these qualities, it is a sign of confidence in it.