Many keep saying that these attacks are theoretical and weren’t demonstrated until the papers were published. I think it’s more appropriate to say they weren’t publicly demonstrated. One public web site (google it) has a TSCM specialist discussing issues like keeping STU-III secure telephones safe and doing so partly by banning cell phone use nearby. At one point, he mentions that having a specific model of cellphone/service within a certain distance of the device will compromise its key[s] due to the EMF waves it emits. He describes what’s essentially an inadvertant, active EMSEC attack on the STU-III by the cell phone and electromagnetic leakage of the key.

I’d also note two things. First, even the BLACKER A1-class VPN had TEMPEST shielding for the BLACKER Front End devices. They knew, even then, that the hardware and software couldn’t be trusted unless EMSEC attacks were prevented. That was two decades ago. Second, nuclear command and control systems continue to use older methods of building computer boards and networks even when “better” stuff is up for grabs. They cite reliability, but I bet EMSEC has to do with it too. It’s probably easier to prevent passive/active issues on those primitive designs than on a modern SOC. I keep thinking about building a cross-domain guard or something out of *old* technology instead of new. I bet a Chinaman’s salary that it’s easier to secure a good old design than a good new one. And 20Mhz is plenty fast to people who know how to code.

Nick P
Of schneier’s blog infamy

Whilst I remember, a simple experiment for you and anyone else to carry out just to show how easy it is to mistake random and non random behaviour.

Get a D-Type latch and clock it from a XTAL or sig generator.

Get a variable frequency oscilator and put it into the D pin and have a look at the output on an osciliscope.

At first it looks fairly random but then you notice that the envolope of the waveform has nulls at points that are related to the difference frequency between the two oscilators…

If you integrate the output wave form either digitaly with an up/down counter or lowpass filter you get what looks very close to being a sine wave.

My advise to any one making a “roulet wheel” type TRNG is to always always monitor the raw output of the “slicer” / sample and hold / mixer with the likes of a frequency/sequency analyser.

You two should have a chat I can easily see a rather good joint paper out of this

And as I said get a suitably wideband IQ Software Defined Receiver and I think the pair of you could have quite some fun for the next few months.

I have more than good reason to think that “susceptability” and “cross/re-modulation” are going to be the next biggest source of effective side channel attacks.

And it has all sorts of implications for Banks with regards to “security tokens” for EPOS, ATM and iBanking.

Oh and passports you will find that some of the chips in passports can be “enumerated” to the point you can remotly identify the country and date of issue. This makes “ID Shopping” more feasable than it currently is.

Mike.

Ross might remember it was around the time he was looking at non sync logic to trye to get around DPA issues.

Also there was a paper about a month or so before about using a highly focused light source for fault injection (I don’t think it was a laser however).

Unfortunatly I’m back in hospital yet again (problems involving both lack of the red stuff and the red stuff going solid in the wrong places the cure for one is contra indicated by the other), I’ll have a google around, and see if I can find it.

The re-radiation idea is something I’ve worked on, and there’s also a fairly recent paper “The Re-emission Side Channel” by Burnside, Erdogan and Arslan:
http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=4595813
(sadly I can’t find a non-subscription version online)

For using a PRNG, I suppose you need enough entropy to initialise it. Otherwise you can just bruteforce by trying all possible seeds and noting the sequences, assuming you know roughly how far down the sequence you are likely to be.

I agree, though, that there’s relatively little need for MB/s of random bits unless there are further attacks revealed on the PRNGs. And for many protocols even a little entropy is enough once the whitening function is run on top (if you only get 3 tries, you need to know pretty much all the state).

Clive, do you remember any more details of that ‘EMP via “pico probe” fault injection paper’? That would be interesting to read. There’s some mention of the technique in the dependable systems literature but I can’t find anything specific on a quick look.

It takes more work to meet this objective with pseudo random numbers, and I think the implementation would have to be pretty careful (thinking about how we could use some of the last BBS Generator output for creating new random primes that could not be traced back to the original values…). If it can be done securely, it would slows things down even more.

“The bast way to solve this type of problem is to avoid it altogether.”

Definatly, however,

“If the key is created by the device, than have it create the key in a safer place (e.g. factory floor).”

Like most of the older solutions do not work simply due to the “rate of use”. Effectivly you end up with exactly the same problem as key managment for OTP’s.

The real question should be,

“When do we realy need truely random and when will pesudo random do?”

For instance the BBS generator is 100% deterministic but as far as we currently know (on the same assumption as RSA) provably secure.

It uses a couple of very long primes, and they should be “Truely Random”. The downside of the BBS is it’s oh so slow for the number of usable bits.

But does this matter?

Well yes and no.

For instance what if you used the BBS to “perturbe” another much higher speed PRBS such as for arguments sake the RC4 stream generator. There are two easy ways to do this one is add the BBS output (P) into the output byte selection (ie x=Sary[I+J+P]) the other is to use it modify either the I or J pointers used to swap the bytes in the State array (Sary).

However either way is still 100% determanistic so in theory could be worked backwards etc.

However what if you used the principle of “indetrministic sampling”?
That is the RC4 generator and BBS run continuously just as fast as they can in a microprocessor, when an output byte is needed the micro services it via an interupt. As long as the demand for random bytes remains un corelated with the micro then the result will (within limits) be effectivly non determanistic which is kind of the definition of a truely random number sequence.

In essence it is an engineering problem that needs to be guided by sound design principles that correctly account for the (security) issues involved.

And the problem with this is “side channels” in reality all our current crypto algorithms are unbreakable the implementations however are breakable due to “side channels”.

Side channels are in most cases EmSec/TEMPEST attacks. In the case of Theo’s attack it is a “suceptability attack” not an “emmission attack”.

One of the problems is that the engineers who know about “suceptance and emmission” are analog/RF communications engineer’s (more recently EMC engineers as well) and they just do not get asked for their input at an early stage of the design of crypto projects (if at all).

The bast way to solve this type of problem is to avoid it altogether. Luckily most of the practical ways of doing this are already used (perhaps dating back to when protocol designers could not count on having a high quality RNG on the device).

The basic idea is to limit the times you have to use the RNG to points where active attacks are difficult to perform. If the key is created by the device, than have it create the key in a safer place (e.g. factory floor). Yes I know we want to eliminate key depots and the like as much as we can, but typically there has to be some amount of trust in the manufacturing process.

If you need to create random keys as part of a protocol, than bias it so that the host, not the exposed client, generates the key. As mentioned above, this was already a pretty common practice – an expensive HSM contained in a secure facility has a higher level of trust than a $5 smartcard (or an ATM) where attackers have physical access. That won’t solve smartcard-to-terminal issues, but that type of communication does not need true RNG anyway (derived keys, perhaps with a forward-security system could work instead).

I don’t recall financial protocols making much use of a device’s RNG after initialization. Has anyone identified a real attack against a specific protocol?

As you note “injection locking” is well known to (some) electronic design engineers and is the principle behind NTSC and PAL colour osc syncing, 19KHz stereo pilot tone re-generation and thus is in most peoples homes.

Also quite a few early designs of data coms and spread spectrum receivers work this way.

Oh and early frequency synths used banks of crystals that where “pulled” by similar techniques.

I had an Email chat with Ross about it getting on for ten years ago when IR “fault injection” for reading the contents of chip ROM was the latest thing. It was shortly before an EMP via “pico probe” fault injection paper was to be published. Ross suggested I chat to the author in Belgium to check with him.

The work I had done was on electronic wallets such as Mondex that had no RF shielding built in and must have been around 1990, and was based on work I had done several years prior to that on Remote Telematry Units (RTU’s) for the offshore industry to understand the effects of PMR equipment on the CMOS CPU (1802) card.

It turns out that all oscilators (Xtal, CR, LC, etc) can be “pulled” via injection locking. Ian Hicks of Wireless World published a couple of articals on it and the assumption was it was the change in base/gate bias point causing phase modulation to pull the oscillator. However I’m not convinced it is the only effect as there are parasitic effects visable with very low levels of locking signal. In practice a signal level of one tenth the tuned circuit level is sufficient to get a reliable lock.

There was a design going around for a Random Number generator using a lage number of 14Pin DIL pack Xtal Osc’s to get “many jitter sources” around the same time. It exhibited the problem if insufficient decouping on the power lines was used.

When Intel brought out their on chip “roulet wheel” design using an Xtal osc and free running OSC modulated by the noise from a resistor, a few tests showed (from current consumption) that it was quite suceptable.

I guess the only reason it was not obvious at the time was the way they hashed the output.

I’ve designed a few True Random Number Generators (TRNG) in my time and they realy are “sensitive little beasts” that need lots of loving care in feeding and caging.

Most comercial designs I have seen in the past for some reason did not use balanced circuitry in the noise generator or true instrumentation amps. Worse was the slap dash use of RC coupling and analogue to digital conversion (often ordinary TTL Schmitt triggers).

In essence the most sensitive part of the design on whic every thing rested had little or no thought in it and appeared to use either a standard “designers notes” semiconductor noise source or worse. It was often clear that the designer had no idea of what effect filters would have on the output of the noise source… Oh and invariably there would be a “magic entropy normaliser” in the wrong part of the design suggesting that the output without it would not exactly be unbiased…
So if you are ever building or buying a noise based system, make sure you get at the raw output before any “magic entropy normalisers” and run tests on it all the time to look for changes in the output.

Another little trick you might want to look at is square wave modulation onto your carrier signal. This has a habit of traveling quite a way into the logic of a chip and thus might be a way to cause a change in program state without crashing the program.

The question is would it be possible to find a way to sync it to the running program to make it a reliable attack vector, I have a sneaky fealing that the answer is yes.

Then there is the less relevant attack these days (expcept on leads) of “resonating” a conductor to target one specific part of the circuit. A side effect of this is that you can sometimes use it to lift data out.

There was a gambling console I looked at where you could get state information out of it simply by illuminating it from an RF source and looking at the super imposed info on the other side. I did have a look at mounting smart cards in a bit of X-band wave guide and a wide band IQ demodulator. When you get the level right you would be surprised at just how much cross modulation there is…