Schneier on Security
A blog covering security and security technology.
« Identifying Speakers in Encrypted Voice Communication |
| The Effectiveness of Plagiarism Detection Software »
September 16, 2011
Friday Squid Blogging: Squid Street Art
Posted on September 16, 2011 at 4:52 PM
• 34 Comments
To receive these entries once a month by e-mail, sign up for the Crypto-Gram Newsletter.
The first report on how the UBS "rogue trader" operated indicates that he found a way to lie to the software that was supposed to curb excessively risky trading.
"It is thought a trader was able to circumvent UBS's risk-management systems by creating fictitious trades that made the bank's computer systems believe that the positions taken had been 'hedged' to mitigate potential losses when in fact they had not been.
Senior managers across the City [of London] have been scrambling to double-check their own systems to make sure they could not have been tampered with in a similar way."
Direct links to jpgs, please. Won't touch those fb pages.
The sport world and security don't often match up but this blog post from a sportswriter points out that a new NFL initiative to improve security at stadium is nothing but security theater.
It's also worth drawing attention to the fact that of the 1500+ comments to the posting almost all are negative against the new procedures.
@petrea: I seem to recall the same thing being said every time a rogue trader gets caught. They always manage to circumvent the security system that was supposed to track them. I do wonder how one fakes a trade that isn't correlated by whatever exchange the trade was supposed to take place on. Is there not a reconciliation between UBS systems and the market exchange?
A nice little hardware device that showes one of the weaknesses of some stream based encryption systems.
In this case the HDMI pairing protocol (HDPC) used to do "Digital Rights Protection" (badly),
Made by a company called Chumby the NetTV box is WiFi enabled and will display over other video (such as that from your Blu-Ray player) information such as tweets, SMS etc etc.
The nifty thing is because it's a poorly implemented Stream Cipher from Intel (Funny their name keeps poping up with poor quality crypto blocks) you don't need to "decrypt" the encrypted stream you wish to "overlay" on.
Thus arguably as the poor Intel crypto system is in the public domain as is it's master key then Chumby are not "circumventing" the system so not a direct Digital Millennium Copyright Act violation (though no doubt some over priced over egoed and overbearing legal twerp will have a go whilst getting major bucks from some other over egoed twerp, both of whom "should go out and get a real job").
Intel's next gen Ivy Bridge microarchitecture to support
- "Very high speed digital random number generator (DRNG) ... can generate high quality random numbers (standards compliant) at 2 - 3Gbps"
- ".. supervisory mode execution protection (SMEP) ... provides hardware protection against user mode code being executed in more privileged levels"
Sketchy details at:
@AC2 - 2-3 Gbps makes me a little nervous about the quality of the RNG. The xbit labs article below provides a little bit more detail. It seems the entropy source (The NRBG or non-deterministic random bit generator) is provided by monitoring certain complex states of the semiconductor. I'm skeptical if the 2-3 Gbps might be too high. This entropy appears to be provided as a seed for a PRNG (Or deterministic random bit generator, DRBG), which dumps into a register accessible by a cpu instruction, rather than enumerating as a peripheral (as is common with most HW RNG devices). I have to wonder if putting it in the ISA is a good idea. Also, will they expose the NRBG, or just the DRBG? I only enough about these to be dangerous, so I'm interested in hearing what an expert such as Bruce would say.
"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 & Gabriel
Anyone *really* needing TRNG can get it in this really nifty device.
As for ISA integration, VIA has been doing that for a long time via their Padlock Engine starting with C5 Nehemiah processors that I recall. Since then, they've added Intel VT support. Their bandwidth for the TRNG was much lower, suggesting Intel isn't using the actual TRNG output. Of course, many so-called TRNG's are actually TRNG's + a pooling or CPRNG mechanism to ensure high bandwidth output. The output is always the best hint at figuring out which it is. The Simtec is kind of the opposite: "each 256 bit block of data handed to the host was formed from somewhere in the region of 3840 bits read from the quantum generators. " Maybe a good thing.
TRNG's is a topic that I know a little bit about. So let me share a few truths
1) All RGN generators attempt to amplify / accumulate some small errors caused by component noise (1/f, thermal, other)
2) All sources require amplification to make the source reliably measurable,
Lets say the source is thermal noise for a 1M ohm resistor (a VERY big device to integrate) (say 100 ohms / sq) at say 2um width / 4um pitch. 100 sq/ 10K segment and 100 * 10 K segments.
so a 1M resistor takes up a chip die area of 200um * 400um.
Ok at 27C this resistor produces 128uV of thermal noise integrated over a 1Mhz bandwidth.
so to increase this level to about 1V rms noise we need a system gain of about 80dB (
One thing that confused me was why was Intel building this in what is essentially a consumer chip, whose requirements for randomness would be low (in the context of creating new secure sessions mostly) so why 2-3 Gbps?
But then I realised that some of the other things that run on consumer systems would also benefit: ASLR for one..
Clive's comment in the immediate previous post doesn't inspire confidence, though its somewhat unrelated:
"The nifty thing is because it's a poorly implemented Stream Cipher from Intel (Funny their name keeps poping up with poor quality crypto blocks)"
TRNG's is a topic that I know a little bit about. So let me share a few truths
1) All RGN generators attempt to amplify / accumulate some small errors caused by component noise (1/f, thermal, other noise)
2) All noise sources require amplification to make measurement of the noise reliable.
Lets say the source is the thermal noise for a 1M ohm resistor.
1Mohm is a VERY big device to integrate (say 100 ohms / sq) at 2um width / 4um pitch. 100 sq/ 10K segment and 100 * 10 K segments. So a 1M (noise) resistor takes up a chip die area of 200um * 400um.
Ok at 27C this resistor produces 128uV of thermal noise integrated over a 1Mhz bandwidth. To increase this level to about 1V rms noise we need a system gain of about (10000) or for engineers 80dB at 1Mhz bandwidth.
To physically make this requires two series amps with gains of 100 each. (assuming av=120db open-loop gain and 100Mhz GBW)
Now for the Problems!
1) the first stage opamp feedback resistor is 100Mohms. (remember the area of the source resistor (.2mm*.4mm) needs to be multiplied by 100 (about or 2mm*4mm). this size is significant because it acts as a patch antenna for certain RF mm wave signals)
It also transforms ANY thermal die gradients into systems signals. meaning the resistor needs to be isothermally layed-out relative to any significant thermal source.
2) At 1MHz the PSRR (power-supply-rejection-ratio) of a typical opamp is less than 20dB.
Now our required system has 80dB of gain so lets try to put some numbers to this. 1mV of switched mode power supply noise (at 1Mhz) on the first opamp will produce 100uV output from opamp1 and 100*100uV (10mV) output from opamp2. So within a 1V noise signal we have 10mV of power supply signal. This is a signal to distortion ratio of 100, in terms of Bits it is about 7bit (6dB/bit). So our RNG system has about -40dB correlation to the system power supply noise. This is not bad for most applications, BUT it is a disaster for a RNG.
For the above reasons, even the best RNG can only achieve about 9 to 10 bits of true randomness at 1Mhz.
Anyone claiming better performance usually has one of the following problems
a) they simply don't know what they are talking about (very common)
b) they are willfully blind to the shortcomings of their circuit (a close relative to problem a))
c) they are combining multiple noise sources and possibly digital pseudo random techniques (hash's, stream cyphers, LSFR's ) with TRNG techniques.
Most of today's best TRNG's are variants of the last category. Usually the engineers tries to combine thermal noise and non-constant sample intervals and unknown internal time constants. If these three are appropriately combined with simple LSFR's than the resultant RMG will pass all tests for randomness. But your left with the question, IS it really random, or just a mess that is too difficult to undo?
Examples of the above are
-self oscillating continuous time sigma delta modulators (especially at 3rd and 4th order)
- RF mixers down converting thermal noise with a jittery oscillator.
BTW: I probably forgot to mention this BUT skilled hardware hackers usually don't attack the system at room temp, they usually prefer the characteristic of the RNG when the chip is cooled with liquid N2 and they usually add more than 1mV signal to the power supplies (100mV is a more common amount)
"But then I realised that some of the other things that run on consumer systems would also benefit: ASLR for one."
It sure needs something, have a read of,
4 bits of entropy is down in the "cut for an ace" territory.
But this raises the question of how many bits of entropy does ASLR realy need and for what.
In Vista Beta2 it was supposed to be 8bits static from reset ( http://blogs.msdn.com/b/michael_howard/archive/... ). That is the libs got loaded in one of 256 slots at boot and stayed there until the next boot. That's possibly fine on laptops that get a cold boot every day but not for servers or other high value targets.
@ 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...
Last week (Wed 7th Sept) we presented details of Intel's DRNG and announced that it will first be available on Ivy Bridge.
As described in the talk, the dominant noise source is the thermal noise in the gates of the transistors in a latch. The method of turning noise into bits is through the metastable resolution of the latch. We do not 'sample noise' from an amplifier in the sense discussed above.
The speed of the source (approx 3Gbps) is a function of the metastable resolution time of the latch on that silicon process. It will vary with silicon process. The noise kicks the latch to resolve and it there that we see random behavior. Contrary to statements made above, 9-10 Mbps is not a limit on the entropy extractable from on chip noise.
Bias and correlation will be present in the bits but unlike many sources, this one is simple enough that we can build effective models to give us a min bound on the entropy content, across process, voltage, temperature, aging and perturbation and confirm through simulation and empirical observation.
From there, standard algorithms can be employed to distill/extract the entropy and extend it with a PRNG. In the case of the Intel DRNG, AES-CBC-MAC is used for entropy extraction and the PRNG is an SP800-90 compliant AES-CTR based DRBG. These are implemented in hardware, which at 22nm, tends to quite fast.
As to the question of why we implement this in consumer chips - we intend to implement this in all processor chips, so that good random numbers are available at all ends of security protocols, thus limiting the failures of cryptosystems we have seen from poor RNGs in the past. The design is fast enough for server applications, so we don't have to re-design it and re-certify it later.
Putting the post processing in HW and making the access to the RNG available through an instruction (RdRand) was deliberate. The intent is to bypass OSs, libraries, API etc and allow applications to access the random numbers directly, thus minimizing the attack surface against the RNG.
For comprehensive documentation, go here.. http://software.intel.com/en-us/articles/...
Sorry for the cross-post, but this is via the netsec list and the quote in the last line of the article immediately made me think of "Liars and Outliers"
On Mon, Sep 19, 2011 at 2:23 PM, Howell, Paul wrote:
> At http://www.bbc.co.uk/news/magazine-14924443
> Schuyler Towne, a competitive lock picker, can pick most everyday locks but
> he still won't pick the lock on his apartment building's front door.
> Picking a lock one doesn't own violates competitive lock picking ethics.
> It's no secret the skills he practises and teaches can be used for criminal
> activity, but Mr Towne says it's simply up to each person how they'll live
> their life.
> In this first person account, the lock picker describes the thrill of
> competing in "locksport" where participants race to pick through a series of
> Over the years Mr Towne has come to realise how the use of locks reveals the
> way people relate to each other.
> Netsec mailing list
If you need help analyzing your RNG than I'm available.
Unfortunately the metastability of a latch has very little rejection for supply noise / glitching occurring at the sample time. the function also has a bias that accumulates over time due to NBTI and HCI effects these will swamp out the thermal noise component.
Tell me if you need help.
The person (Luigi Auriemma) who released 34 zero-day exploits on SCADA systems back in March has relearsed another 15.
Of this current batch of zero-days 13 effect eight different SCADA products...
And just so Apple MAC users won't feel left out. of the vulnerability fest...
It appears that ordinary account users on OS X Lion can change other users passwords, including those of the admin. It's a quick and simple command line exploit that could easily be done in a few seconds whilst a users goes to get a print out from the office printer etc...
Thanks for that link, read the PDF, looks interesting.
n00b question re the Online Health Tests, how do they "compare bit patterns against expected pattern arrival distributions as specified by a mathematical model of the ES".
If you have a mathematical model that the entropy source will definitely correspond to, is it really random? If it is really random won't occasional non-compliance with the OHTs stop random number generation?
Oh and an item from The Register that states that an attack against TLS 1.0 and earlier works because the crypto can be broken by a plain text guessing attack,
"... carries out what's known as a plaintext-recovery attack that exploits a vulnerability in TLS that has long been regarded as mainly a theoretical weakness. During the encryption process, the protocol scrambles block after block of data using the previous encrypted block. It has long been theorized that attackers can manipulate the process to make educated guesses about the contents of the plaintext blocks."
The two researchers (Thai Duong and Juliano Rizzo ) who have come up with the attack will be presenting it at the Ekoparty security conference in Buenos Aires later this week,
Because nearly all browsers only support TLS 1.0 or earlier that are all vulnerable this is quite significant. However the newer TLS standards which have not yet been taken up by browsers are apparently not vulnerable.
From what has been said this is actually an attack against the protocol of SSL/TLS which is a bit of a problem, because it's likley to be fixed in a way that will still be vulnerable. That is later versions of TLS will be put into browsers but the vulnerable versions will be retained "for backwards compatability".
Also if the vulnerable versions of the protocol are retained they will probably be accessed via a "fall back mechanism", which in all probability, to avoid confusing users, will fallback "silently" and in all likleyhood be forcable by an attacker in some way (such is the way the industry works).
Thanks for commenting, David, knowing what it uses helps. I'll read up on the implementation when I get a chance, but I was wondering if it is similar or related to some research I found on metastability: http://www.eecs.umich.edu/~tnm/trev_test/...
"Security researchers have developed a potential cyberattack that could decrypt secure communications used by online banking and payment sites.
"The attack breaks the confidentiality model of the protocol … potentially affecting the security of transactions on millions of sites," wrote Dennis Fisher on ThreatPost, an internet security news blog run by the antivirus maker Kaspersky Lab.
The attack targets TLS (transport layer security) 1.0, the encryption mechanism used by websites accessed using https (secure hypertext transfer protocol)."
"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: is this a known plaintext attack on CBC mode ciphers, or does it rely on other factors that are present in ssl/tls?
"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/... ) 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)
Further to my above made in the we small hours of the morning (my spine is giving me pain and thus insomnia, but atleast I'm now off the CNS Depressent pain killers that turn the brain soft ;)
Firstly my last sentance "So Bruce get's the last word 8)" does not make a lot of sense because I forgot to preface it with "He also mentions this blog towards the end."
Secondly I also forgot to add a link to Bugzilla,
Which makes interesting reading, comment 2 there indicates much of what the problem is with going to TLS 1.1 and then 1.2.
However the real problem is that it's not just the client PC's that are at fault the majority of web servers only use TLS 1.0 as well.
This is because of the "chicken and egg" issue of "Why upgrade the server when the clients don't talk 1.1 or 1.2", and "Why upgrade the client when the servers don't talk 1.1 or 1.2"...
Thus for various reasons support for TLS 1.0 will stay around for a long while yet in client software. And even if you can disable it via a configuration panel the chances are the software will ship with it enabled to keep the customer support lines quiet.
Thus if a Man In The Middle attacker knows or finds a way to make the "negotiation phase" "fall back" to TLS 1.0 then this attack will continue to be feasable...
Thus it will probably still be haunting us for the next 5-25 years depending on such things as "the expected lifetime of embbeded systems".
For example your common or garden electricity meter has a designed in expected life time of well over 25. Thus the up and comming "smart meters" will also have an expected service lifetime of atleast 25years... So if the embedded interface is TLS 1.0 over zigbee, bluetooth, or mobile phone then client software will still have to support TLS 1.0 for the next quater of a century or so...
Is anyone here interested in an in depth analysis of the metastable RNG cell that Intel has revealed. I have some preliminary estimates of the cell's entropy, but I'll only continue to work on this if their is any real interest in the topic.
I'm definatly interested, and I suspect some of the other regulars would be interested as well.
How will you present the information?
Because based on my (limited) knowledge of Hot Carrier issues I gather that the performance will decay logrithmicaly quite significantly over a relativly short period of time.
OK I'll see what I can write without requiring the reader to have a degree in semiconductor device physics, but it could be hard, as with many technical things the devil is in the details.
If you provide me with the exact cell dimensions and Spice models, or better still 3D process models, than I'll give you an advanced look at what I write and a chance to comment. Otherwise I'll just make some reasonable assumptions about cell size and layout.
- Well spacing from the cell (well stress effect)
- device Length (I'm guessing you use short channel devices)
- device Width
- Layout of latch (how many devices Spice M factor)
- Common centroid or other layout?
- Any specific Power supply filtering
- Current controlled or simple switched Latch cells
- Sample clock frequency
- peak supply noise (an FFT of the cells supply ripple would be useful)
-Supply noise ripple at sample frequency
Beanies are the new determinant of nefarious intent!
A beanie-wearing high school student on his way to the bank with fellow students after a fund-raising car wash causes the branch to go into lock down after an over-zealous teller doubts his intentions.
"It was just an overzealous bank clerk who had pressed the alarm."
No further action would be taken, police said.
Totally the wrong response - the teller cost the community (bank, police etc) a heap of money for a pointless and stupid reaction.
Schneier.com is a personal website. Opinions expressed are not necessarily those of Co3 Systems, Inc.