New paper: “A Simple Power Analysis Attack on the Twofish Key Schedule.” This shouldn’t be a surprise; these attacks are devastating if you don’t take steps to mitigate them.
The general issue is if an attacker has physical control of the computer performing the encryption, it is very hard to secure the encryption inside the computer. I wrote a paper about this back in 1999.
Clive Robinson • January 12, 2017 7:51 AM
@ Bruce,
The general issue is if an attacker has physical control of the computer performing the encryption, it is very hard to secure the encryption inside the computer.
Sorry, the world has very definitely moved on this century.
You nolonger need physical access let alone physical control.
The power usage is never 100% efficient. Which means the excess power has to go somewhere untill it eventually becomes heat by radiation transport etc. Even as heat the channel the energy is in had a bandwidth, it it’s wide enough it will carry out information with it. This is one of the basic ideas behind TEMPEST.
However you can –as I keep pointing out– do better, you can illuminate the device with an EM or other coherent energy signal including vibration that gets cross modulated and reradiated carrying information with it.
But it also works the other way. Electronics are susceptible to external energy it’s part of what EMC is all about. What for some reason is not commonly acknowledged is that the external energy can carry information in and impresse it onto signals within the electronics. The lower power or voltage the electronics uses the easier this is to do. We even get it demonstrated to us when we put a GSM mobile phone near a system with an audio amplifier in it, you can hear the “envelop” of the GSM signal super imposed on the audio going through the amplifier.
I’ve mentioned on this blog a number of times more of the details but it’s the reason I say that “air gapping” is nolonger secure you have to use “energy gapping”.
Actually making an effective energy gap is actually quite difficult and due to cost and physical considerations such as size and mass it is very rarely done.
@Clive,
I don’t think energy gapping is as impossible as you make it sound, maybe in a traditional air-cooled setup sure but certain thermal solutions should be able to dampen emissions in that respect fairly evenly.
Especially where you start to move into miniaturization.
mineral oil, lead – they’re both reasonably sourced – containerizing your apparatii cannot be that unattainable.
MASS v PORTABILITY is the only problem I see, but I’m a layman and eat up your every word otherwise.
Andrew • January 12, 2017 8:06 AM
At the practical level, if an attacker controls your computer its pretty much game over. He takes the data (plain text) or passwords and make the whole computer even more vulnerable. The encryption keys may be the last concern. Sometimes I wonder if some cryptographers ever seen some hackers tools.
I don’t think there was a single case in the recent global hacks where they broke the encryption. The main concern today should be end points security, not cryptography.
For example if you’re a state target these days, they get in through software updates or OS backdoors, duplicate your data and disappear without a trace. If you’re a hackers target, they get in through social engineering, emails, browser, open ports etc.
There is this wrong focus in protecting compromised systems which lead to a false sense of security. Securing a computer while the attacker escalated the privileges is pretty much waste of time. Some other things should be in focus, like detection, cutting communication and prevent data exfiltration etc.
Andrew • January 12, 2017 8:16 AM
Now I see that Bruce said “physical control” of the computer…
Clive Robinson • January 12, 2017 8:16 AM
@ Poul-Henning Kamp,
If the attacker has physical control of the computer, even if only temporarily, you don’t know what hardware your program is running on in the first place.
Actually if you think about Intel and AMD with their managment engines and ability to update the CPU etc microcode. The damage is already done before the “computer” is even built… Worse they can use other aspects of the modern PC to make the changes remotely when they feel like it. Whilst not an example of using the managment engine, Lenovo showed with the nasties they put in the BIOS that this is more than easily a consideration.
The problem is supply chain poisoning can occur at all levels of the computing stack, thus it’s not possible to stop in commodity computers the majority use all the time.
As it’s not possible to prevent supply chain poisoning for mear mortals, or those who do not 100% control the entire production process from the Fab upwards your only two choices are to mitigate it or not play.
It’s something that has been discussed on this blog in some considerable depth before, usually towards the bottom of threads.
You can find it by searching for my name, Nick P, RobertT, Wael, Figureitout, Thoth with the first names being in the discussions since the begining.
Wael usually comes up with links if you ask him to, as I think he’s bookmarked a few for refrence. Then there is Nick P and his “link farm”.
Thoth • January 12, 2017 8:53 AM
@Bruce Schneier, all
Not sure if you have ever heard of Whitebox Crypto and many other variants at improved Whiteboxes, DPA and SPA Protection from CRI and all that and TEMPEST as well. Those are one of the many many ways to mitigate whatever power analysis can throw at.
Also, there are many solutions in the Security and Defense industry that supplies security solutions for remote machines which provide tamper resistance from physical tampering as well and there is also secret sharing schemes to protect master keys that are loaded onto tamper resisting security processors with the master keys stored in battery-backed SRAM to deter many types of intrusive measures at acquiring the master keys stored in BBSRAM.
One example are EMV payment mPOS with BBSRAM protected EMV keys with tamper meshes and all sorts of glitch, voltage and temperature sensing triggers laced throughout a decently protected mPOS. There are attacks showing that they can break into these mPOS but those attacks are very expensive and the better choice as most card scammers have figured out is to simply hide mini cameras on PINpads, shim the weakly protected cards or hack into the unprotected application processor running the Windows XP OS and cause the glitches they want and simply sidestep much of the attacks against the crypto processors since it’s too expensive to go down the route of attacking crypto processors when the low hanging fruits are the weak OS security for the application processor and so on.
There is a whole ton of interesting technology to explore but the problem is most people are too conceited to the standard Windows, Linux and Mac with the usual Intel or AMD processor when given the choice to use something like smart cards or Ledger devices that have input and screen attached to the devices. The excuses per usual are either they are too esoteric or not easily available but the truth is much different with standards like GlobalPlatform and even with APIs and codes left in the open for use.
Whoever uses a software protected key on the usual OSes and insecure setup is asking for trouble. As @Clive Robinson have mentioned, search our names and there is a ton of discussion we have already put in place and some of us have active projects in place while others have link farms for scholarly references and some have tonnes of experience to give advise to us.
The answers to lots of security woes is a couple of search away. We have given a lot here already.
Winter • January 12, 2017 8:55 AM
When I come here to read about the latest security threat, it is always comforting to learn that there is nothing I can do. So I should simply stop worrying and give up.
That saves me so much time and effort.
Clive Robinson • January 12, 2017 8:57 AM
@ r,
I don’t think energy gapping is as impossible as you make it sound,…
It’s not just thermal energy it’s all energy mechanical, acoustic, EM, even what you might call gravity changes.
To be usefull even issolated systems have to have the ability to get power and information in and out. Which means you kind of have to shield the operator inside with the computer. Hence the fondness of SCIF[1] tents/rooms.
[1] The full design of Sensitive Compartmented Information Facility (SCIF) systems is sort of secret, but you can get an idea of the general construction from, https://www.ncsc.gov/publications/policy/docs/ICS_705-1_Physical_and_Technical_Security_Standards_for_Sensitive_Compartmented_Information_Facilities.pdf
Don’t make the mistake of thinking they are just faraday shields, additionaly they have sound proofing, IR proofing electrical and signal filtering and often heavily damped floors walls and ceilings to prevent energy being “conducted out” rather than radiated. As far as I’m aware, they don’t yet have neutron[2] sheilding as a design requirment but you never know 😉
[2] Neutron tomography[3] is interesting, in that from a 20,000ft view it appears to work the opposit way to X-Rays. That is metal and the like are more transparent than organic materials. It’s why you can use it to see water boiling in a kettle, fuel flow and burn in running engines etc. Oh and humans moving around –all be it briefly– inside a tin box etc 😉
Clive Robinson • January 12, 2017 9:37 AM
@ Winter,
When I come here to read about the latest security threat, it is always comforting to learn that there is nothing I can do.
Stop being such an optomist 😉
Actually there are many things you can do to mitigate the situation.
Much though cryptographers hate them One Time Pads/Phrases do work and the technology is “pencil and paper” level to use with well tried and tested “field craft” OpSec. That way you mitigate the communications “electronics” problems in one go “Easy”…
But you still have to make the pads etc, which means you are according to most “just moving the problem”… Which whilst true is actually not so much of an issue because you can plan and prepare for it in a non urgent / panicy way…
Also the thing is that OTPs don’t need to be made oh so slowly with a couple of dice, you can make CS-DRNGs out of crypto algorithms. Because it’s not the algorithms that are broken, but the systems they run on.
Thus the reality is the hard part is running the algorithms and getting the OTPs printed out securely. But you only need do it once a year or other long time period not every time you communicate.
So with a little thought you can infact do this reasonably securely without using a PC if you just happen to have an old printer with a parallel or serial interface. You could use an untrusted Raspberry Pi or similar SBC in a suitable enclosure, but that still leaves the problem of the printer.
So… you could of course put the printer, a computer and a high capacity UPS into a fire proof safe of sufficient size with a few additions such as cork tiles etc. Set it up so that you turn on the printer alow it to warm up etc, and boot up the computer and auto run a program which reads the startup values out of a file on a floppy disk etc, as the computer starts to boot pull out the kettle lead from the UPS and shut and lock the safe door. Sit there and have a coffee or two, then when you’ve alowed enough time open the safe and lift out the printed OTPs colate punch/staple put in secured envelops and put in a security safe, whilst printing out a few very complex image files to clear any memory in the printer.
Wael • January 12, 2017 9:48 AM
@Clive Robinson, @Poul-Henning Kamp,
usually comes up with links if you ask him to, as I think he’s bookmarked a few for refrence
Ask and you shall receive! I seldom bookmark things; I just remember some keywords. Nice neutron tomography info…
@Thoth,
Not sure if you have ever heard of Whitebox Crypto and many other variants at improved Whiteboxes,
It’s very unlikely he’s heard of it. It must come as complete revelation to him 😉
Trent • January 12, 2017 9:48 AM
@Poul-Henning Kamp
If the attacker has physical control of the computer, even if only temporarily, you don’t know what hardware your program is running on in the first place.
And the computer you purchased from some kind of vendor who assembled it off-site from components manufactured at other different sites, right?
Compromising manufacturing / assembly / delivery is one of the vectors specifically addressed in the TAO that’s already been discussed at length a while back on this blog.
@Andrew
I don’t think there was a single case in the recent global hacks where they broke the encryption. The main concern today should be end points security, not cryptography.
There was the NSA / NIST elliptic curve backdoor thing. Wasn’t there something else about a SSH vulnerability because someone had taken the time to effectively rainbow table the factorisations of a few very large primes disproportionately widely used in the handshakes?
But yes, most of the recent high profile “hacks”, publicly available information indicates endpoints rather than cryptography weaknesses. But then, if an investigation relied on information obtained through say, a SHA backdoor known only to some cooperating agency then no, we’re never gonna hear about that information source.
Nick P • January 12, 2017 9:52 AM
@ PHK
That’s not true in practice. There’s quite a few threat models where the attacker lacks the competence or time to defeat or clone the hardware. The low end of this is a screen lock where layperson snoops can’t get in. The middle end is higher-end smartcards. The high end is a HSM where even admin or support people might not be able to do specific things without a key wipe.
Jack D. Ripper • January 12, 2017 10:40 AM
@Winter
Don’t give up! Stop worrying and learn to love the logic bomb 😉
Dirk Praet • January 12, 2017 10:50 AM
@ Thoth
There is a whole ton of interesting technology to explore but the problem is most people are too conceited to the standard Windows, Linux and Mac …
Yes and no. It all depends on your threat model. While all three are a lost cause when up against state actors, there is still plenty of ways to efficiently mitigate against script kiddies, cyber criminals, data harvesters and the local sheriff’s office. Which is probably along the 99% mark of the general population, at least over here in Western Europe.
In my experience, it is utterly pointless to even try and convince the average individual or SMB of more secure alternatives unless they have a serious incentive/business case to do so, and in which case they will call themselves.
The answers to lots of security woes is a couple of search away. We have given a lot here already.
We really should at some point consider bringing some of that stuff together in a practical how-to guide here on this site.
robinsonfacts • January 12, 2017 10:57 AM
Clive Robinson can bit-bang random numbers onto floppy disks just by passing his electromagnetic hand over them.
vas pup • January 12, 2017 11:48 AM
!!!URGENT:
Rudy Giuliani to lead Trump’s cyber security team:
http://www.bbc.com/news/world-us-canada-38600075
Slime Mold with Mustard • January 12, 2017 12:18 PM
@Clive Robinson
Damn it Clive, when you tell me I need to muon shield this office, you’ll get a transuranic response. London? Close only counts with…
Ted • January 12, 2017 1:01 PM
One of the two co-authors of the Twofish Key Schedule SPA paper, Jose Javier González Ortiz, also co-authored an earlier paper: “Heart Sound Classification Based on Temporal Alignment Techniques</a href>”
Abstract: The ability to accurately stratify patients at risk of adverse cardiovascular outcomes using heart sound recordings could result in earlier treatment and improved patient outcomes. […]
Jennifer Gold Stockholm • January 14, 2017 8:29 PM
@ Clive Robinson can bit-bang random numbers onto floppy disks just by passing his electromagnetic hand over them.
thats actually really funny when considered in the context of the Chuck Norris scope of jokes.
We should have a thread of similar jokes for @ Clive – he is definitely deserving
I’ll start by paraphrasing a Chuck Norris joke
“When Alexander Bell invented the telephone, there were 9 missed calls from Clive Robinson “
Wael • January 14, 2017 9:04 PM
@Clive Robinson designed the security system for king Khufu.
Art • January 20, 2017 9:35 AM
There is no valid reason to use Twofish over AES. AES is supported by all modern CPUs which not only makes it way more faster, but constant time too, with no lookup tables, which protects it against all kinds of timing attacks. Twofish has more lookup tables even more than AES with no hardware support. Stick with AES as it has been tested for almost 20 years with no known practical attacks.
ab praeceptis • January 20, 2017 6:38 PM
I’m somewhat suprised by Bruce Schneiers rather shallow statement. And unlike some others I think that PHK made a smart remark summarizing thing quite nicely (if not completely, but then, who achieves that anyway?).
But yes, of course, one is right to highlight that with the vast majority of todays systems one doesn’t know much about ones hardware anyway. And that’s not even the usual nsa “delivery” hint but more serious: Even the manufacturers don’t know sometimes; the chips, even complete modules (e.g. bmc), and lots of code come from diverse third parties.
And so quite some comments actually focussed (justifiably) on the context and not one the 2fish attack itself.
Concerning 2fish itself, or more generally, crypto formerly one had basically one guideline, namely that the algorithm must be sound and that it must hence withstand the best attacks peers could come up with.
Today another factor entered the game, namely that an algorithm should be designed and/or at least implementable and implemented in such way that it defends itself well against a plethora of context attacks (e.g. timing, power).
I hereby posit one more criterion: We will need algorithms, not only but particularly in crypto, that carry proof of properly running (Pardon my poort english. I’d love to express it better).
One major deliverable in that regard will be the generation of proof that the algorithm/context combination perform as specified.
While this increasingly vital challenge might look inconspiciously simple at first glance it actually is a very tough nut. The major reason being that it’s not good enough to (as one might imagine the proof) to show proof for e.g. a number of messages and ciphertext – that could be faked by a cleverly mischievous context (e.g. cpu). One will need more. One way I see is to a) throw randomly chosen messages at the mechanism and b) to have or generate references to compare against.
A next step might be to proactively consider the contexts; an x86 works differently – also in respect to e.g. timing attacks – than say, a sparc cpu.
Until we have that, and I don’t expect it anytime soon, we will be well advised to tackle the problems from the other side, namely by chosing simple contexts, i.e. simple sytems with minimal firmware, minimal – and tightly controlled – i/o, sram rather than dram (which opens attack vectors by itself), 1 level of cache only, etc.
And while making the whole thing as tamper proof as any feasible is important and helpful it does not deliver by itself alone.
Which leads me to Thoth and his project. I’m sometimes not too excited for different reasons, some of them rather subjective (e.g. java, javacard) but nevertheless I think Thoth should be praised and supported because he clearly has understood the nature and urgency of the problem class as well as the general direction to go.
In particular I see the chance to get at a widely available reference device that would allow its users to serve as the external reference I talked about above. Alternatively such a device you serve to offload at least some critical crypto.
A short note for those who think that we don’t need 2fish anyway as we have aes. I don’t agree. Aes is nist and nist is to be regarded as nsa. If asked to trust either Bruce Schneier or the nsa I don’t need even a full second to think about it.
gary • February 6, 2017 1:52 PM
anyone have a simple countermeasure to this ? for the average pc setup
Subscribe to comments on this entry
Sidebar photo of Bruce Schneier by Joe MacInnis.
Poul-Henning Kamp • January 12, 2017 6:46 AM
I would argue that today there is an even more fundamental threat model here:
If the attacker has physical control of the computer, even if only temporarily, you don’t know what hardware your program is running on in the first place.