Schneier on Security

Clive Robinson • April 12, 2017 6:51 AM

@ r,

… kelihos taken down from Alaska.

Not exactly “from” but what looks like a case of “Justice Tourism” by the authorities, looking for a compliant magistrate to sign the paperwork…

This os something we will see much more of in the near future with Internet related activities.

Similar “Justice Tourism” caused considerable concern in the judiciary with the likes of Apple and Samsung over their leagal disputes over copyright etc. It also led to considerable concern that the US Patent and IP protection systems were being abused in ways not intended, rather more than Patent Trolls did as it directly effected economic activity by consumers.

Clive Robinson • April 12, 2017 6:38 PM

@ Thoth, Nick P and other usuall suspects,

You might find this of interest,

https://blog.acolyer.org/2017/04/07/sgxio-generic-trusted-io-path-for-intel-sgx/

It discusses a paper about Intel’s SGX security enclaves and IO channels. Over and above the usual DRM nonsense we get endlessly.

@ Bruce,

One you might want to add to your reading list,

http://dl.acm.org/citation.cfm?id=3029837

It’s a paper from CODASPY17,

“If you can’t beat them, join them: a usability approach to interdependent privacy in cloud applications” by Hamza Harkous & Karl Aberer.

It covers the privacy loss issues of third-party applications available to axcess the likes of Dropbox and Google Drive. Nearly two thirds of these applications request greater privileges than they require. But as the authors show even when the don’t you can still lose a lot of privacy unexpectedly when you colaborate on a document with another person who does use such applications. As a practical step they have come up with the idea of a “Privacy Indicator” that displays extra information to a user when the decide on an application.

Clive Robinson • April 13, 2017 4:49 AM

@ ab praeceptis,

Your link doesn’t work.

Hmm, yup the link is correct if you do the %xx conversion back to an ASCII char… Sorry I missed it last night (trouble with being unwell yet again and during the holls).

For those who do not have a HEX-ASCII converter/chart to hand, try,

http://dl.acm.org/citation.cfm?id=3029836&CFID=740755237&CFTOKEN=24369842

With regards,

And I’m afraid that you became a victim of a form of academic clickbait.

Yes and No,

The paper was vetted not just by the ACM usual rules but also by the CODASPY17 paper vetting pannel.

Is the paper weak, by my own experience “yes”, but… academic papers on “Fault Injection Attacks” usually are. Also being as rare as “hens teeth” as well (see the papers citation list and you have about two thirds of the ones I know of in there).

As I noted they did a simulation of the AMD chip because the chips were not on the market. So as the paper belabors they based the simulation on the past year or so of AMDs released paperwork.

Importantly however the thing about nearly all active fault injection attacks is the “that’s bleeding obvious” response you get when you tell people. However no matter “how obvious” it is to them afterwards, they did not see it befor hand in every case I’ve found in the past. Thus they made no attempt to mitigate such attacks in their designs, which makes them vulnerable.

The thing is Cache timing attacks have been known for a couple of decades now “academicaly” and longer in the engineering community along with other fault injection attacks since atleast the 1980’s. Yet they keep appearing in new designs as do many other active falt injection attacks. The AES competition in 1988 and the resulting published code being the classic example of the cache timing problem visable across a network. Which still plagues us today over a decade and a half later and will probably continue to do so for another decade or three (I still blaim the NSA as NISTs advisors for this issue as they would certainly have known not just about cache timming issues prior to the competition starting but time based side channels in general, but they said nothing…).

I have explained a number of times on this blog and other places about why fault injection attacks work so easily with devastating effect[1]. But still they get designed in “With nary a thought” in new products year after year, presumably much to the delight of SigInt agencies around the world.

I suspect the late Douglas Adams was well aware of the cause of such problems with his joke –back in the late 1970’s– about the “Somebody elses problem field” that whilst it did not make things invisible, it stopped people seeing them for what they are.

And it’s not just me seeing this connection, whilst chatting to someone from the UK’s Cambridge Computer labs a while back, I mentioned the issue, and they told me that one of the Reader’s there, Prof. Alan F. Blackwell “also has the same bee in his bonnet” over the SEP issue.

I guess at the end of the day active fault injection attack mitigation is a question of “problem ownership” when products are implemented. The theoretical guys say “no problem with the algorithm”, the software guys just cut the code to “reduce the overhead” and the test guys “don’t have test software” that can check for it. So it drops through the crack that is “implementation issues” that in reality is so vast it makes the Grand Canyon look like a “shake in a piece of wood” in comparison.

Our host @Bruce once wrote a book about implementing crypto in practical systems with Niels Furguson (Cryptography Engineering). It’s been a good few years since I read it, but I don’t remember anything specific about this issue, hopefully he will correct me if I’m wrong.

And likewise most other books on cryptography code cutters are likely to read never mention time based side channels let alone active fault injection attacks…

[1] Just search for “efficiency-v-security” or “clock the inputs and clock the outputs” and “fail hard and long on error” which explain the “system transparancy” problem and why such things as standard error correction techniques become active fault injection attacks.

Clive Robinson • April 13, 2017 5:29 AM

@ John Gault,

SO…. you don’t think your computer with your antimalware software is slow enough, yet?

I wouldn’t know, I don’t have antimalware “bloatware” on the majority of them, and the one that does has all sorts of non-standard antimalware running on it and is quite an old machine (no Flash ROM and runs from a CDROM not a hard drive).

I should mention at this point the computers are “hard gapped” because many run very old OS’s going back to MSDOS 5 because I still have to support some people who run my code in industrial control and CAD/CAM systems, talking to even older Vaxen etc. I keep telling them that they need to upgrade, and even “Listen guys that hardware and me are both going to die one day” does not appear to move some of them.

Speaking of old computers like the TRS80, I was asked to sort out an Acorn Atom that had an intermitant fault a kittle while back. Turned out the electrolytic caps had gone dry and thus had lost capacitance and gained ESR. Sadly they were not old enough to “regenerate” so I swapped all of them with new ones that looked sufficiently retro, and problem solved, so it could go back on display. It’s fun to see kids eyes open wide to the computer games etc of those 80’s home computers whilst some of the older dad’s get a little misty eyed.

Another problem with keeping them going is televisions… Yup they are now all “high def DTV” and you’ld be hard pressed to find a computer monitor that will take the input of old PAL or NTSC video.

So as the old saying has it “All good things must come to an end”… I guess even my white Apple sweat shirt from 82 will someday fade even though it’s kept out of the light.

Clive Robinson • April 14, 2017 12:36 PM

@ r,

With regards,

researchers develop master fingerprints that can break into smartphones

Fingerprints are only presumed to be unique, just like snow flakes. However that does not preclude matches, especially when you take metrology into account.

How you measure, and to what accuracy is important. If for instance you look at a banknote made with organic material (paper/cloth) under a microscope you can see the fibers, the patterns of these are likewise presumed to be unique. However to do the comparison between a hundred thousand or more banknotes at that level of magnification requires a quantity of data that few of us could comprend in real terms.

As you pull back on the magnification two things happen to the measurment. Firstly the resolution of the fibers goes down and secondly the uncertainty goes up due to both sampling and noise. The upside though is the level of data drops significantly. Pull out further and the fibers are not visable, however by shadowing etc the still produce discerable features depending on the angle of lighting, the same happens with the bank not inks, this is sometimes used as a security feature. Eventually you get to the equivelent of a foot or so from your face, where you can only resolve to about one part in two thousand or about two one hundreths of a square millimeter. Which is good enough to see the finer print details but not without much ability to compare between notes.

Fingerprints suffer from the same problem, as well as a whole lot worse due to the crap we pick up on them that would also get spread over the sensor. Thus the actual details used are not very fine, thus the quantitisation is low and thus the chances of getting a false positive is way way higher than you might expect.

In some early systems I worked on (and got fired over showing how to fake fingerprints with less than a dollars worth of common household items) you would get false positives in groups of less than a hundred people…

So I’m not surprised that this problem has arisen.

Clive Robinson • April 14, 2017 1:30 PM

@ Dirk Praet,

You can still play all of these classic games on your TV with Retropie and a Raspberry Pi or ODroid C1/C2.

You can, but you don’t want to fake a historic exhibit unless you have to.

As for the Raspberry Pi they get to play with those further down.