Single DES and Double Yolks

It was reported in the Daily Mail this week that a woman bought a carton of half a dozen eggs, which she later found to be all double-yolked, as shown below

Since the chances of getting a single double-yolk egg are  around 1-in-1000, then it appears that we have witnessed an extremely rare event, in fact one that is a practical impossibility. If we assume that the likelihood of each egg being double-yolked is independent, then the picture above is conclusive evidence of a  1-in-10^{18} event manifesting. This is a bit less likely than guessing a DES key at random at 1-in-10^{17}. The Daily Mail article goes on to give reasons why this event is not as unlikely as it seems, because on face value, the event is so unlikely that we would never expect to witness it over the lifetime of all eggs that have ever been produced.

Apparently the eggs are all likely to come from hens in the same flock and of the same age which reduces the likelihood to “only” 1-in-729 million. And the occurrence becomes even more likely (or less unlikely – take your pick) when we account for eggs of a similar weight being sorted into the same boxes.

A bit more detail is given over at the wonderful Understanding Uncertainty blog. If the 1-in-10^{18}  odds were correct then given the number of eggs consumed in Britain each year, we are looking at waiting 500 years to see the photo above, so the independence assumption is not plausible. Factoring in that eggs coming from the same group (who may have a propensity for double yolks), packing by weight, noting that some supermarkets can detect and sell double yolked eggs, then the event seems less impressive. But impressive nonetheless!

The USB Password Vulnerability

In early January Heise Security reported that a German security firm had discovered a vulnerability in the password authentication process of several USB sticks that are rated as being highly secure. The discovery has been widely reported, and led to various responses from USB vendors Sandisk, Verbatim and Kingston, including patching and recalling their devices from the field. The full list of effected sticks has been reported by Simon Hunt for example. Steve Ragan of the TechHerald has commented that the whole incident is “"quickly becoming the first FUD-based news cycle for 2010”.

What was the vulnerability?

Well when a user plugs in a password-protected USB stick their desktop starts the stick by launching a popup application prompting the user for their password. You would expect that the user supplied password is then transferred to the stick for verification, and the stick grants access if the password is correct.

What German security company SySS, discovered is that the password verification is actually performed in the popup application itself , and an acknowledgment code is sent back to the stick indicating if the candidate password is correct or not. By sniffing this traffic SySS determined that the acknowledgment code granting access is static, and in particular does not depend on the password entered by the user. Essentially the desktop popup verifies the user supplies password and then returns "yes" or "no" to the stick.

SySS captured the acknowledgment code, and then wrote  proof-of-concept exploit which injects the acknowledgement code into the memory space of the desktop popup so that the value returned to the stick is always the positive acknowledgement code. Thus regardless of what password the user enters the hack ensures that the stick will always grant access.

What was the impact?

Given the injection code, the password-protection can be defeated on sticks susceptible to the attack, which turns out to be a reasonably large class of commercial sticks that are marketed as being highly secure. All things being equal, the risk of a data breach from lost sticks is therefore increased, since the password-protection of the sticks can be bypassed with the right software. And losing sticks is increasing. CSO Online recently reported on a UK survey conducted by Credant which revealed that 4,500 memory sticks have been forgotten in people's pockets as they take their clothes to be washed at the local dry cleaners.

The impact is not limited to a single vendor product. The vulnerability exists in several families of secure USB devices across the major USB vendors because they all rely on a common USB chipset whose security properties have not been properly vetted.

FIPS Certification

The incident is all the more telling in that the vulnerability impacts devices that use AES 256-bit encryption and are rated as secure by the FIPS 140-2 certification process. Users are paying quite a premium over vanilla sticks for the advertised additional assurance that their data are protected by a certified device using strong cryptography, and for some US government agencies such purchases are mandatory. The relative ease with which the password protection was bypassed calls into question the value of the FIPS 140-2 process.

In Computerworld NIST is quoted as saying "From our initial analysis, it appears that the software authorizing decryption, rather than the cryptographic module certified by NIST, is the source of this vulnerability", and then also "Nevertheless, we are actively investigating whether any changes in the NIST certification process should be made in light of this issue”.

To be fair, the FIPS 140-2 focuses on verification of cryptographic modules and not the supporting software, however the incident highlights the narrowness of the approach and the expectation that certification is more than secure cryptography. Chris Merrit at Lumension has a good post on the fine print of the certification FIPS 140-2 process, and he concludes

So, bottom line: while this discovery seems to suggest an area to which NIST might want to bring some clarity and rigor, it does not mean that FIPS 140-2 is fatally flawed. It’s up to you, as the buyer, to understand what (potentially critical) functions occur inside & outside the cryptographic boundary, and how that might impact the security of the device in your case. And since what you’re looking for is what’s not certified, it might be useful to have an expert review the vendor security policy (posted with the certification on the NIST website) to help you understand the nuances.

AES-256 and Passwords

As I explained in Are AES 256-bit keys too Large? it is very unrealistic to equate password security with the security of AES-256. To achieve the equivalent of 256-bit security users would need to select 40 character passwords at random, and we are a long way from that. In fact so far away that we will never get there. So USB devices that protect their data using AES-256 encryption sound impressive, but when access control to those devices and the underlying keys is controlled by a password, then this setup sounds a lot less secure. The SySS vulnerability now shows that the whole AES-256 encryption process can be bypassed in the presence of weak password handling.

Conclusion?

Is there a useful conclusion from this incident? There is a lot of embarrassment all round and we have little confidence that a similar issue will not arise in the future. Security is just done poorly in general, and blatant examples are uncovered whenever someone takes the time to look under the hood. Some  articles and posts have focussed on verifying passwords in software as the culprit, which is partly true, but the real issue is not software but insecure programming of software - the password verification should never have been done on the desktop, and a static acknowledgement code should never have been used to unlock the USB device.

A trusted path should be established between the desktop keyboard and the USB device, and for smart cards this needs to be done with a secure reader. But this is at odds with the plug-and-play semantics of USB sticks where the portability of the ubiquitous USB connector is the selling point.

Plugging the Authentication Gap in SSL

The IETF has announced a draft document that specifies changes to the SSL protocol which closes the "authentication gap" exploited by the renegotiation attack announced last November. I posted a plain English explanation of the attack here, and you can find better graphical explanation here by Thierry Zoller (check for updates at his blog). The IETF and several vendors, including Google, Microsoft, and PhoneFactor, have been working on plugging this authentication gap since October. Until now, the best defence against the attack was to disable renegotiation in SSL.

The attack was initially dismissed as a quirk in the protocol - unexpected yet harmless - but it has ultimately resulted in several relatively small yet fundamental changes to SSL that introduce cryptographic state from one run of the handshake protocol to the next. The threat profile of the attack was raised when proof-of-concept code was written to demonstrate how the attack could be applied to steal Twitter passwords. PhoneFactor has described the attack as the most "severe" against the core SSL protocol to date.

The vulnerability that was uncovered is the observation that SSL does not distinguish between the initial protocol handshake of the client connecting to server, and any subsequent in-band handshakes for the renegotiation of cryptographic parameters. An attacker can establish an SSL session with a server and then later highjack an initial client SSL connection request to the same server, and splice the client request into the existing SSL session that the attacker has with the server. This is possible since the server interprets the client connection request as a renegotiation by the attacker. Any pending commands that the attacker has established with the server are then injected into the next client SSL-protected web session and executed in the context of the client (using the client cookies for example).

The solution proposed by the new IETF draft is for both client and server to cache the validation data that is currently computed and exchanged as the last step in the existing handshake protocol. A new protocol field has been introduced which indicates if the handshake is an initial or subsequent run (renegotiation), and in the latter case, the cached validation data is included in the renegotiation protocol. This prevents two independent sessions from being spliced together since the required validation data will either be absent or mismatched between the client and server.

It now remains to make any final tweaks to the protocol and to then deploy the revised protocol in existing SSL and TLS libraries, which is expected to be a slow and tedious undertaking. One of the authors of the new draft, Eric Rescorla, was a co-author in a recent study to examine the rate at which weak keys produced by a flaw in the random number generator of OpenSSL on Debian from 2008 were being patched. The study tracked a collection of approximately 50,000 public web servers over a period of 6 months. Initially around 1.5% of the servers (751 to be exact) were using Debian-flawed keys in their certificates, and 30% of the Debian-flawed certificates were still not re-issued after almost 180 days. Let’s hope for a better rate of patching in this case.

Fast computations on FPGA Clusters

Pico Computing recently announced a single hardware accelerated server that can process 280 billion DES decryptions per second, permitting the full 56-bit key space to be searched in 3 days. This is apparently a new record, and the announcement is a prelude to a presentation at the upcoming Black Hat DC 2010 conference in Virginia.

The effort was lead by David Hulton, Pico Computing Staff Engineer, who was previously involved in an abandoned effort to create rainbow tables to break GSM encryption. The latest effort focuses on understanding how FPGAs can be used to produce computations that are power efficient and scalable. In a companion Pico white paper, the impact of scalable FPGA clusters on password breaking is considered. A dedicated FPGA cluster with 77 nodes can recover an WPA key in 11 seconds, representing an improvement of almost a factor of a thousand over the same time required by a standard dual core processor.

End of Month Roundup, Jan 2010

Well I have to say that I still have not got back into the swing of blogging after Christmas. January has already come and gone with a only a single post to show, and I am grateful for the 1,500 visitors this month. There is a great deal going on in security, and I am collecting materials for posts that I imagine will come next month.

This is the first post written on my new netbook, and I finally succumbed to the purchase after many months of indecision. The post-Christmas sales finally got me. I also purchased a copy Ultra Recall for capturing and editing web content, and added some plug-ins to Windows Live Writer for improved editing and content linking. You may also have noticed the site enhancements provided by Apture that provide compact previews of linked content without having to navigate away from the current the page.

One of the built-in previewers is for Scribd content and I have added quite a few documents of late, clearing out pdfs that have been languishing on my hard drive, in need of review. My latest uploads include

• State of Enterprise IT Security and Emerging, Jonathon Penn, Forrester
• How to Organize Email
• How to Secure Windows and Your Privacy -- with Free Software
• Rainbow Tables Explained
• A Probabilistic Model for Cyber Attacks and Protection
• A Status Report on the P versus NP Question
• On the Entropy of Arcfour (RC4) keys

The last document is a copy of a 1998 IBM technical report on RC4 (then only referred to as Arcfour), examining the randomness of initial state and the cost of recovering the key through backtracking.

This time last year I had started another blog which I had hoped would be more informal and easier to write (less time per post), and also give me some exposure to Wordpress blogging tools. Quite quickly it became too hard to maintain both blogs and I ended up more or less abandoning the new blog and transferring some content over to No Tricks

• Moore's Lore and Attention Crash
• The Restaurant at the end of the Web
• Twitter as your Personal Content Proxy
• Social Media Data in Flight and at Rest
• Scoble's Law of Twitter

It seems that I was just as interested in Scribd a year ago as I am today with

• Data Centric Security Model hot on Scribd
• Entropy and Anonymity article featured on Scribd
• Some books on Scribd
• Publishing on Scribd

but there was still time for a few other posts as well

• Google's Storm in a Teacup
• Downadup's Password Cracking List
• Algebraic Group Visualization

Let’s hope I am back to full strength blogging next month.

Slides from my ZISC talk on Black Swans in IT Security

In December I gave a talk at the Zurich Information Security Colloquium, based on a post I made in October 2008. The slides can now be found on Scribd.

Recent Uploads to Scribd, Dec 17

Here are my recent document uploads to Scribd

• Threat Classification, Web Application Security Consortium
• Statistical-based approach to password guessing
• Clobbering the Cloud
  
• NIST Statistical Test Suite
• 2009 Key Management Report from True Catalyst
• iPhone Privacy presentation from Nicolas Seriot
  

A USB Entropy Drive

A UK company called Simtec Electronics has created a USB thumb drive device with dedicated hardware for producing a continuous stream of high entropy bits, suitable for mixing into an existing entropy pool on your device or feeding directly into applications and protocols that require sources of randomness. The product is called Entropy Key and and can be ordered from the website for £36.00, with further discounts for bulk orders

An overview of the process for producing the entropy is given in the diagram below. There are two independent noise generators based on P-N junctions that are sampled at a high rate to produce a stream of bytes. The output of each generator and their XOR are subjected to the universal statistical bit test devised by Ueli Maurer. If the sequences pass this test then von Neumann’s debias trick is applied, and then another round of universal testing, followed by hashing with Skein. This process blocks at any stage if the computed statistics fall outside conservative estimates of the properties of random generators.

These steps are repeated until 20,000 bit have been collected, upon which the statistical tests recommended by FIPS 140-2 are applied. The 20,000 bit pool is then parcelled into blocks of 256 bits, and Simtec estimates that each such bock has been generated from about 5,000 bits of noisy hardware samples.

There is quite a reliance on Maurer’s universal statistical bit test, and perhaps justifiably so since this test is specifically designed to detect deviations from expected statistical properties in a bit generator by computing an estimate of the generator’s entropy using ideas from universal data compression algorithms. The test is quite simple, and there is a reasonable description and parameterization given in NIST SP-800 22, which also contains a description of a large number of other statistical tests. A research paper on a finer analysis of Maurer’s test can be found here.

The output rate is, by its nature, variable but an average rate of more than 30 kilobits per second is expected. The complete client daemon source is provided under an MIT license which means everyone is free to examine the code for themselves. SimTec also notes that the Entropy Key can automatically detect various different physical attacks, such as temperature changes (by using a built-in temperature sensor), and opening of the case. The device is currently undergoing testing with "select customers” but is available for general ordering. There is an IRC channel #ekey on the oftc network if you want to discuss any of this further.

(Thanks to Vincent Sanders for providing some more technical details)

 

A Faraday Wallet

Do you remember the blocker tag? This was a proposal from researchers Ariel Jules, Ron Rivest, and Michael Szydlo, all affiliated with RSA Data Security, published (and surely patented) in 2003. It was about this time that the privacy concerns over information that could be collected about you and your habits by engaging in passive exchanges with arbitrary RFID readers was reaching its zenith. Your RFID tagged items could be passively giving away a lot information without your consent or knowledge.

Jules, Rivest, and Szydlo jokingly suggested that you could encase yourself in protective foil or mesh, which would make walking a bit more awkward but perhaps could be useful for wallets. And now we have just such a wallet, shown below.

It is advertised as an Identity Theft Preventing Privacy Wallet, retailing for $79.95. The product advertising states that

Most credit cards now contain tiny chips that provide a unique identifier that can be scanned to retrieve your billing details.

Such RFID technology can, unfortunately, also be corrupted by hackers using portable scanners in crowded airports, restaurants, and stadiums. Our slim and surprisingly lightweight Privacy Wallets are literally woven from over 20,000 super-fine strands of stainless steel into a flexible fabric that feels like silk — but protects your ID like armor plate! Stronger than leather, with no sharp edges or corners — and won’t stain or scratch.

Inside, 6 credit card slots, 2 internal slots, and a billfold let you carry plenty of purchasing power — completely shielded from today’s high-tech pickpockets.

This could go well with your swine flu suit.

The Crypto Year in Review from Bart Preneel

Bart Preneel is a professor at the Katholieke Universiteit Leuven, in Brussels, and leader of COSIC, one of the largest security and cryptography research groups in Europe. This is the research group that produced Rijndael, which eventually became the AES. Preneel is a frequent speaker on security and cryptography, and in this post we will review a recent presentation on the topic of the Crypto Year in Review.

Preneel begins by observing that cryptographic research is alive and well, with over 600 papers published on the pre-print server of the IACR, amounting to over 10,000 pages of written research. Not all of these papers will be published, but it does give you some idea of the reading load to keep abreast of new ideas and developments.

His attention then turns to AES, which still remains secure despite the publication of several theoretical attacks. AES now runs at 110 MB/seconds in software, and Intel has announced direct hardware support beginning with its Westmere line of chips. Referring to the security of AES-256, Preneel states that for $5 billion USD, a key cracking device could be built to search a 120-bit key space that would take a billion years. This was about the same work required by the so-called Luxembourg Attack announced in June, which was the first attack against full AES-256 that saved significant time over exhaustive search (though a large amount of ciphertext is required).

Preneel calls this an academic weakness, since it relies on a related key attack which is hard to arrange in practice and can be easily avoided by making the AES key schedule more non-linear. The slide below shows that relationship between AES key size and the number of rounds. There are several feasible attacks when the number of rounds is 10 or less with small key sizes. The 2^{119} effort of the Luxembourg Attack is located far above what is considered practical.

Preneel then considers hash functions, the topic of his PhD thesis. He gives a benchmark slide showing the complexity of collision attacks against well-known hash functions, assuming a $100K USD funded adversary using special hardware (equivalent to 4 million PCs).

The downward trend of the graphs is suggestive of a meltdown for hash functions, with the worst implications for protocols and signatures yet to play out. The transition path to a better hashing standard via the SHA-3 hash contest of NIST in underway, and a new standard by will be selected by 2012. However Preneel is concerned that the design of SHA-3 will be based on state-of-the-art from 2008 – that is, all of the additional insights and learnings produced in the evaluation of the SHA-3 candidates will not be exploited until SHA-4.

It was a relatively quite year for public key cryptography, with no factoring records announced, but a lot of fretting over the coming upgrade of RSA-1024 keys in 2010 in compliance with US standards. Elliptic curves are rising in importance due to support from the NSA, and quantum computers remain a very long term threat to the security of public key systems.

There are some additional topics considered by Preneel, mainly around protocols and deploying cryptography. His summary is that 2009 was a relatively unexciting year on the surface but you may find interesting details when you look closer. Also, always remember that cryptography is a building block for information security, an essential block but far from the whole story.

WPA Password Cracking in the Cloud for $34

Following on from the recent results of a project on the feasibility of password cracking using cloud computing, a new cloud service for cracking WPA passwords has been announced by researcher Moxie Marlinspike, best known for his work on discovering subtle flaws in the SSL protocol. The cloud service attempts to crack uploaded passwords against a 135 million word WPA-optimized dictionary on a 400 CPU cluster.

The stated purpose of the service is to assist penetration testers and network auditors who need to test the strength of WPA passwords that use pre-shared keys (PSK or personal mode). In this mode, the PSK master key is used to derive a session key from several parameters in the initial wireless connection handshake, including the MAC addresses of the client and base station. In practice, the PSK is a password and is therefore exposed to a brute force or dictionary attack.

Verifying a guess for the PSK password is relatively costly, roughly the equivalent of processing a megabyte of data, since the session key is derived from 4096 iterated hash operations. This high iteration count, or spin, limits the number of password trials to several hundred per second on a standard desktop. Marlinspike's cloud service searches through a 135 million word dictionary in just 20 minutes, a computation that would otherwise take 5 days or so on a standard desktop.

And all this for just $34, after a client has uploaded a capture of the WPA handshake on the network of interest. If the cloud service does not find a password then a client can be confident that the submitted password is resistant to dictionary attacks – no refund, you still pay for the assurance!

The Church Of Wifi has a project to create public rainbow tables for WPA based on common passwords, but the resulting tables only encode one million passwords because the tables must be recomputed for each network identifier (ESSN), which acts as salt in the password derivation function. Marlinspike opted to create his own WPA-optimized dictionary list which includes word combinations, phrases, numbers, symbols, and “elite speak”.

In Security Muggles I posted about finding ways to connect with management about security. Robert Graham, CEO of penetration testing company Errata Security, has commented that "When I show this to management and say it would cost $34 to crack your WPA password, it's something they can understand," he said. "That helps me a lot."

PC World has somewhat dramatically reported the announcement as New Cloud-based Service Steals Wi-Fi Passwords, suggesting that the cloud is reaching into wireless networks and grabbing passwords. In fact, the service is designed to trade-off a 5-day desktop computation against a 20-minute cloud computation for $34. Nonetheless, a better name would be WPA Auditor rather than WPA Cracker.

A Threat Model for SSL

I traced a link to my post How fast are Debian-flawed certificates being re-issued? to SSL Shopper, a new site for me, and I looked back through their news items and found a link to an SSL Threat model proposed by Ivan Ristić, the principle author of ModSecurity and a leader in Apache security.

Referring to the origins of his threat model, Ivan states that

SSL is easy to use but also very easy to use incorrectly. The ecosystem, which is built of the specifications, the implementations, the CAs and the PKI, is full of traps, each of which is very easy to fall into. Once I started to spend significant time thinking about SSL I set out to build a model of the ecosystem, for my own education and to ensure that I understand it all. That's how I arrived to the SSL Threat Model.

His threat model is represented as a FreeMind map, available as a graphic as shown below. The threat model considers clients, servers, PKI, protocols, users and attacks, and perhaps the model needs to be updated in light of the new The TLS Renegotiation Attack.

Ivan admits that the model needs some additional clarification, but it is probably more useful as a published draft rather than waiting for him to find the time to perfect the model (the same reasoning lead me to releasing my outline of a password book).

Tidbits: A5/1, WhiteListing and Google

There is a nice write-up in the very respectable IEEE Spectrum on the A5/1 rainbow table generation project run by Karsten Knol for cracking GSM encryption. The write-up for Knol in the IEEE is a signal that his project has mainstream acceptance and attention. The timeliness of Knol’s project was heightened a few weeks ago when MasterCard announced that they would be using GSM as an additional authentication factor in their transactions. This MasterCard feature may end up being very popular since IDC recently predicted that the mobile phone market will exceed one billion handsets by the end of 2010. Hopefully this huge demand will increase the deployment of the the stronger A5/3 algorithm that is being phased in during upgrades to 3G networks.

The evidence continues to mount that whitelisting is an idea whose time has come. Roger Grimes at InfoWorld published a large list of reviews on whitelisting products, and he was pleasantly surprised that “whitelisting solutions are proving to be mature, capable, and manageable enough to provide significant protection while still giving trustworthy users room to breathe”. Given that the amount of malware introduced in 2008 exceeded all known malware from previous years, viable alternatives to the current blacklisting model are needed.

Finally, Google recently announced that it will be offering its own DNS service, nominally to increase performance and security. Sean Michael Kerner wonders whether Google DNS is resistant to the attacks reported by Dan Kaminsky last year, where common DNS implementations relied on poor random numbers. H. D. Moore has forwarded Kerner some graphs he made from sampling Google DNS for randomness. First, a plot on port scanning

and then a plot of source ports against transactions IDs

In both cases the graphs look quite random, and so both Kerner and Moore conclude that Google seems to be a right track here. But Moore concedes that more testing to be done.

November Blog Round-Up

I normally don’t post monthly blog summaries, but  last month there seemed to be quite a bit to write about. It was a good month for visits and page views, so thank you to everyone. Here is the No Tricks dashboard from Google Analytics (click to enlarge).

 

And a review of the posts

Opinion and Analysis

• The Other Google Desktop
• How fast are Debian-flawed certificates being re-i...
• The TLS Renegotiation Attack for the Impatient
• More on TMTO and Rainbow Tables
• The Internet Repetition Code
• Security FreeMind map sources
• Not so sunny for Whit Diffie
• Security Muggles
• Quadratic Football Revisited
• FUDgeddaboudit
• MasterCard bets on A5/1
• TLS Renegotiation Attack Whitepaper
• How big is 2^{128}?

Visualisations

• Visualisations of Data Loss
• Navigation map of the Cloud Ecosystem
• Growth of Wal-mart across America
• Death Star Threat Modeling
• mini-Bruce for $89

News

• Recent uploads to Scribd
• Outline of a book on Passwords
• Upcoming Black Swan talk at ZISC

Improving Blog Navigation

• All Posts on Entropy
• All Posts on the Birthday Paradox
• All Posts on Security with FreeMind and Flash
• All Posts on AES
• All Posts on Passwords

Google Maps and Crypto Laws Mashup

Simon Hunt, VP at McAfee, has a great Google map mashup application that visually maps crypto laws to countries around the world, including individual US states. The map was last updated in September.