How To Password Protect Your Pen Drive

A nice how-to article on protecting USB drives with a password and encryption using Windows Vista or 7 and Bitlocker.

Do you carry sensitive data in your pen drive? Then you should carefully keep your pen drive. Oh! You mean you are not that careful too. Then I would suggest that you should password protect your pen drive. Yes folks, you can do this by a simple method. This is an added advantage to Windows Vista and Windows 7 users that they can easily password protect their pen drives with the help of BitLocker Drive Encryption. Its an inbuilt feature of both of these operating systems.

 

Related articles by Zemanta

• ZoneAlarm's DataLock: BitLocker for the Rest of Us (technologizer.com)
• BitLocker, USB drives not at fault - it's BIOS (seattletimes.nwsource.com)

Conficker and your health

A USB stick inserted into a terminal in one of its car parks is being blamed for a massive Conficker infection of Waikato hospital in New Zealand that broke out last December. Over a 3 day period this incident infected 3,000 computer on the hospital network, impacting around 5,000 hospital staff. A full report on the incident is still forthcoming, but a USB-borne strain of Conficker is expected to be named as the culprit. A similar incident occurred in the server of the NHS in Leeds earlier in the year.

Passwords for USB Keypads

Bruce Schneier recently posted about a new USB stick that comes with its own on-board numeric keypad, permitting a password consisting of digits to be entered directly into the USB device to authorize unlocking. Such a stick and keypad would circumvent the recent USB password vulnerability that was derived from a poor implementation of password verification on the desktop.

The stick in question from Corsair (shown above) also uses AES-256 encryption to protect the data on the stick. The AES-256 key for the stick is then likely to be derived from the user-supplied password (say using PKCS #5 or RFC 2898), or used to protect a file which contains a full-length 256-bit key. In either case the 256-bit key will be derived from, or protected by, a password which has a much lower entropy.

Bruce points out that a 77-digit password would be needed to produce the same entropy as a 256-bit key (since the logarithm to the base 10 of 2^{256} is about 77 ). I made the same point in Are AES 256-bit keys too large? where I calculated that a password based on the 94 printable ASCII characters would need to be 40 characters in length to achieve the same entropy of a 256-bit key (since the logarithm to the base 94 of 2^{256} is about 40). Deriving or bootstrapping AES keys from passwords is really an exercise in self-deception, especially when considering 256-bit keys. The discrepancy between the low entropy of passwords and the astronomical keyspace of AES-256 simply cannot be reconciled.

Perhaps the situation would improve if a biometric such as a fingerprint was used to bootstrap a 256-bit key. I did some research about a year ago and posted what I found in On the Entropy of Fingerprints. Some work has been done by IBM researchers who estimate the entropy of fingerprints to be at most 85 bits, or approximately the same as a length 13 password based on the 94 printable ASCII characters. An improvement, but still a long way from 256 bits of entropy.

USB devices back on duty for the DoD

The US DoD has tentatively rescinded its universal ban on USB devices issued over a year ago, reintroducing them under controlled conditions and for limited use, as reported by Stars and Stripes. The DoD introduced the draconian ban to prevent malicious software from infecting defence networks. However it seems that the combat need to transfer data quickly and conveniently has trumped any blanket security veto. The new devices can only be connected to military networks, and used for data transfer when network resources are unavailable or overloaded. In short, as a method of last resort.

According to Defence News, the drives are designed so that they can be tracked by system administrators, are password-protected, and store information in encrypted form. Additional features include on-board anti-virus software and security rules that prevent copying or forwarding of certain information from the drive or saving unapproved information on the drive.

The move may seem somewhat untimely since suppliers of secure USB sticks are still reeling from a vulnerability that permits password-protection to be bypassed. Wired reported on the announcement as saying that both hackers and troops will be rejoicing.

Another source of USB Randomness

Back in December I posted about a new USB device with dedicated hardware for producing a continuous stream of high entropy bits based on sampling P-N junctions. Another lower tech randomness source with a USB interface is described at this site, and is shown below

The device has a small hourglass, and as the sand falls from the upper to the lower chamber, the pattern of grains is sampled against a light-sensitive detector at a rate of 100 times per second. The site claims that each sample yields about 9 bits of entropy based on statistical tests. The device detects when all the sand has passed to the lower chamber and then rotates the hourglass 180 degrees, so the sampling process can continue. The samples can be accessed through a USB interface.

The device is a prototype, and as yet not for sale, but costs about $100 to produce. The advantage of the hourglass method over other more sophisticated and higher yielding devices is simplicity and transparency. Perhaps so, and you can read more about the design here, and the entropy of the output here. Finally

While the hourglass is not precise, accurate, or repeatable as a timekeeper, and has been almost completely supplanted by better devices, it is a good source of random entropy. It is still manufactured in quantity at low cost, and it is clean, compact, durable, and uses little energy. The source of the random entropy can be easily understood, and observed to be functioning correctly without instruments. An off-the-shelf photointerrupter can be employed to electronically observe the random entropy, and an open-source, standardized microcontroller can be used to control the process and interface it with a host computer.

Related articles by Zemanta

• USB Hourglass random number generator (makezine.com)
• Arduino-controlled hourglass (makezine.com)
• USB Hourglass random number generator (electronics-lab.com)

The USB Password Vulnerability

In early January Heise Security reported that a German security firm had discovered a vulnerability in the password authentication process of several USB sticks that are rated as being highly secure. The discovery has been widely reported, and led to various responses from USB vendors Sandisk, Verbatim and Kingston, including patching and recalling their devices from the field. The full list of effected sticks has been reported by Simon Hunt for example. Steve Ragan of the TechHerald has commented that the whole incident is “"quickly becoming the first FUD-based news cycle for 2010”.

What was the vulnerability?

Well when a user plugs in a password-protected USB stick their desktop starts the stick by launching a popup application prompting the user for their password. You would expect that the user supplied password is then transferred to the stick for verification, and the stick grants access if the password is correct.

What German security company SySS, discovered is that the password verification is actually performed in the popup application itself , and an acknowledgment code is sent back to the stick indicating if the candidate password is correct or not. By sniffing this traffic SySS determined that the acknowledgment code granting access is static, and in particular does not depend on the password entered by the user. Essentially the desktop popup verifies the user supplies password and then returns "yes" or "no" to the stick.

SySS captured the acknowledgment code, and then wrote  proof-of-concept exploit which injects the acknowledgement code into the memory space of the desktop popup so that the value returned to the stick is always the positive acknowledgement code. Thus regardless of what password the user enters the hack ensures that the stick will always grant access.

What was the impact?

Given the injection code, the password-protection can be defeated on sticks susceptible to the attack, which turns out to be a reasonably large class of commercial sticks that are marketed as being highly secure. All things being equal, the risk of a data breach from lost sticks is therefore increased, since the password-protection of the sticks can be bypassed with the right software. And losing sticks is increasing. CSO Online recently reported on a UK survey conducted by Credant which revealed that 4,500 memory sticks have been forgotten in people's pockets as they take their clothes to be washed at the local dry cleaners.

The impact is not limited to a single vendor product. The vulnerability exists in several families of secure USB devices across the major USB vendors because they all rely on a common USB chipset whose security properties have not been properly vetted.

FIPS Certification

The incident is all the more telling in that the vulnerability impacts devices that use AES 256-bit encryption and are rated as secure by the FIPS 140-2 certification process. Users are paying quite a premium over vanilla sticks for the advertised additional assurance that their data are protected by a certified device using strong cryptography, and for some US government agencies such purchases are mandatory. The relative ease with which the password protection was bypassed calls into question the value of the FIPS 140-2 process.

In Computerworld NIST is quoted as saying "From our initial analysis, it appears that the software authorizing decryption, rather than the cryptographic module certified by NIST, is the source of this vulnerability", and then also "Nevertheless, we are actively investigating whether any changes in the NIST certification process should be made in light of this issue”.

To be fair, the FIPS 140-2 focuses on verification of cryptographic modules and not the supporting software, however the incident highlights the narrowness of the approach and the expectation that certification is more than secure cryptography. Chris Merrit at Lumension has a good post on the fine print of the certification FIPS 140-2 process, and he concludes

So, bottom line: while this discovery seems to suggest an area to which NIST might want to bring some clarity and rigor, it does not mean that FIPS 140-2 is fatally flawed. It’s up to you, as the buyer, to understand what (potentially critical) functions occur inside & outside the cryptographic boundary, and how that might impact the security of the device in your case. And since what you’re looking for is what’s not certified, it might be useful to have an expert review the vendor security policy (posted with the certification on the NIST website) to help you understand the nuances.

AES-256 and Passwords

As I explained in Are AES 256-bit keys too Large? it is very unrealistic to equate password security with the security of AES-256. To achieve the equivalent of 256-bit security users would need to select 40 character passwords at random, and we are a long way from that. In fact so far away that we will never get there. So USB devices that protect their data using AES-256 encryption sound impressive, but when access control to those devices and the underlying keys is controlled by a password, then this setup sounds a lot less secure. The SySS vulnerability now shows that the whole AES-256 encryption process can be bypassed in the presence of weak password handling.

Conclusion?

Is there a useful conclusion from this incident? There is a lot of embarrassment all round and we have little confidence that a similar issue will not arise in the future. Security is just done poorly in general, and blatant examples are uncovered whenever someone takes the time to look under the hood. Some  articles and posts have focussed on verifying passwords in software as the culprit, which is partly true, but the real issue is not software but insecure programming of software - the password verification should never have been done on the desktop, and a static acknowledgement code should never have been used to unlock the USB device.

A trusted path should be established between the desktop keyboard and the USB device, and for smart cards this needs to be done with a secure reader. But this is at odds with the plug-and-play semantics of USB sticks where the portability of the ubiquitous USB connector is the selling point.

A USB Entropy Drive

A UK company called Simtec Electronics has created a USB thumb drive device with dedicated hardware for producing a continuous stream of high entropy bits, suitable for mixing into an existing entropy pool on your device or feeding directly into applications and protocols that require sources of randomness. The product is called Entropy Key and and can be ordered from the website for £36.00, with further discounts for bulk orders

An overview of the process for producing the entropy is given in the diagram below. There are two independent noise generators based on P-N junctions that are sampled at a high rate to produce a stream of bytes. The output of each generator and their XOR are subjected to the universal statistical bit test devised by Ueli Maurer. If the sequences pass this test then von Neumann’s debias trick is applied, and then another round of universal testing, followed by hashing with Skein. This process blocks at any stage if the computed statistics fall outside conservative estimates of the properties of random generators.

These steps are repeated until 20,000 bit have been collected, upon which the statistical tests recommended by FIPS 140-2 are applied. The 20,000 bit pool is then parcelled into blocks of 256 bits, and Simtec estimates that each such bock has been generated from about 5,000 bits of noisy hardware samples.

There is quite a reliance on Maurer’s universal statistical bit test, and perhaps justifiably so since this test is specifically designed to detect deviations from expected statistical properties in a bit generator by computing an estimate of the generator’s entropy using ideas from universal data compression algorithms. The test is quite simple, and there is a reasonable description and parameterization given in NIST SP-800 22, which also contains a description of a large number of other statistical tests. A research paper on a finer analysis of Maurer’s test can be found here.

The output rate is, by its nature, variable but an average rate of more than 30 kilobits per second is expected. The complete client daemon source is provided under an MIT license which means everyone is free to examine the code for themselves. SimTec also notes that the Entropy Key can automatically detect various different physical attacks, such as temperature changes (by using a built-in temperature sensor), and opening of the case. The device is currently undergoing testing with "select customers” but is available for general ordering. There is an IRC channel #ekey on the oftc network if you want to discuss any of this further.

(Thanks to Vincent Sanders for providing some more technical details)