It’s smart to encrypt USB memory devices, but it’s stupid to attach the encryption key to the device.
Health bosses today admitted the memory stick was encrypted, but the password had been attached to the device when it went missing.
I’m sure they were so proud that they chose a secure encryption algorithm.
sbr • January 14, 2009 6:38 AM
Regarding duress codes: RSA’s SecurID has such an option. IIRC, if you 9 to the first digit, you gain entry AND an administrator is alarmed, so action can be taken. So duress codes are nothing new.
BTW. the article shows that key management is a real and difficult to solve problem AND security depends crucially on sound key management.
Daniel • January 14, 2009 6:41 AM
This reminds me of a conversation I had with a vendor a couple of years ago.
They were trying to sell handheld POS devices for use on board aircraft, since it’s not feasible to do online authorisation of a card several thousand feet in the air, the device stored credit card details on a removable card for transmission when the device was docked.
The creditcard were encrypted with unique keys, however the keys were added to file. For some reason the vendor couldn’t see a problem with this.
Clive Robinson • January 14, 2009 8:03 AM
@ Glenn,
“a ‘duress code’ option that wipes the data instead of decrypting it.”
As it is very dificult to reliably wipe data quickly, you would possibly be better encrypting the data a second time with a device specific admin key, that you then securly delete.
As the ordinary user should be unaware of the admin key then effectivly you are at the point of having the data doubly locked from an attacker but still recoverable by two employes co-operating under specific procedures.
Addmitdly this does alow for law enforcment to get a warrant but there are ways around this for international organisations (think M of N systems in different juresdictions).
sooth sayer • January 14, 2009 8:33 AM
@Clive
I am not sure it’s hard to delete applies to Flash drives as it did to the magnetic drives.
Residual “charge” is buried in the device and I don’t know if any device manufacturer provides “any” way to access the raw sense data from inside of the device.
Unless you have access to chip level probing . it’s near impossible — and I think average street thief is far from skilfull in this area.
Anonymous • January 14, 2009 8:35 AM
<>
Actually, if you already have the data encrypte, it’s very simple: usually, the “real” encryption key is derived from the access password key plus some random IV data stored on the device. Just overwrite the IV with something else and the data becomes unusable. Better yet: you can have a backup of the IV somewhere safe and, if you ever recover the storage, you can recover the data.
Henning Makholm • January 14, 2009 8:37 AM
And it is particularly difficult to make a “duress code” DO anything on a passive storage device.
kiwano • January 14, 2009 9:44 AM
As far as duress code on filsystems are concerned, my inclination would be more to have various files and directories marked as safe for other people to see, and using the duress code would show only those files. It’s a lot easier to get past whoever’s demanding access to your data if you can plausibly claim to have provided it to them.
Clive Robinson • January 14, 2009 10:34 AM
@ sooth sayer,
“I don’t know if any device manufacturer provides “any” way to access the raw sense data from inside of the device.”
Likewise, but it is possible to remove the chip and scan with a scanning electron microscope or other device to detect any residual charge.
But my reply to Glenn was about putting something in “his software” which I had assumed would end up being used in a more secure device than a USB memory device.
Ordinary external Flash or hard drives cannot be protected for a couple of reasons.
The first as Henning Makholm has pointed out is that duress codes don’t work on passive devices.
Secondly and perhaps more importantly most external memory devices can be bulk copied before the user enters a “key” so the data can be easily restored.
So attempting to use a “duress key” on a passive device would only earn you a little more of the rubber hose etc.
Although for your average user simply using a nonstandard format on a flash or other memory device might prevent them accessing it and in this respect be more effective than encryption (as they might assume the device was damaged/broken).
The only way a duress code is going to be usefull is in a non pasive device which is tamper proof…
giafly • January 14, 2009 10:39 AM
When I write down passwords, I reverse the case, between lower and UPPER. Nobody is likely to guess that.
RTO • January 14, 2009 10:40 AM
@sbr
“IIRC, if you 9 to the first digit…”
The utility of a duress code is diminished if it is widely publicized. (I am making no assertion regarding the correctness of your statement – it might actually be the case that SecurID uses this 9-prefix as a “duress” indicator). However, in order to protect individuals who may be subject to coercion, it should always be the case that the adversary who has coerced you into giving up the code is completely incapable of distinguishing between the real authorization code and the duress code.
christopher • January 14, 2009 10:53 AM
@RTO: correct, so simple transposition of a user PIN should suffice, or PIN reversal, etc, some form of truth twisted, like flying the US flag upside-down
MailDeadDrop • January 14, 2009 11:30 AM
My home alarm system has a duress code. I’ve set it to the house number. Rationale: easy to recall, assume easy to convince real kidnapper that I’m feeble-minded and wanted an easy-to-remember code, and in the “movie-plot scenario” case of a burglar trying “reasonable” possible disarming codes, he’d silently call the police upon himself.
Michael Seese • January 14, 2009 12:19 PM
@ Glenn, and kind of building on MailDeadDrop, just above:
Yeah, but the kind of user who writes down his password would probably forget what the code is, and then eventually say, “What’s this? Oh, it must be the key.”
sbr • January 14, 2009 12:20 PM
@RTO:
It’s not a prefix. You have to add the digit 9 to the first digit. I.e. 1 – 0, 2 – 1. Ok, I am not sure if it was 9 or something else.
sooth sayer • January 14, 2009 12:50 PM
@Clive,
you seem to have a habit of arguing.
Here we are talking about someone loosing a USB drive with password written on it .. and 16 (or a 60) year old hacker is not going to get his electron microscope out to read it after erase..
Joel F • January 14, 2009 1:11 PM
Instead of duress codes, a hidden volume within the normal volume is also an option (such as is available with TrueCrypt). Keep the actual sensitive information in the hidden volume and junk in the normal volume. Under duress you give the password to the normal volume.
JimFive • January 14, 2009 1:43 PM
@sbr
I find it difficult to believe that a duress code attached to the fob read out would work. If I were coercing someone, I would be the one to type in the fob code so there would be no possibility of an incorrect code being entered.
@sooth sayer
JimFive
-ac- • January 14, 2009 2:02 PM
In infinite number of nested hidden volumes isn’t going to do a thing. You would need to simulate activity in the “junk” layer to make it work.
In the light of the article, I have to wonder which way their policy will go next? Less lengthy/”secure” passphrases that are better remembered? Or longer ones that will really annoy the user? Or key files?
I am in favor of a duress key type of thing. A single sign-on with deliberate lockout would be awesome. The current heterogenous user/pass system makes it nigh impossible to protect completely against duress/torture extraction of access codes. The only option that comes to mind is a movie-plot device itself: they unleash a worm/virus on themselves.
JRR • January 14, 2009 2:05 PM
The first thing I’d do when trying to break an encrypted volume that I didn’t know the protection on would be to make a copy, and only work with that, so erase codes wouldn’t be much use.
Prepending a single fixed digit like 9 to the code is silly – anyone familiar with the software would know you were playin’ him and you’d be that much the worse off for it.
Having read all this, if I ever try to open someone else’s encryption, I’ll do it on a virtual machine with no enabled network interface.
JRR • January 14, 2009 2:09 PM
As far as duress codes that erase data, I don’t see how they’re useful. Without them, you give them the wrong key, it doesn’t work, you CLAIM “ha ha, that was a secret code that made the software erase the volume, PWNED!” and they say “we don’t believe you – we’re going to keep beating the snot out of you until you cough up a code that works.”
WITH a duress code that really DOES wipe the data, the scenario is exactly the same except they never stop beating you up because there now isn’t any code that will work.
I wonder if the existance of plausible deniability might have the same effect – if you’re not using it, you give them the only password that exists, they don’t find what they want, do they believe that’s the only password, or do they keep beating the snot out of you trying to get a “hidden volume” password that doesn’t actually exist?
Clive Robinson • January 14, 2009 2:36 PM
@ Sooth sayer,
No not argumentative, I agreed with you that I was not aware of direct sense read out being available as a normal use function.
I was just indicating that direct reading of the residual in the cells can and has been done by a group of researchers who’s equipment budget was quite low.
However for the more technicaly knowledgable there are going to be factory test modes where each individual flash memory block can be tested and it is quite likley that the sense or it’s equivalent will be accessable either on a package pin or unbonded pad on the chip.
Due to the way the EEPROM manufacturing worked in the early days it is quite likley that the test methods will be common to many apparantly different manufactures.
Further it is known that the flash memory control logic can map out deffective memory cells so the control logic can certainly get access to the sense in one form or another.
Although there is information about getting at the residual contents of flash devices available it tends to be contradictory or not sufficiently indepth to judge it’s accuracy.
@ JimFive,
As far as I am aware the net result on the flash memory by it’s control logic and the OS driver is, not only is the file not erased, it is not overwriten either unless the flash memory is full (which is why erased pictures can be recovered even after many other pictures have been taken).
The purpose behind this apparantly odd behaviour is to spread the writes as evenly across all flash memory blocks as possible due to their very limited number of re-writes.
There are a number of sources of information on the Internet with regards the hows and the whys of flash memory including driver source code however a lot of it is not in a suficiently technical form.
Anonymous • January 14, 2009 2:45 PM
What are the best practices regarding the “chicken-and-egg problem” of saving the key of encrypted data?
Where and how (encrypted) keys should be saved in e.g. a webserver environment (storing encrypted data in DB, encrypt source code)?
Clive Robinson • January 14, 2009 2:56 PM
@ JRR,
“Having read all this, if I ever try to open someone else’s encryption, I’ll do it on a virtual machine with no enabled network interface.”
I would suggest you think carefully as you are not accounting for U3 compliant USB memory…
Google “U3 malware” for more information.
Fed Tech • January 14, 2009 5:57 PM
speaking of movie-plot scenarios, if you can’t wipe it, make it self-destruct… 🙂
SPT • January 14, 2009 6:33 PM
A simple real life scenario… Data Backup of a patient database.
My parents have an opticians here in the UK. Their computer database consists of basic patient data (Name, DOB, Address, etc.) as well as prescriptions for spectacles ordered. The medical record is on paper, indexed by the computer record (I’ve just not had the time to take them the whole way yet – 17 years later ;).
If they lost the paper record (e.g. fire) their business could survive. If they lost the computer record, they would be up the creek without the proverbial paddle. Off site backup has always been a priority and has bee carried out religiously since the first computer system (circa 1992). In those naive days, the Syquest 44MB disk cartridge used was taken home each night with no more protection that the database password. In hindsight, I believe that password was more protection than most systems of the time!
Anyway, over time the system moved platform (the original was a Mac) to PC, the Syquest became a Zip drive and the data was still password protected.
The Backup disks also multiplied because the working pattern for the opticians changed. They ended up with 4 part time staff with shift patterns that did not intersect. As a result, each staff member had their own backup disk… and the password (and shop keys). I should add my parents have never had a member of staff they don’t trust – it’s just never been a problem (though of course that’s until the first time).
About 4 years ago, I finally got worried enough about several unencrypted backups “floating around” to go out of my way and make the time to sort it out.
Step one – Physical.
I decided to scrap the Zip disks and move to USB Memory Keys, attached them to the shop keys to reduce the risk of losing a small device. If you drop it, chances are you hear the keys. People are also naturally “fairly” careful with keys.
Step two – Encryption.
I picked an encrypted volume protected by a key file stored on the shop computer. The database password protects the key file (its the same to help avoid it being written down). The key file is backed up on CD twice, one stored in my parents safe and the other stored in my safe (which is also in another town).
Plug the USB Key into a standard machine and it will ask if you want to format it.
You know what your doing with the volume? You still need the key file… You’re some kind of uber hacker/safe cracker and have managed to get the key file… You’ll still need the password (though if you got the key file you probably got the password long ago ;)… in which case, your welcome to the database because I don’t believe I can make a practical system used every day by non-technical people any safer than that!!!
sooth sayer • January 14, 2009 11:01 PM
@Jimfive
All flash devices support deleting part of or the whole device with one command. That’s why they are called flash memories.
Winter • January 15, 2009 1:52 AM
About duress codes. The only duress code I would ever accept would be a cry for help to law enforcement or security.
I really believe that “your money or your life” is a choice where I want to select to keep my life.
If I have things I REALLY want to keep out of the hands of others, I either keep their existence secret, or I make sure everyone knows I cannot get at them myself.
I mean the logic behind the time locks in store safes.
Winter
Clive Robinson • January 15, 2009 1:57 AM
@ JimFive,
I suspect that you and others are begining to wonder about the nature of the comments on Flash memory.
Flash memory was invented over a quater of a century ago and comes in two basic forms NOR and NAND and it is a form of EEPROM that although cheaper to manufacture has significant downsides such as slow write times, limited erase cycles and having to erase entire chips or very significant blocks within a chip. Each type is primarily used in different areas and although NOR Flash had standards some time ago NAND Flash only got a standard a couple of years ago.
Because of the downsides it is usually only design engineers that see Flash memory directly everybody else sees it through control logic and software drivers that try to hide the downsides.
Most memory cards and USB Flash devices actually have CPUs on them that make the Flash memory look like a HD or floppy formated as a FAT system. Some memory cards effectivly have an IDE interface.
The CPU or Flash control logic is responsable for “faking deletes” as part of “wear leveling”.
However you would be very unwise to use Flash as a direct replacment for a HD in a modern OS due to the fact that OS’s tend to write out access times even for reads, which would cripple a Flash chip in a very short order of time.
Likewise if you are going to use an encrypted file container you need to ensure that it does not use an encryption mode that could cause significant re-writing to the Flash memory chip.
It is a quite complicated subject and not one that is amenable to off the cuff answers as the view of Flash memory changes radicaly depending on what point in it’s control stack you look at.
I’ve had a scan around for links on Flash and other NV memory that will provide some further information.
This link provides a brief overview of the various NV memory chips. As far as I can tell this is the original article that many other web sites have copied/modified.
http://dev.emcelettronica.com/flash-memory-nand-eeprom-nvram-and-others
This WikiPedia link provides a more indepth technical article however it does not focus on the issues to do with Flash memory in practical implementations.
http://en.wikipedia.org/wiki/Flash_memory
This link provides a set of other links which the page owner appears to have vetted so have a browse through.
http://maltiel-consulting.com/Semiconductor_Flash_NAND_NOR_EEPROM_HDD_Device_consulting_expert.htm
greg • January 15, 2009 4:59 AM
@Winter
For the people who are serious when threating “your money or your life” usually don’t have that much of a problem with “your money and your life”. furthermore they are not known for their ability to keep there word, that is “your money or your life” should not be considered a legally binding contract.
There is episode of Blackadder that covers this nicely. “Did I say, your money or your life, my mistake, I meant your money and your life”.
So giving them what they want dose not change anything (other than you now having nothing to give them and you are a witness).
kangaroo • January 15, 2009 10:41 AM
@clive: However you would be very unwise to use Flash as a direct replacment for a HD in a modern OS due to the fact that OS’s tend to write out access times even for reads, which would cripple a Flash chip in a very short order of time.
That appears to be true for windows. Most of the unices allow turning off writing access times as a mount option.
See the difference in performance for the eeepc’s which use a flash as the main drives — it’s unusable under windows (and properly dies after a year), but is perfectly usable under linux (and benchmarks show very little extraneous writing).
So, let’s correct that: You would be very unwise to use it with a primitive OS that hadn’t been written to actually handle anything outside a very limited set of cases.
But then again, acer may just not be properly setting the Window mount options.
Zaphod • January 15, 2009 12:00 PM
@Clive “The CPU or Flash control logic is responsable for “faking deletes” as part of “wear leveling”.
Does that mean the various secure delete utilities are ineffective for these devices?
Worried of (just leaving for) Brazil, formerly UK.
kangaroo • January 15, 2009 12:01 PM
Clive: I would suggest you think carefully as you are not accounting for U3 compliant USB memory…
Now, who would be dumb enough to use Windows as their virtual host or client to do a break? Besides lacking most of the tools you’d want to use, that’s a horrible setup.
Those who use Windows deserve what they get 😉
Clive Robinson • January 15, 2009 1:00 PM
@ kangaroo,
“Now, who would be dumb enough to use Windows as their virtual host or client to do a break?”
“That appears to be true for windows. Most of the unices allow turning off writing access times as a mount option.”
You have me twice 😉
Seriously though MS OS’s are somewhat prevelant in many many areas forensics being just one of them…
Why I do not know I’m at a loss to explain it (politely). What I do know is it’s use mandates extra hardware which realy cannot be cost effective.
Also knowing which switches to use for mounting under a *nix should be a prerequisit for an old school sysadmin, however most *nix users these days are not old school sysadmins.
@ Zaphod,
“Does that mean the various secure delete utilities are ineffective for these devices?”
There is no simple answer to this because of the way USB memory devices are designed.
To put it simply the designer has a number of compromises to work around to make a product in a very cost sensitive market.
The only interface they have to worry about meeting standards is the USB interface as it is the only “public interface”.
The interface between the CPU/control logic and the flash memory is private and therfore it is upto the designer(s) and their managment.
In most cases this private interface will be a minimal function interface for two reasons,
1, The interface has to work with quite a few different Flash memory devices, not just in capacity but from different manufactures.
2, Time/cost to market are the areas that define the profit, the longer/larger these are the less the potential profit.
It is only where security is a primary design goal that it is likley that deletes will work the way you think they do.
You then have to ask if a delete does not work as expected is this an actual issue?
The answer to this, is determined by the level of ability of those that might wish to read the data of your device, and the level of tamper proof construction of your device.
The cheeper the construction the easier it will be for an oponent to get access to the PCB tracks etc of the private interface and be able to read the flash memory chip directly.
A simple threat reduction technique is to fill the case of your device with an appropriate epoxy (one that has good thermal conduction and has granular quartz in it).
Another is to always use encryption on sensitive files but… use the right type of encryption a stream cipher is a no no as are quite a few block cipher modes… thus you should use software that is known to work not just securly but effectivly with Flash memory devices.
Peter • January 15, 2009 7:10 PM
There is a simple solution: ban the use of USB sticks and enforce that all remote data access is performed via a thin client – the technology has been around for, oh, at least a decade. The problem of encryption on removable storage then becomes a non-issue. Attention can be focused on securing the remote devices (laptops and the like) against other forms of abuse.
In the past I’ve had some of my medical data (albeit very limited) lost by a member of medical staff who stored it on a USB stick, and I must admit I was pretty pi*sed – mainly at how it was possible to copy data onto the device in the first place.
In public services at least, the only reason I can see for permitting the use of removable storage (either USB or CD) is as an excuse to leak data. There is the very rare exception of having to move data from an air-gapped network to another network and this could be considered an exception with carefully applied encryption.
Randall • January 15, 2009 10:02 PM
What this really makes me think is that “bad” key/data management may not be so bad if it prevents stuff like this. Public-key encryption without protection against MITM attacks looks positively great.
Steve Davies • January 19, 2009 8:53 PM
Thw way data nneds to be managed is an attribute of those/that data. That includes all the ‘usuals’ – backup, availability etc and perforce encryption. Once the data is understood from that flows the allowed placement and methods etc. Let it out of those bounds and you are no longer managing or controlling it. And it happens all over the place, in industry and governments – and the database state will just continue exacerbate this issue. This is really a non subject. Flash Drive abuse is more like it.
Or rather, organisationally “Can’t get the basics right, what are our options ?” The answer to that is self evident (I hope).
For the individual case don’t put anything if any value whatsoever on a flash drive – eliminate the risk.
Pen Plum • June 21, 2010 9:21 AM
TTI Guardian provides the best knowledge and experience in Duress Alarms. By providing my staff with a Duress Alarm ensures less risk for my company. TTI Guardian has helped my company improve response times to any incidents. Visit their website at http://ttiguardian.com.
Subscribe to comments on this entry
Sidebar photo of Bruce Schneier by Joe MacInnis.
Glenn • January 14, 2009 6:20 AM
I’m suddenly struck by the idea that one should write one’s encryption code with a ‘duress code’ option that wipes the data instead of decrypting it.
Then put the duress code on the side of the device.