How the Dual EC DRBG Backdoor Works

In December 2013, Reuters reported that the National Security Agency had paid RSA ten million dollars to use a random number generation algorithm that contained a backdoor.  The algorithm, Dual_EC_DRBG, is the default random number generation algorithm in RSA's BSAFE toolkit which is used by other companies to implement cryptography in their products.  These allegations have seriously damaged the reputations of RSA and of the NSA who had established itself as a partner in the security community.

A great number of articles were published about the RSA-NSA deal after Reuters first reported on the matter.  Many of these make misleading or untrue technical assertions and few of them have attempted to provide any explanation as to how this supposed backdoor works.  Some commentators have claimed that this backdoor (if true) made the products that used the BSAFE toolkit more vulnerable to attack.  This is (mostly) not true.  Because the backdoor, whose possibility was first speculated on by Dan Shumow and Niels Ferguson of Microsoft, relies on techniques from public key cryptography, it is only usable by a person that knows the key and that key cannot be discovered by another party, even if that party knows the full details of the algorithm.

This post explains the Dual_EC_DRBG algorithm and how a backdoor could be implemented.  It is meant to be accessible to non-cryptographers. We’ll begin with a really brief review of modular arithmetic and the discrete logarithm problem, discuss basic operations on elliptic curves and introduce the discrete logarithm problem over elliptic curves (ECDLP).  Then, we’ll see how Dual_EC_DRBG can be engineered to contain a backdoor and explain why the backdoor is only usable to someone who knows the key.  If all of this is new to you, I recommend reading an introductory text such as this one.

Note: I originally wrote this as a paper for a graduate class.  In revising this for my blog, I've removed all of the in-text citations and tried to replace them with links.  My original references are listed at the end.  The point of this post is to explain ideas originated by others; the original ideas are not mine.

Understanding Rabin-Miller

I'm posting this to provide some clarification on the Rabin-Miller primality test as requested on Twitter.  My favorite reference on the test is the notes by Diane Hoffoss located here.  If you're not familiar with primality testing and/or Rabin-Miller; read the notes first then come back to this post if you need any clarification.

My purpose here is to restate a few key points from Hoffoss's notes, provide a little more exposition on the examples and to compare her description of the algorithm with the description given in the Handbook of Applied Cryptography.  This is a derivative work and I do not claim to have originated any of the ideas here.  Of course, any mistakes are my own.

This test is discussed in many books including Practical Cryptography, Understanding Cryptography and the Handbook of Applied Cryptography.

Note: For the examples below, I group digits using commas as is the convention in the U.S.  All of the numbers are integers.

I'm not dead. Happy New Year!

I apologize if this blog is starting to look a little abandoned.  It's not (I promise) I just had to go on hiatus for a few months.

I started a new job in September (Director of Technology for a school district) and it has kept me very busy.  Over the new few months, I'm planning a handful of posts on technical topics plus a few about the realities of trying to run an IT department.

Here are the next three posts that I have in mind:

• Understanding Diffie-Hellman and the Discrete Logarithm Problem
• The Elliptic Curve Discrete Logarithm Problem
• Understanding Dual Elliptic Curve Deterministic Random Bit Generator (Dual EC DRBG)

Dual EC DRBG is the random number generator that the NSA supposedly put a backdoor into.  The first two posts that I'm planning are just to provide background information so that readers can understand the third one.  The third post will explain how Dual EC DRBG actually works and why it's susceptible to key escrow/backdoors.

Career prospects: going to grad school

I've recently been involved in several discussions about whether online schools are really helping their students.  In particular, do they prepare people for the job market?  I can't comment on how this works in other fields, although many are probably similar, but here are my thoughts on IT degrees:

The Oversell

I think that many schools oversell the value of their degrees.  A degree is useful and often required, but it's not a guaranteed ticket to your dream job.  Many schools report that X% of their graduates received a raise or promotion after graduating, but these are rarely automatic.  If you're considering going back to school, the burden is on you to figure out what a degree can do for you and how it fits into your career plan.

What is your narrative?

I've run into a few people who either have no work experience or who are in entry level jobs and have completed graduate degrees in IT.  I think education is a good thing and there's nothing inherently wrong with earning a graduate degree, but you have to think about how it fits into your personal narrative.

Attending an online for-profit school

A few years ago, I decided to go back to school to finish a bachelor's degree.  The school I ultimately chose was Capella University, an online for-profit college.  Online universities, and for-profits in particular, have a poor reputation, but I decided to attend anyway.  Here's my take on for-profit universities and why I plan to return to Capella to finish a master's degree.

Availability

I live in a small town.  When I started going back to school, there were no night-time or degree completion programs that I could take advantage of.  I would have loved to go back to school full-time and attend a well-regarded university, but I support a family and can't afford to relocate and quit work in order to go to school.  I needed a degree program that I could complete while working full-time.

Threat scenarios

When analyzing security features, we often look at them in black and white terms: either they can be broken or they can't.  DES is crackable but as far as we know AES is not so we recommend AES.  This is useful when we're making general recommendations because we don't know what threats everyone is going to be concerned about so it's safer to assume that we'll always need to protect against a skilled, well-funded attacker.  In many cases, however, that assumption is not true.

At Passwords 13, Steve Thomas, a.k.a. sc00bzT, gave a presentation about building a cheap hardware security module (HSM) to store and protect passwords.  During the talk, someone mentioned on IRC that what he developed wasn't a true HSM since the hardware was not tamper resistant.  While that is a valid concern, others correctly pointed out that it may not matter depending on your threat scenario.

Since it has no physical protection, Thomas's HSM is vulnerable to hardware tampering.  It should not be used in situations where that is a valid concern.  If you're worried about foreign governments bribing your employees or about a rogue employee (e.g. at a bank) being able to sell those credentials, then you should consider laying out the cash to get a tamper-resistant HSM.  But, if you're mostly worried about outsiders using SQL injection to dump your password hashes, this solution is perfect.  It's cheap and it solves the problem.

Passwords 13 - Next Week

I haven't posted anything lately, but I'm heading to Passwords '13 in Las Vegas next week and hope to come back with some new thoughts and ideas worth posting about.  In the mean time, here's a picture of my dog.

Basics: Avoiding SQL Injection

SQL injection is a pretty big deal.  The attack is easy to carry out, the vulnerabilities are prevalent and the payoff is potentially large.  Many of the password breaches reported over the last year or two are known or thought to have been carried out via SQL injection. 

SQL injection attacks allow attackers to execute arbitrary queries or commands against a database.  Developers introduce the vulnerabilities into their code when they concatenate or substitute user input into the elements of a SQL query.  In the following Python example, the program will accept any input as the "user_id" variable (returned as a part of login_data) and tack it onto the end of a string that is subsequently executed as a sql query:  

login_data = web.input()
query_string = "SELECT * FROM USERS WHERE ID = '%s'" %

login_data.user_id

cursor.execute(query_string)

Lessons from the S.C. breach

In October, the South Carolina Department of Revenue discovered that it had been breached and contacted Mandiant to assist in the investigation and response.  All told, millions of social security numbers and hundreds of thousands of bank/credit card numbers had been stolen.

In November, Mandiant published their findings.  This is exciting.  All we usually get is a news article lacking in technical detail.  This we can actually learn from.

My goal in this blog post is to explore what, in hindsight, the S.C. Department of Revenue could or should have done better. Please read the Mandiant report before you move on.

Lessons from the CCSF debacle

In January 2012, some fairly sensational news stories were published about a major data breach at City College of San Francisco.  According to the early reports, tens of thousands of student records may have been compromised.  Even more interesting, the reports said that some systems may have been infected for over a decade and that there were connections to China and Russia.  While the reports were interesting, they were short on details and I hoped to eventually read more after the school had some time to sort things out.

In May, the CTO of CCSF was suspended at least in part for his reaction to the breach.  The Guardsman, CCSF's newspaper, published a series of articles that described controversy within CCSF over the handling of the breach, the CTO's management and accusations that the breach was a false alarm.

The CTO's tenure sounds like it was a disaster.  It's also full of lessons for IT and security managers.

Wrapping up 2012

I've been really busy lately so I haven't blogged much.  Things are coming together pretty well here at the end of 2012.  Here's what's happening with me.

This summer, I won a free trip to Fishnet Security's iSWAT training event in Las Vegas through The Ethical Hacker Network.  I decided to take the CISSP review course.  I've been meaning to take the CISSP exam for a while, but it's been hard to find time to study since I'm working and in school full-time.  There were only three of us in class, but it worked out really well.  Instead of sitting in rows and listening to the instructor drone on for hours, we sat around a conference table and actually discussed things as we went over them.  Many of the discussions went well past what we needed for the exam, but I enjoyed the hell out of it.  It's not often that I get to spend an entire day talking about security.

My only complaint is that Fishnet was supposed to reimburse me for the CISSP exam (it was part of the package).  I was told a month ago that my reimbursement was being processed, but I haven't heard back and I haven't received anything.