Security of Solid-State-Drive Encryption

Interesting research: "Self-encrypting deception: weaknesses in the encryption of solid state drives (SSDs)":

Abstract: We have analyzed the hardware full-disk encryption of several SSDs by reverse engineering their firmware. In theory, the security guarantees offered by hardware encryption are similar to or better than software implementations. In reality, we found that many hardware implementations have critical security weaknesses, for many models allowing for complete recovery of the data without knowledge of any secret. BitLocker, the encryption software built into Microsoft Windows will rely exclusively on hardware full-disk encryption if the SSD advertises supported for it. Thus, for these drives, data protected by BitLocker is also compromised. This challenges the view that hardware encryption is preferable over software encryption. We conclude that one should not rely solely on hardware encryption offered by SSDs.

EDITED TO ADD: The NSA is known to attack firmware of SSDs.

EDITED TO ADD (11/13): CERT advisory. And older research.

Posted on November 6, 2018 at 6:51 AM • 46 Comments

Comments

Clive RobinsonNovember 6, 2018 7:48 AM

@ All,

The underlying problem is such that to be secure you need to have different encrption schemes at

1, The application level.
2, The file level.
3, The volume level.
4, The OS level.
5, The hardware Interface level.
6, The hardware physical level.

If you don't compramising information will leak.

Dorothy Denning wrote about bits of this back in the early 1980's. The likes of Brian Snow have also mentioned it going back even further.

Which is why I've mentioned it on this blog a few times in the past when data encryption has come up.

Oh and remember core memory likewis has similar issues and levels (though the last three are usually compressed into a single layer).

Clive RobinsonNovember 6, 2018 8:06 AM

@ Bruce,

Speaking of encryption layers, there is another one that although myself and @Nick P have talked about, does not come up very often. But is slowely getting interest in the academic community

It's "geo-encryption" which uses not just location data but velocity and direction information as well.

I've talked about it on this blog also with respect to the "something you know" factor for multiple factor authentication.

This is a recent paper talking about geo-encryption for communications systems,

https://www.ijirset.com/upload/2018/february/83_Geo-Encryption.pdf

However they are actually quite a long way behind the curve on geo-encryption compared to non-academic fields of endevour, their idea was discussed to death amongst some oh a decade to a decade and a half ago.

Gerard van de SchootNovember 6, 2018 8:43 AM

I read it yesterday. Again it's the damn Dutch guys who did it.

The real problem is that when you even can't trust the hardware, what else can you trust? Hint: Intel.

TimHNovember 6, 2018 9:00 AM

This likely explains the complaint I've read that FDE with Bitlocker is much faster than with Veracrypt. If BL is using the native hardware encryption, then it will be that much faster than VC, despite speed improvements with AES-NI.

RealFakeNewsNovember 6, 2018 10:06 AM

I thought it was already known that hardware disk-level encryption was pretty useless?

If you look at the specs, few drives actually state the algorithm used. Some do actually say "AES xxx-bit encrypted". How secure are those particular drives??

MeNovember 6, 2018 10:53 AM

When I worked at Seagate I know there was a lot of attention paid to making sure we didn't mess up the FDE. We knew it would only take one news story about our encryption failing and our entire line would be unsellable. As far as I know, we never had an security failure.

In the end, I think we actually sold more Crypto-erase drives than FDE. Crypto-erase was basically the same as FDE, but with the encryption key in a known location (the firmware knew where to get it, but there wasn't any way to get it out through the SAS/SATA API, nor through the serial interface, a determined hacker might be able to find it). As such, it worked just like a regular drive when in use. When the drive was to be disposed of, you deleted the old key and generated a new one. Blank drive within a second.

EthanNovember 6, 2018 11:38 AM

So are there any brands that get this right? Far as I know Apple does hardware encryption correctly. What about Intel SSDs?

My understanding is that it's the implementation that is done wrong. So what companies are implementing full disk hardware encryption correctly (besides Apple)?

Instead of just writing off hardware encryption as the researchers seem to encourage, it would have been nice if the researchers could help us identify the companies who are implementing correctly.

Clive RobinsonNovember 6, 2018 12:02 PM

@ Me,

When the drive was to be disposed of, you deleted the old key and generated a new one. Blank drive within a second.

I do wish people would not say thst, because it's compleatly untrue.

Erasing the encryption key does not erase the contents of the NAND Flash or other storage media the drive might use.

Because of "wear leveling" and often incorrect usage of crypto modes it becomes possible to recover some information iregardless of if you have the encryption key or not.

But there is also the question of "burn in" in both NAND and NOR Flash and other storage types. Nobody has yet come up with a definitive answer that says "burn in data recovery" is not possible.

It's why when part of the UK Gov "contracted out" the design of an encrypted thumb drive they specifically excluded "key erasure" as a data delete method, and still required multiple "random over write" of all storage memory. Which as any hardware engineers reading along will know is not something you want to be doing if all you have is "backup battery" power to work with.

Oh one nice thing about "key erasure" is of you have central crypto-key managment. You can if you recover a drive get the data back because you centrally have the encryption key.

If your memory device has a GSM radio modual, then you can store the device key in core RAM using a RAM&Register protection scheme[1]. You put a PubKey pair in the device which enables you with care to securely transfer the data encryption key across the GSM network.

Thus it's possible to design a hardware device that you can use where you can not reveal the password or encryption key because you genuinely don't know them, and it takes atleast on third party to enable them. If the third party is outside the jurisdiction you are in it's game over for law enforcment. Just in case you are worried abou the third party getting preasure put on them as @Nick P suggested having them in China would probably solve that. But to be a bit more certain I counterd with "multiparty key sharing" from several antogonistic jurisdictions, as it has the extra advantage that one or more of the third parties can lie and send a false or "duress" key share, and there is no way for any authority to know which third party or multiple third parties it was.

[1] If you design your RAM&Register protection scheme properly then you do not get "data burn in" and even if the device is captured an attacker can not recover the encryption key from examining the RAM contents. I've discussed how to do this before using "data shadows" with burn in protection being done from a time based interupt scheme. @RobertT also mentioned he had seen a system implemented in silicon that used a chaotic Lorenz attractor system to both hide the key and prevent data burn in. Have a read of,

https://www.schneier.com/blog/archives/2012/08/is_iphone_secur.html#c857693

And down that thread we talked about issues to do with encrypted storage in a consumer device (iPhone) and even over six years later it's still highly relrvent today including this thread.

X-MouseNovember 6, 2018 12:27 PM

This challenges the view that hardware encryption is preferable over software encryption.

Very good. Encryption or other compute-intensive operations done "in hardware" are of course done in highly proprietary, hastily coded, and impractical-to-update SOFTWARE, running on a small microprocessor with limited resources, no true opreating system, and limited if any security.

OneMoreQuestionNovember 6, 2018 12:54 PM

According to the overview-table and description in the paper, Samsung's Evo 850-drive seems to be only problematic, when used with ATA-security in high-mode. Locking it via TCG-Opal (i.e. bitlocker or sedutil or the likes) should be fine, or have I misread their findings?

TimothyNovember 6, 2018 1:53 PM

The research paper provides 6 case studies on 2 brands of Solid State Drives: Crucial (Micron) and Samsung.

An interesting tangent is that there is currently a major stir-up from the U.S. regarding intellectual property that they allege China has taken from the American company Micron.

Micron is an Idaho-based company that produces semiconductor devices, including DRAM, flash memory, and SSDs. Its products are marketed under the brands Crucial and Ballistix.

The stolen Micron IP is feared to be helping fuel the unfair advancement of China’s semiconductor industry. In 2015 China announced its “Made in China 2025” plan that included a goal to dominate 10 industry sectors, with the semiconductor industry being a relevant component of those. The company who allegedly stole the IP is Fujian Jinhua Integrated Circuit, a maker of DRAM chips - commodity semiconductors used in smartphones, laptops, and servers.

On October 29, the U.S Commerce Department put a ban on exports to Jinhua. America sees the Jinhua products and competition as a significant threat to the military supply chain and national security.

From the November 3rd The Economist article "Chip shot: An American ban defangs a nascent Chinese chip champion"

Also more articles from Slashdot

VRKNovember 6, 2018 3:42 PM

@ Clive Robinson.

Thanks for your note on Geo-Encryption. This breathes more life into my hope of seeing encryption taken out of human hands, where it can't be traded for a bowl of soup.

Looks like Chris Veness has provided a grand breakout in javascript for great circle geodesics.

Perhaps that could be utilized in implementing a key based hack for TWO known endpoints... but I have felt that we should let the stars tell where and when we are, such as from a sundial / sextant app in our phones? :)

WeatherNovember 6, 2018 4:04 PM

I don't trust web, is that link.htm?JavaScript(cookiemacure)
Got a story the non official openssh for window had a heap bug, no doubt about cmpstr, if you know ausername 4,8,12 etc long you had a couple hunderd strings that would make root0x3a111111àaaaaaaaaaaaar.. Overflow the heap

Yeah these things are old but were is tipping point zdi

I'm sure with more Rops these days I could have a income

Clive RobinsonNovember 6, 2018 7:21 PM

@ VRK,

Looks like Chris Veness has provided a grand breakout in javascript for great circle geodesics.

The problem is that the haversign formular is based on a sphear so is kind of a first aproximation.

Whilst it gets longitude quite accurately around the radius median it is inacurate for most lattitude measurments especially as you aproach the poles.

Whilst this might not appear important to most it makes on heck of a difference if you are involved with any of the off shore energy businesses be they petrochem, wind or wave power.

But... It also does not take account of the effects of planatery bodies like the Sun and the moon both of which effect the shape of the earth due to the effects they have on the ocean bulge, or tides if you are standing on what you think is solid ground.

You can correct for the oblatness of the earth using a "remaping process that can be done with a look up table and spline curves or the simpler Beizer curves based on Bernstien polynomials

But correcting for planetary effects is often best done using a form of harmonic addition, which is what astronomers use to calculate the orbits of the planets and moon.

All of which takes a bit of number crunching, to put it mildly. Which in my past was made quite a bit more complicated because I had to write the required "large floats maths library in assembler... It was a blessing when Intel brought out the math co-pros for the 386 and 486 CPUs because they were IEEE 754 standard compliant...

On a similar note the major planatary bodies and moon also effect those orbits of satellites that we use for our various "positioning systems" as does the change in earth's orbital path. The correction calculations were way beyond what most GPNS receivers were capable of calculating for quite some years. So they are calculated on earth in
Colorado Springs at the Falcon Air Force Base, where the atomic clocks in the individual satellites are compared to those in the earth based master refrence. Thus the relatvistic correction data is sent upto each satellite along with the ephemeris and almanac data and engineering information. This is then transmitted by each satellite along with the raw timings downwards to the receivers many of us now depend on.

When you consider a 1nS timing error would translate to a positional error of around a foot and modern upper end recievers can provide positional data better than ~1/2 inch it quickly becomes clear that the correction data is very usefull.

TimothyNovember 7, 2018 7:21 AM

US-CERT released an advisory on “Self-Encrypting Solid-State Drive Vulnerabilities” on November 6, 2018.

NCCIC is aware of reports of vulnerabilities in the hardware encryption of certain self-encrypting solid-state drives. An attacker could exploit these vulnerabilities to obtain access to sensitive information.

NCCIC encourages users and administrators to review Vulnerability Note VU# 395981, Microsoft's Security Advisory ADV180028 and Samsung's Customer Notice regarding Samsung SSDs for more information and refer to vendors for appropriate patches and recommendations, when available.


ZDNet’s Catalin Cimpanu wrote an article covering it “Flaws in self-encrypting SSDs let attackers bypass disk encryption” as did The Register.

@matthew_d_green and others tweeted about it.

*Also to correct my earlier comment, it appears there were 7 case studies

ArclightNovember 7, 2018 11:39 AM

@Clive Robinson. That geo-encrypion scheme is similar to the permissive action link (PAL) technology used to secure nuclear warheads. The general theme is that the weapon isn't supposed to operate outside of a very narrow box of physical conditions associated with an authorized delivery by the missile/gun/etc. that it was designed to deploy from.

Would this not require access to an encrypted or signed GPS datastream to prevent spoofing though?

Clive RobinsonNovember 7, 2018 1:56 PM

@ Arclight,

Would this not require access to an encrypted or signed GPS datastream to prevent spoofing though?

As they say "And thereby hangs the rub"...

The US military have been trying to find a way to have "spoof-proof" GPS for years and they have not yet found a way that does not involve some kind of "secure device" that can not be accessed by anything other than a secure receiver in "classified crypto equipment"[1]. So never ever going to make it into the civilian or even other Government markets.

But there is if you take a carefull look in the paper I gave the link for, a glaring hole in their protocol. That is the authors have forgotten that you can not go faster than the speed of light thus distance equals "time shift". Which means one of two things, either it's vulnerable to a narrow range of "replay attacks" or the client system needs a time machine[2].

Oddly this "distance equals time shift" problem crops up all over the place not just with physicists and their "time cone" diagrams. Whilst it can not be fixed engineers can occasionaly find work arounds but at some other expense (needlessly wide bandwidth had less filter time delays and faster rise times for instance). However protocol designers rarely if ever consider it except when they start getting involved with high frequency trading... Where they can and will pay unimaginable amounts of money to tunnel through mountains to shave a few mS (~1nS per foot saved) off of communications paths. Pay millions to rent fields to stop competitors putting up radio towers and all sorts of other things, some of which like bribery are either illegal or highly questionable.

The classic one that is comming home to roost with protocol designers is "distributed database updates". That is if your database is on three widely spaced nodes how do you deal with the update deadlock. That is node A makes a change and sends it off to node B which sends it off to node C. Provided neither node B or C update the same record in a time period less than the total propergation time it's not an issue. If however they do you get an issue of which update takes priority. Thus the first thought solition is you use time stamps and decide on those. Only it is difficult to hold all nodes to the same time unless you use atomic clocks which need continuous adjustment for "relativistic issues"[3] for people moving at different speeds, which happens if your buildings are at different lattitudes... Having solved that you have potentially cured the "two change" issue, but not if three or more nodes make changes... But there is still a hidden issue which is "what did you make changes to" that is the nodes update at different times as it propergates across the network thus they are in effect "out of step" as it happens, any additional update during that time therefore could be on old/out of date data. People then stat thinking about "record locking" but that has other issues as NFS admins can tell war stories about. Put simply no network is reliable in it's entirety at all times, if you issue a lock it may not happen at all nodes, another node might lock the same record before your lock gets there, a node might go down and hold a lock in some way etc etc etc. Thus simple protocols become nightmares with distributed scale. Oh and as far as we can tell there is no effective solution only partial solutions that all have issues...

And yup I have not just war stories but scars from such protocol developments.

[1] I'm not saying there is not a way to do it, especially when the US Mil also have other motives such as keeping tech out of non aligned nations hands. But I've not yet seen any tech that convinces me it is possible.

[2] Yes I talk of the NSA and other Gov entities building "time machines" by "collect it all" but to be secure this needs to "see into the future" not "relive the past" (which historians do all the time ;-)

[3] Thankfully the 1PPS GPS signal and phase locked carrier frewuency and chip rate clock can save a great deal of expense and difficulties because the USAF in Colorado Springs does all of the corrections for you. But the "Commercial Off The Shelf" (COTS) price of equipment to do this is still eye wateringly expensive...

carrotsNovember 7, 2018 7:18 PM

@Clive Robinson

"I do wish people would not say thst, because it's compleatly untrue."

Agreed. However, write a 128..256 bit password on a piece of flash paper: Data destruction at the speed you can light a match!

Clive RobinsonNovember 7, 2018 11:56 PM

@ carrots,

However, write a 128..256 bit password on a piece of flash paper: Data destruction at the speed you can light a match!

Yes, if you can first find a piece of flash paper large enough for 256 bits of "entropy" ;-)

Then there are the issues of, if the flash paper does burn entirely to smoke, what do you get "data destruction" of? In reality "only of that copy" of the "password", but not of anything else. Because that's all the same as it was before you put a lit match to that piece of flash paper.

What else might or might not happen as a side effect, depends very much on the technical system being used by the user(s) and the OpSec they employ in it's use.

So if there is a "password" backup in an envelope in the office fire safe...

Yes I'm belabouring the point, but it's a point that unsuprisingly many people sometimes have trouble getting to grips with. Whilst jargon and similar might help speed up the communications of those who correctly understand not just the jargon but the full context in which it's being used, it just confuses the heck out of people who don't.

Which is a point not lost on George Orwell long befor he wrote 1984 back in 1948.

We often see the confusion with "security by obscurity"[1] it's a "term of art" that you can not get understanding of by looking the individual words up in a dictionary.

A more technical example can be seen with programers and the use of "nonce" or even "random" which is why,

    Four is a random number.

Is an "in joke". The same as the,

    Why did the cat slide off of the roof?

Is to some physicists and, the punch line of

    "Oh plus a constant"

Is to some mathematicians.

I'm mindful that the readership of this blog has very varied depth and breadth, and try to address it which has had the side effects of making me look pedantic to some but bringing understanding to others ("You can't win em all" ;-)

[1] If anyone has a "one sentance explanation" that precisely and unequivocally explains "security by obscurity" to a non expert, I would not be the only one who would be greatfull of it. The Wikipedia attempt of,

    In security engineering, security through obscurity (or security by obscurity) is the reliance on the secrecy of the design or implementation as the main method of providing security for a system or component of a system.

Which whilst getting close "Does not cut the mustard" with "non experts", who will have unanswered questions from it. Due to the use of other "terms of art" and an assumption.

AnuraNovember 8, 2018 6:36 AM

@Clive Robinson

A 20-word diceware passphrase has over 256 bits of entropy. It only seems long because we live in the world of Twitter.

Clive RobinsonNovember 8, 2018 1:54 PM

@ Anura,

A 20-word diceware passphrase has over 256 bits of entropy.

Only if the dictionary is 7132 words or longer. Which is larger than the average persons vocabulary.

But that is beside the point I was joking about. Flash Paper is most frequently used by magicians and is usually the size of a small "hand rolling paper".

The reason is some magicians make their own they take a packet of Rizzler papers (or what ever the local equivalent is). Lay them out and brush them down with a nitrate or permaganate solution.

The reason that they make Flash Paper that way, is that when it burns it generates enough thermal lift to float up by it's self. What the audiance sees is what looks like a flame with a life of it's own. You can make them coloured by adding other chemicals.

Any way unless you have teensy-weeny hand writting you would not get 26 words --from a 1024 size dictionary-- on such a small piece of paper.

TheoNovember 8, 2018 2:04 PM

With most diceware word lists a 20 word pass phrase fit in a tweet easily.

Clearly a good many people are using twitter to transmit diceware pass phrases, although it seems like a bad idea to me.

Sorry, couldn't resist.

WeatherNovember 8, 2018 4:12 PM

Theo
It is rc4 or rc5 c
For a nonce value, for a one time key,you should know the replied based on that

AnuraNovember 8, 2018 6:17 PM

@Clive Robinson

Each diceware phrase = five rolls of the dice = 7776 unique words. Here is the first diceware dictionary I found; get a dice (or build a physically non-deterministic dice similator) and give it a try for yourself, and calculate how much entropy a reasonable passphrase has. It works pretty well, actually. If you don't need to remember it then twenty words on flash paper is probably not that big of a deal so the only thing that really matters is whether you can type it.

https://github.com/chadlavi/diceware.sh/blob/master/dictionary.txt

Clive RobinsonNovember 8, 2018 10:38 PM

@ Anura,

then twenty words on flash paper is probably not that big of a deal

Just how tiny is your hand writing?

Or are your cigarette "hand rolling papers" the size of Havana cigars where you come from ;-)

I know the Russian's used special printing techniques and very soluble inks to put their Spy "one time pads" on flash paper a couple of sizes bigger than cigarette papers. But if you get to see one in a Museum they are usually mounted under a large magnifying glass, otherwise you just can not read them.

AnuraNovember 9, 2018 1:48 AM

@Clive Robinson

Flash paper is available in much larger sheets from magic shops. As for the scribbles I call hand writing, I can fit the words "one" through "twenty" on a one inch tall by four inch wide piece of paper with four lines of five words each. I could probably get that on a piece of rolling papers anyway.

ErikNovember 9, 2018 11:15 AM

@Ethan beat me to it with his comment above - a few years ago, Apple decided to stop trusting drive-based encryption and started moving those functions into a coprocessor ("T2" chip) that they designed themselves - it handles drive encryption, boot signature verification, always-on listening, and other functions that are considered to be security-sensitive. At the time, the drive encryption part struck me as a strange bit of overkill but now one wonders if they took a look at some SSD firmware one day and said "Oh, hell no...."

carrotsNovember 9, 2018 1:49 PM

@Clive Robinson

I managed to squeeze 64 hex password on paper the size of 2 by 0.5 inches. The point of being able to write it down means you don't have to use diceware, just random characters. To ensure there's no record of password creation, rolling a 16 sided dice is probably better than using some application to generate it.

One has to assume of course that the encryption works (unlike in the context of this study) and that it's the only copy of the password. So it was mostly to highlight the idea that fastest way to wipe data might be outside the computer. If it takes too long to find the password then it can be considered destroyed.

There's an endless amount of increasingly sophisticated attacks, of course. For example, an evil maid attack effectively defeats FDE regardless of where the password is stored in.

Clive RobinsonNovember 9, 2018 7:17 PM

@ Erik, Ethan,

Apple decided to stop trusting drive-based encryption and started moving those functions into a coprocessor ("T2" chip) that they designed themselves

Apparently the T2 chip now on new hardware also stops "Linux" being put on Apple hardware hard drives. Which might upset Linus, apparently he's been a fan of Apple hardware for a while.

https://www.forbes.com/sites/jasonevangelho/2018/11/06/booting-linux-is-impossible-on-new-apple-hardware/

Clive RobinsonNovember 9, 2018 8:04 PM

@ carrots,

To ensure there's no record of password creation, rolling a 16 sided dice is probably better than using some application to generate it.

I've looked into sixteen sided dice and twenty sided dice. Compared to a couple of standard six sided dice they are more difficult to get and a lot more suspicious if found on you.

Thus I use two standard six sided dice. One with whiye spots one with yellow. It's a matter of a moment to mentally convert the face values to a number between 1-36 and then adjust for the number range you need. It's a habit I got from an early age as my father used to use it to work out his "football pools". I think the most he won was around one hundred and eighty pounds, it does not sound much now but back then it was around four weeks money for a skilled craftsman.

Whilst encryption works, it's the implementations that lets us down most of the time. This ranges from using it in the wrong modes for the application it's being used for, through to "time based side channels" that leak either plaintext or keytext.

Or worse on the likes of a smart phone or other comms connected device, where an "end run attack" that just grabs the user interface via a driver shim or similar and sends it around the encryption app to the comms channel is probably todays biggest threat. Hence my nagging about moving the security end point not just off the device but a good deal away from it to give better security than just an air gap.

Installing remote "key loggers" these days can be done via the OTA interface on most "smart devices" making the poor old evil maids redundant. Thus they are enrolling the TSA knuckle draggers to "up skill" instead, or their Australian equivalent...

Mind you since the new year most if not all "Top Down Security" is now busted for all to see, not just a couple of old grizzeled graying engineers. The likes of Meltdown, Spector, and other "bubbling up attacks" had rendered all software and a number of hardware security featutes effectively broken more or less beyond repair. The fact that now hardly a month goes by without somebody reporting a new bubbling up attack or varient shows why we need two or more energy gapped computers to maintain a modicum of privacy let alone security.

Which means from my point of view important as it is Disk Encryption is not at the top of my security list, but segregation is...

Anyway the reality of life is what ever we do on a comms end point these days, there will be someone with a fat salary chasing our private data...

GerryNovember 10, 2018 12:21 PM

@Clive

I still don't understand how 'geo-encryption' could possibly provide any acceptable security AND be technically implementable. Do you have any link to a decently written paper, possibly in a reputable journal? The one link you gave is neither, and by a good measure. Paywalls wouldn't be a problem.

Clive RobinsonNovember 10, 2018 3:32 PM

@ Gerry,

I still don't understand how 'geo-encryption' could possibly provide any acceptable security AND be technically implementable.

Well it depends on what you mean by security and technicallt implementable...

Have a look at MIMO RF systems for one geo-encryption system that works.

But GPS based systems don't realy work security wise (hence my comment about the worth of the paper).

My use for it is an extension to the "something you know" factor.

As we know humans are fairly crap at remembering passwords especially if they don't use them very often or at all untill an emergancy. However remembering places and a time is mostly trivial for humans, and with GPS can give a considerable entropy, especially if you include a directional vector.

So when your ordinary password times out due to your phone being ceased by authorities you need a "reset" system. Thus taking your phone to a location you have chosen at a specific time and pointing it at a local feature that software can recognise and then typing in your ordinary password will unlock the phone.

In effect you have "extended" the traditional something you know password with geo, temporal, direction and image factors.

Providing the software is correctly written so as not to leak information it would provide a workable fairly high security way to provide a duress proof way of reenabling a password.

One of the reasons geo-encryption did not become better known back at the begining of the century, was attention focused not on where it would work but on where it would not, and that got talked to death... Which is a shame because under certain circumstances it can provide a much better system than other more conventional methods that often become unworkable due to the likes of human failings.

If you look in the back of the paper there is a refrence list which will give you the Denning and other papers which you can then do reverse searches on to get more recent papers.

My point though is it is an area of research that needs to be more widely considered.

GerryNovember 11, 2018 6:18 AM

@Clive

Thanks, now I understand what sense you mean 'secure'. Sure, GPS coordinates could provide more entropy than a short pin without need of remembering any digit, so in that sense it would be an improvement. As a back of the envelope estimate, if the limiting factor is the accuracy of a consumer-grade GPS receiver one can reliably get a little more than 20 bits of entropy by picking one particular GPS position within a 10x10 km area centered on one's house. A bit more than 30 bits if one could pick any site at will in the entire UK. But these are extremely optimistic estimates because in reality most land, even assuming you can access it, is too devoid of landmarks for a human to go back to 'from memory' at the level of accuracy of even a consumer grade GPS.

As to MIMO I'd think it provides diversity rather than security because observing the signal at a sufficient number of locations would allow estimating the signal at any other location - not trivial but also not complex in the security meaning of complexity. Am I correct?

Derek November 11, 2018 4:26 PM

Does this also mean that you could make it look like the drive supports encryption when it doesn't. So bitlocker would just do nothing if enabled later?

Clive RobinsonNovember 12, 2018 2:02 AM

@ Derek,

Does this also mean that you could make it look like the drive supports encryption when it doesn't. So bitlocker would just do nothing if enabled later?

Yup, that's more or less the case.

Think of it this way, bitlocker can not reach through the drive electronics to the raw data in the Flash in a reliable way. Because it has to go through the drive electronics and there is no way to tell if those electronics are being honest or not.

But even if it could get honest access how could bitlocker tell the quality of the encryption? It would need to know not just the key, it would need to know the algorithm the drive used and mode it is used in.

Now consider you are a malicious actor you could get at the Flash storage in the drive electronics. It would not be difficult to come up with an algorithm that would sector by sector disable the encryption, so after a while the drive would be compleatly decrypted but you would not have seen a performance hit or much increased power drain... Oh and Flash does not clank or click like a mechanical system, so you would not get an audible clue the drive had changed behaviour either...

It's one of the reasons I said at the top of the comments above,

    The underlying problem is such that to be secure you need to have different encrption schemes at,

And went on to list the layers you need to address.

echoNovember 13, 2018 3:14 PM

@Clive

Any way unless you have teensy-weeny hand writting you would not get 26 words --from a 1024 size dictionary-- on such a small piece of paper.

Shorthand and other alternative writing systems may provide a form of compression. The provided link lists a number of systems with explantions of the writing system and visual examples compared to normal text. Variations and combinations of these schemes might have some utility too.

http://www.alysion.org/handy/althandwriting.htm

Clive RobinsonNovember 13, 2018 10:37 PM

@ echo,

Shorthand and other alternative writing systems may provide a form of compression.

Without redundancy there can be no entropy...

Many shorthands actually take up more page space due to trying to harness the fluidity of longhand, and still having "pot hooks" that are accurately recognisable some time later. As the article notes most are just a short term at best aide-memoire to go from dictation to typed letter. I've known a couple of 80-100 wpm typists, who can type as fast as most people can dictate whilst thinking about what they are saying. Oh and a couple of military telegraphists who could out type the old mechanical teletypes --KSR/ASR machines-- that were supposedly good for ~90wpm.

What the article does show however is the level of redundancy in written english. It's lack of precision, is actually one of it's strengths, it's lack of rigidity allows for creativity. Which in turn encorages inovation, thus progress.

It's actually quite surprising just how much our "mother tongue" effects our outlook on life.

meNovember 14, 2018 6:20 AM

@Schneier
you made my day by adding the other research that i have linked.
I'm happy to have added something useful to the conversation ^_^

meNovember 14, 2018 6:32 AM

@all
i'll add a quick tl;dr of the older research:
-they "used" aes (good)
-but the key comes from c functions *srand/rand* which literally anybody knows that are not cryptographically secure
-in some cases due to implementaton flaws, sometimes you have 256 possible passwords, sometimes you have 2^32 (4 bytes=the seed of rand) again super easy to bruteforce.
-there are multiple backdoor passwords

Clive RobinsonNovember 14, 2018 3:53 PM

@ echo,

Did you just drive a coach over me and mansplain me?

Err not intentionally.

The "Without redundancy there can be no entropy..." is one of those jokes like "4 is a random number", only it's ment to be said in a neutral but monotonic voice like a "Vulcan pronouncement" or the "Their can be only one" of the highlander movies.

As for "out typing" and old mechanical teleprinter it's one of lifes "ouch moments" as the clutch grinds and graunches and wise telemechs vanish as if by magic to some place unknown. Because adjusting that mechanism is to be blunt a right royal pain, if you follow the "official method"...

But those with grey hair know to have a pack of hand rolling cigarette papers in their tool kit, as the very much unoficial method which uses them can be way easier and many times faster.

Which brings us back to "just what can you get on a Rizzler" cigarette paper where space is somewhat short in both directions.

Thus I'm still doubtful that an ordinary mortal using ordinary pens etc will get a 256bit AES key to fit when hand written no matter how you encode it.

You could have 256 binary symbols such as a short and long vertical line, but how do you tell them apart after a long run of either. You could use 64 hex chars which you could get on but you need spaces to group them otherwise your chance of getting the sequence write is low. However each extra bit width you use doubles up the number of symbols which obviously reduces not just legability but increases potential errors so you need extra symbols for error correction, which in turn need their own error correction of a different form. So just the humidity from your hand or in your wallet will cause the ink etc to smudge reducing legability thus needing more error correction etc.

There are so many "hidden gotchas" in covert communications systems especialy of the degrading store and forward variety that has a deadmans / antiduress fast destruction features, it's still a quite wide area of research.

There are some horror stories of the "blew up in my face" variety. There are stories of the use of cellulose papers washed in oxidizing chemicals to give high flamability and inks that are very soluble that were independently developed. But... when mixed together the ink is a catalyst to the fuel (cellulose) and oxidizer mix that makes it unstable with time.

A similar but more famous example is "exploding billiard balls". Nitro cellulose or celluloid was the wonder plastic of it's time and used in just about everything from shirt buttons through handles for knives and forks through piano keys and billiard balls. It turns out that nitro cellulose is a fuel oxidizer mix that over time will degrade and become a vibration sensitive explosive... The speed of the degradation is in part the general environment but also mechanical shock. Thus the billiard balls would eventually explode in blazing balls of fire.

Now any competent chemist on being told what was in the ink and paper would have warned about the danger. But as we know when secrecy is involved information gets compartmentalized, and the left hand does not see what the right does and vice verser. The result was store rooms of code books suffering what was thought to be very clever arson attacks... Because being "secret" the investigators were also kept in the dark...

The world of secrecy is full of similar left not knowing right stories...

echoNovember 15, 2018 1:11 PM

@clive

Right! Where were we? Defining the problem as achievable by an ordinary person without access to special tools or techniques I managed to fit a AES 256 bit key in base 16 on one side of a cigarette paper written with an HB pencil. Slightly better compression could be achieved with base 36 which would save five character spaces.

I haven't attempted to use any other form of compression scheme such as one of the more space efficient shorthand systems or anything like a memorable look up table or equivalent scheme.

I also didn't use any tools like a hand rest or magnifying glass.

I have discovered videos of people doing miniture writing which can achieve much higher density but this requires levels of expertise or extra equipment or time to read and/or write the message. I disregarded this as it was a special case behind the scope of the original problem.

I did not apply an error checking scheme.

Clive RobinsonNovember 17, 2018 2:02 AM

@ echo,

In effect what you write is an "all or nothing" "limited retry" password. Type it in wrong and it's very quickly "game over". Which even with a pristine copy is quite likely to happen, which is why I wince when I see things like,

I did not apply an error checking scheme.

It's unfortunatly a common failing in security systems where you are expected to type in what appears to human eyes a long random string.

Which is odd because it's long been known with hand written letters that things get mistaken...

B - 8, C - 0, D - 0, E - F,3, F - E,7, b - 6, 1 - i,I,l, 2 - 7, 3 - 8, 5 - s,S,...

Are just a few of very many errors people make when reading hand written text.

Likewise it's also been known for a long time that hings get worse if they are not "grid aligned" and "grouped".

Grid alignment in a mechanically typed font is usually something like a quater of a letter width block after a letter and between a quater and a half a letter hight block below a letter. With hand written letters a similar or greater spacing is usual for legability.

Grouping is used to make random memorable over a short run. There is a saying about human short term memory "five plus or minus two" which says basically the minimum we can remember is three random letters and if they were the start or end of a group. Which is why the accepted intetnational standard for "codes" is "upper case letters in groups of five letters with a single space between groups" and has been for considerably more than a century, and why the "word" of "words per minute" is "five letter average".

With regards,

Slightly better compression could be achieved with base 36 which would save five character spaces.

Whilst 36^50 is greater than 16^64 / 2^256 you end up with a leading / terminating encoding issue as the difference is around 5.6 times larger. Humans tend not to be good with such ambiguity, especially when writing software to match it.

So what you do write should be "armoured" in some way. For very limited error detection and correction you look for one bit extra for every bit length doubling of data. So 256 bits of data would need an extra 8bits of error check as a minimum to detect / correct just one error, which is nowhere near good enough. In communications "in noisy environments" the likes of "Forward Error Correction" often send twice as many "check bits" as there are "information bits" of data. Importantly the error correction needs to be distributed across the entire information block. But in the case of writting on paper errors tend to group in two dimensions that is if you smudge a letter the eight surrounding it in the 3x3 grid are also likely to be effected thus your error correction should also be two dimensional in effect.

These are practical considerations that would be needed to make a system workable in practice over a period of time.

But sticking with HEX alphabet and 64 letters you are looking at four rows of sixteen letters. So with a 6x8 font size you would be looking at 126x44 grid area with around an 8 size boarder for 142x60 total coverage.

A Rizzler blue is 70mm x 35mm (2.76x1.38in) giving a basic point size of ~0.5mm which would need quite a sharp HB pencil, held upright when using... 0.5mm is usually considered the minimum width lead or nib size in technical drawing propelling pencils and ink pens. Having spent over half of my professional career using them I know why I tend to write in block caps in 10x15 points of 0.5mm as the minimum to be legible over time.

Leave a comment

Allowed HTML: <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre>

Photo of Bruce Schneier by Per Ervland.

Schneier on Security is a personal website. Opinions expressed are not necessarily those of IBM Resilient.