Schneier on Security

Clive Robinson • August 31, 2018 12:14 PM

@ Alejandro,

find that old cheap external microphone you never use anymore, cut off everything except the male jack portion and then plug that in to the computer, and leave it in. That will turn off the mic. regardless of any electronic wizardry.

Sorry no not these days, many computers nolonger use mechanical switches in the jack pair connector as it cuts down noise and considerably ups the reliability.

Thus the internal mic is hardwired into the chip, and software is what turns it off.

Clive Robinson • September 1, 2018 8:05 AM

@ echo,

This isn’t the clearest explanation of “ghost images”.

The diagram in the article you link to reminds me of those you used to see explaining holograms.

They two use seperate beams (although split from a single source). Aproximately they worked by taking a refrence beam and a reflected beam then producing an “interferance refrence” at the photo gel. You then played it back using another refrence beam that did not have to be the same frequency or in some way cohearent with the original refrence beam.

In effect the photo plate when developed had a complex transform embedded on it, that to most views without the refrence beam was vague or random mess.

I think it’s time for a little more digging and thinking 😉

Clive Robinson • September 1, 2018 8:03 PM

@ echo,

I only just heard of quantum information theory yesterday.

So you’ve not got the “Bloch sphere” under your belt then 😉

If you want something to realy drop your jaw, have a look at Seth Lloyd over at MIT, he has a fair argument the whole universe is a quantum computer, but nobody knows –or could no– for what purpose.

An interesting little thought for you. Information is not of the physical universe quantum teleportation tells us this. We simply impress/modulate information onto physical universe objects such as matter and energy, to store, communicate, and process it. The implication is that our physical universe is a subset of an information space of some kind, where the laws of physics do not of necessity apply. But also our physical universe is finite and thus only a very limited subset of what is knowable will be known at any one time.

It’s thoughts along these lines a hundred or so years ago that drove mathmeticians not just mad but as one eminent physicist only half jokingly said “bat shit insane”…

Clive Robinson • September 2, 2018 6:16 AM

@ echo,

Sorry a nights sleep intruded in my reply (they tell me it happens to everyone 😉

With regards,

I have no idea what you are up to but it sounds intriguing.

I’m upto many things, some dull some interesting, some I can’t talk about or talk about currently whilst others I can. But at all times I’m curious about things that are new. That is part of what I do all the time is research into the viability of the new in fields of endevor the originators might not have thought of.

Mostly these days the research I do is in my own time[1] and is about using or mittigating the very new for security purposes. Usually from a bottom up approach using external communications technology or other energy source to do Active EmSec Attacks.

What most forget is the usuall solution to security issues is much like that of Victorian artifisers. Which is the “We will make it stronger by design” PR sound bite of the reality of

Bolt another bit on till the bl@@dy thing stops breaking and just get a bigger horse to drag it to market.

That is don’t find out why it’s breaking just glue/weld stuff over the cracks and cross your fingers.

Such an aproach is almost always “top down” thus does not fix “bottom up” attacks.

Also what most forget is that almost always at low level the movment of information is not one way due to the likes of handshaking and error correction. Software writers are notorious for how they handle “errors and exceptions” from the right… That is down stream functions, processes and devices. Likewise unexpected input from the left especially when it is assumed to be another process not a user…

Which means injecting faults is a happy hunting ground for attackers. Whilst the industry is slowely waking up to input side faults, they are still sleepwalking on the output side faults… So any “bubbling up” or “bottom up” attack is going to be quite devastating. As @Thoth indicated “the usual suspects” here have been talking about the problem for quite a long time and it is only now with Meltdown and Spector being reported even in the MSM that people are waking up.

As @Thoth has pointed out Security Enclaves are a bit of a problem.

The real reason for this is that they use the main memory just as every other process does. At the memory level there is generally no protection of process space as at that level it has no meaning what so ever. It’s just address bus and data bus and a control bus designed to have as few gates as possible to get maximum speed of response.

It’s been known for multiple decades that anything with that bus level access can do as it pleases, thus Direct Memmory Access (DMA) is a major system integrity risk. Unfortunately trying to get high communications transfer speeds and bandwidth with low latency response more or less predicates the use of DMA…

If you look back at Apples Firewire interface and Intels later lightPeak designed to replace it which later still became ThunderBolt they all provide DMA intetfaces to the outside world on conbectors. So pluging in a malicious device to give a simple “bubbling up” attack whilst not childs play to develop realy is childs play to deploy…

The same is true of other high bandwidth low latence comms. Even USB suffers from similar DMA issues but with it’s own interface CPU.

There is no top down soloution to these types of “bubling up” attacks because software works much further up the computing stack. Thus it does not matter a tinkers cuss what you do in the way of formal methods, provably correct by design etc, they can not stop DMA changing the process memory. Only correctly configured hardware can do that IF AND ONLY IF it has the capability built in from day zero.

But it gets better, once you know the basic security fault behind DMA and you know how the extra hardware protection is configured by the OS software, it’s simple to realise if you can change the configutation you change the security. Thus you can turn security off to gain access to a protected processes memory or you can turn security on to a process such that it can not access the memory resources it needs to function…

Well guess what you can… You can actually perform an attack at a lower level in the computing stack than the memory interface level… Due to issues in the design of high density memory chips it’s possible to attack them not at the gate level but even lower still at the basic storage component (capacitor) level… The fact you can do this from software is more than a bit devistating and you can look it up as the RowHammer attack. It requires fairly major hardware changes to fix but there are some OS mitigations that limit it’s potential, but there are Systems Performance Issues…

But RowHammer is just one instance of a whole class of “Reach Around” attacks in this case a “reach down” subclass. Meltdown and Spector are other reach around attacks but there are more, many more and the vague fiddling Intel, AMD, ARM, and others are doing will not solve the issue of this class of attack, at best they will mitigate an instance or two with a significant system performance hit which will accumulate for each mitigation…

So you can see the potential of all such bottom up attacks be they “reach around” from malware or “bubbling up” from malicious hardware.

But… My favourit areas of research are ones you don’t hear very much about in “The Open or Academic Communities” in fact next to nothing[3]. They are mainly Active EmSec attacks not passive, where by you get a signal in at the basic electronic component level that takes advantage of fundemental analog problems such as metastability to cause execution to diverge from the designers intention. The routes in are many and I’ve described a few in the past. But two simple to exploit ones are due to “System Transparancy” issues,

The first is time delay or jitter, whereby you hide a time based signal on top of a valid input signal. Even though the system may change the input the time signal is still seen on the output. The classic example is keyboard data goes into the system as valid looking key presses which then gets wrapped up in network packets for originally Telnet but later SSH etc remote terminal access. Thus the timing data ends up being transfered onto the network packets irrespective of any encryption etc. But… because the system will alow other processes to connect to “stdin” an application can be inserted into the input stream of any existing service alowed to run. Thus the app could be a generator or an input Tee acting as a modulator to an existing stream, sending out confidential information in the timing…

The second transparency issue goes in the opposite direction, that is from the output back through the system to the target of interest. You will not find this talked about, I guess because few even think it’s possible. Unfortunately for them and many others it is and it quite happily works bakwards through data diodes and other supposed one way protection devices. At a low level systems are generally designed by people who have trained as electronic or communications engineers thus are, unlike most software coders, aware that there are realities in life such as line noise and disrupted communications. In short they know things are inherently unreliable and that you need to employ multiple levels of error correction in the right ways. The most obvious to look up is “flow control” that is a transmitting source also has a receiving flow control port you can see an early example in the old RS232 CTS/RTS signals [4]. A terminal (DTE) sends data to a modem (DCE) but for various reasons the modem may not be able to process data at the rate the terminal sends it at. Thus the modem uses a control line output (DCE-CTS out) to a control line input on the terminal (DTE-CTS in) to tell it to pause in transmission. Thus data will wait at the DTE filling it’s serial port device driver buffer such that it sends an error signal back to the process connected to it and so on backwards up the transmission chain. Eventually when buffers are full the generating process gets the error signal as an exception and has to deal with it. Due to the way many coders think and write software it might send an error message to the error log before crashing out. Due to the way modern computer caches work other processes can find out the error status thus have a covert channel back to them most would never have thought to check for… Likewise due to the way network switches and ports work you can do similar, which is why even Data Diodes are vulnerable to this reverse error/exception timing covert communications channel. Oddly though the software coders should be aware of not just system transparancy but reverse communications are, if they know what “Port Knocking” is[5]. It makes a good question when interviewing.

Anyway I hope that answers your question without me having to go into specifics.

[1] One of the major issues these days I’m guessing you are probavly aware of is “employer over reach” in some form or another. One aspect of is if an employee comes up with an original idea and even if entirely unrelated to the emoloyers activities and done entirely in the employees own unpaid time with entirely the employees own resources the employer will lay claim to it[2]. Even “zero hour” supposadly “self employed gigs” come with a “we grab it all clause”.

[2] There have been many reasons for employers attacking employees over their creativity or IP. Mostly it’s not about going on and using the IP but stoping it being used to protect the often exemployer’s rice bowl or other employers rice bowl. In the same way patents are frequently used. But employees can be unaware it is also directed at them. The Silicon Valley employers deliberately not employing from other Silicon Valley employeers was not about the noise they made of potential legal issues, but an illegal cartel designed to drive and keep wages down.

[3] One of the reasons you do not hear very much about it goes back to the end of the last centure and research into attacks on Smart Cards. The idea of “Power Supply Noise Analysis” came up again after a nearly a couple of decades, as a way to detect a CPU’s internal function thus how it behaved in things like crypto algorithms that could and did leak KeyMat information easily to the outside world… Well the smart card industry did the usual top down approach to in effect mask the noise in random data. But as any communications engineer will tell you that approach is doomed to failure if the algorithm is run repratedly and the signal averaged. What happens is the wanted signal adds up and the random noise averages out towards zero, so you get back to where you were before the madking technology was bolted on. Well a person who decided to publish what was openly known in the communication engineering community gave it the name “Differential Power Analysis” and grabbed a bit of fame with it, which is fair enough. But what he also did was seek and gain overly broad patents in the US (you can only do it in the US). But the result was a “major chilling effect” on the various communities on what is or should be basic research and thus exempt from patent issues. You can be sure that research is on going in commercial entities but as they will want to access the US market they simply say nothing about it outside of select internal groups. Which is just one reason I have no intention of visiting the US again and thus am happy to talk about it in my personal capacity to make the issues more widely known.

[4] Although most call it “RS232 hardware signalling” it’s actually the TIA-232-F 1997 Rev 2012 interface specification that is current. What is worse, is it’s probably the most abused data communications specification for single user compiters ever. Thus it involves one heck of a lot of “magic thinking” to get it to work, and yes books have been writen about it (I wrote one back at the birth of the UK 8bit Home Computer revelotion, and although I got the miniscule advance the publisher joined that great big publishing house in the sky and closed it’s doors befor it got around to getting the draft let alone publishing it).

[5] our host @Bruce wrote briefly on port knocking getting on for a decade and a half ago,

https://www.schneier.com/crypto-gram/archives/2004/0315.html#5

I’m thinking it’s time he wrote an update about it, but this time including the risks as a covert communications channel for attackers 😉

Clive Robinson • September 5, 2018 6:29 AM

@ vas pup, Alejandro, me,

Should small audio jammer placed next to PC/smart phone do the job, i.e. mic is still working as you suggested, but can’t extract useful information?

The answer is the mic will always extract the information around it. All you are effectively doing is adding a lot of noise to the desired signal.

This is the mistake they made with smart cards and power analysis, which became obvious with Differential Power Analysis (DPA) back last century.

With DPA you simply keep adding aligned trace after aligned trace thus the wanted signal goes up by n but as the noise is random it goes down by sqrt(n). With enough aligned samples the noise is effectively striped of and other signal processing meyhods then applied to recover the wanted signal and determin the wanted key bits.

With an external source you need to get a second signal with a different aplitude differential between the desired signal and the jamma signal. By making the desired phase and amplitude correction it enables you to add the two together to eliminate the jamming signal and recover the underlying audio.

It’s why proffessional surveillance people always try and get two fairly widely spaced audio signals when ever possible.

The same technique can be used effectively in reverse to detect GPS jamming with a synthetic or translocated signal.