Schneier on Security

Clive Robinson • September 18, 2011 1:33 PM

@ Gabriel,

“I only [know] enough about these to be dangerous, so I’m interested in hearing what an expert such as Bruce would say”

I’m not sure you will find anybody who would willingly call themselves an “expert” in the area of Hardware Non-determanistic Random Bit Generators.

I’ve dabbled in designing what you would describes as HW-NRBG peripherals (but we used to call them TRNG for True Random Number Generators and PRNG for Pseudo Random Number Generators depending on what part we were designing).

For a TRNG you are effectivly looking to use something most engineers go to very very long lengths to get rid of which is “noise”. The problem is there are more types of noise than you would beleive and they all have a significant problem which is they have “charecteristics” that enable you to identify them in some way…

What you don’t want in a Crypto-RNG is any kind of distinguishable “characteristics” as these (in theory) alow predictability.

The other problem with “noise” is where it actually comes from and how you get it to a usable level. In electronics the most oftern used source of noise is thermal noise from a passive resistance and it has a very very low level which you need to amplify to a usable level.

The problem is all amplifiers generate noise as a function of their operation and even in a good quality carefully designed amplifier this is comparable in level to the thermal noise signal you are trying to use.

This amplifier noise comes from many different sources and each has fairly well defined characteristics which you don’t want polluting your desired thermal noise signal. But you can not avoid it, and the issue then becomes how do you make your desired noise source dominate over the unwanted noise of your amplifier.

The simple answer is by selecting only some of the output signal using filters, and as any RF engineer will tell you no filter works from DC-Daylight. That is a lowpass filter will at some point become a high pass filter and vice-versa, likewise band reject become band accept etc etc, so in reality all filters are aproximations with their own characteristics which will end up superimposed on your desired noise signal…

But there is a dirty little secret engineers don’t much talk about which is, “is noise addative or multiplitive or both?” when it comes to the real world of nearly but not quite linear circuit design.

Thus much of the design work in a TRNG is mitigation of the circuit characteristics following the actual noise source, a substantial part of which is ensuring that you don’t get external signals injected into the TRNG. This can be via inputs for the powersupply or outputs, or from other parts of the circuit. As any RF engineer will tell you “Oscillators don’t and Amplifiers do”. All amplifiers are unstable at some point in their characteristic and the amplified input signal at the output feeds back into the input circuit sometimes as negitive feed back and sometimes as positive feedback.

All of which has made life a bit difficult for TRNG designers in the past…

However… buried deep within the quantum world of the silicon chip there are interesting structures to be found some of which some people claim can be utilised to make TRNGs of high bandwidth without the problems found in “off chip” designs…

I’m sceptical for various reasons but I’m not sufficiently knowledgeable to prove them wrong (and I suspect few if any people are) the ideas in use for these TRNG’s are effectivly new and not yet sufficiently time served to show if they are going to live upto expectations.

However all of these issues pale into insignificance when we talk about “Certification” and “Compliance” through the “life cycle” of a product.

For instance how do you test for “Random Behaviour” when the definitions most people use are not quantafiable. For instance “exhibits non-determanistic behaviour”… Is not exactly very helpfull when trying to develop tests, in essesnce you have to come up with a foolproof test that indicates without any doubt that the same result as seen from your generator could not have been produced by a determanistic device…

The simple fact is in the majority of cases it is not possible to tell if your TRNG source is becoming predictable or biased in some way.

Ultimately does it matter if the RNG is determanistic or not?

The simple answer is probably not, what realy matters is can it be “gamed to an adversaries advantage” and we don’t yet know enough to be able to say.

One asspect of this is rather unfortunate, which is access to the TRNG output before it gets the benifit of “magic pixie dust” obsfication via a hash or other function to “spread the love” of any entropy you might get. Access to the raw output means that you have a very real security risk, but removing access means you can not tell if it’s functioning correctly…

If you have a hunt around the net you will find that there are various attempts to put in place standards for Crypto-RNG’s but… Have a close look at how much hand waving there is on the actual “entropy source” of the TRNG.

Clive Robinson • September 19, 2011 3:45 AM

@ A Blog Reader,

With regards “personal drones”.

The article is a little misleading in that you don’t need 10,000 GBP/USD for a personal drone.

In the UK there is a retail outlet called Model Zone that will sell you an electricaly powered foam RC aircraft. You can also buy a small battery powered video recorder that weighs in less than 50gms that you can with a little skill mount in it and still have it fly, likewise you can get an integrated 2.5GHz TX video camera (from Swann).

I was with a friend doing just this a couple of weekends ago near the UK’s Epsom Race Course.

Model Zone also sell a nifty range of electricaly powered RC Helicopters as well. We’ve had a look at making one lighter to take a payload such as a very small linux computer.

And if you hunt around on the internet you will find plenty of software to talk to low power light weight GPS units and also software to control RC actuators etc to do auto piloting.

However I realy like the idea of a foam flying wing because you can get suitable foam that is “radar transparent” and you can also get “100 Ohm Foam” for storing DIL IC’s on that makes a very good microwave absorber to put around your electronics package in the fuselage. Thus it’s possible to make your own “stealth drone” without to much effort…

Clive Robinson • September 20, 2011 3:07 PM

@ aaaa,

“The attack targets TLS (transport layer security) 1.0”

If you look at my post a couple above yours you will see that The Register has also an article on the SSL/TLS problem.

As I said I expect this one to go on one way or another for quite some time…

As I’ve said befor I’m sure the likes of some parts of the NSA et al just love,

1, Side channels leaking key or plain text.
2, File formats with known plaintext at known locations (preferably at the bigining of the file).
3, Standards and Protocol errors that can be exploited.

Clive Robinson • September 20, 2011 11:09 PM

@ Gabriel,

“Is this a known plaintext attack on CBC mode ciphers, or does it rely on other factors that are present in ssl/tls”

Honest answer is I’m still trying to get to the bottom of all the gory details.

The first I heard about it was from someone leaking the info that something was in the offing via twitter about three weeks ago. However some developers where told about it in May so that they could start working on the problem as the solution is not simple (ie reasonable disclosure). Also depending on the conferance rules the authors/presenters of the paper may be also precluded from pre-publish (there’s a moan about this on the IETF TLS mail list)

As far as I’m aware from what other people have said the problem has been in SSL from the very begining and has been discussed amongst various security people for some years as a “theoretical attack” only (not the first time this has happened).

In an “Email Interview” ( http://threatpost.com/en_us/blogs/new-attack-breaks-confidentiality-model-ssl-allows-theft-encrypted-cookies-091611 ) Thai Doung (supposadly) said,

“It is worth noting that the vulnerability that BEAST exploits has been presented since the very first version of SSL. Most people in the crypto and security community have concluded that it is non-exploitable, that’s why it has been largely ignored for many years. Our work has two contributions, we introduce a practical and efficient plaintext-recovery attack for that vulnerability. It’s an enhancement of something crypto people call ‘block-wise chosen plaintext attack’. We present one application the attack: BEAST. BEAST focuses on SSL implementations on browsers which is HTTPS. BEAST works for most major browsers and websites.”

The only hint Thai Doung gives is ‘block-wise chosen plaintext attack’…

However he also notes this problem effects not just web browser/servers but other systems that use SSL/TLS (ie some mail systems, internet chat systems and quite a few others such is the ubiquitous nature of SSL/TLS).

Thus it’s still a matter of guess work, that said here goes,

When SSL was originaly developed, things like java script had not been developed or realy thought about, and likewise it was not envisioned that two seperate comms paths would share the same SSL tunnel.

Overly simply SSL is in effect a stream cipher and uses block ciphers in the CBC + IV mode. Now if two applications share the same key and IV then one application can work out the traffic in the other applications stream even if it only has access to the ciphertext.

Which is what the folks on the TLS maillist are currently talking about (see http://comments.gmane.org/gmane.ietf.tls/8814 or other mirror if you don’t want to sign up)

And where you will find a comment from Martin Rex,

“It only becomes a weakness when CBC-Mode is used inappropriately like when the same key is used to protect data that ought to be seperate. Or when it is used in a fashion that gives attackers an easy “adaptive chosen plaintext attack capability” for free(Applied Cryptography 2nd Ed., page 6 (4.) — such as a Web-Browser that not only runs arbitrary active content as a courtesy to the attacker, but also lets this malicious code re-use an established SSL connection through which supposedly confidential data was transmitted to mount an adaptive chosen plaintext attack.”

So Bruce get’s the last word 8)