Tuesday, March 9, 2010

Recovering RSA Private Keys using Faulty Signatures

Researchers at University of Michigan recently devised a method for recovering the RSA private key used for signing by sifting through a collection of faulty signatures produced by the key. A faulty signature is one where the attacker has caused bits in the signature computation to be flipped from one to zero, or zero to one. Fault patterns that consist of just a single flipped bit permit an attacker to guess and verify a small piece of the private key (called a window), and to eventually recover the entire private key given a sufficient number of such faulty signatures. The researchers ran proof-of-concept experiments to demonstrate that a 1024-bit RSA private key can be recovered from a sample of just under 9,000 faulty signatures created by manipulating the voltage level to the processor computing the signatures.

There are two main ingredients to the attack: a method to recover information about the private key given some faulty signatures, and then a method to actually generate or induce the faulty signatures. We deal with the second point first.

Generating Faults Through Power Fluctuations

The researchers chose to exploit vulnerabilities in modern circuitry to changes in environmental conditions (such as temperature or power fluctuations) that inhibit signal propagation, which lead to faults in computations. The researchers experimented with varying the voltage on a SPARC-based Leon3 server running Debian, using OpenSSL for signing operations. Using runs of 10,000 multiplications the researchers discovered that 1.25V was the optimal value to induce single fault errors, and that reducing the voltage much further resulted in an exponential increase in faults (totally spurious results).

image

At this optimal voltage level the researchers found that from a sample of 10,000 signatures about 90% would contain at least one fault, and 12% contained exactly one fault. Note that the attacker can distinguish between faulty and non-faulty (correct) signatures by verifying with the public exponent, but cannot distinguish a priori between faulty signatures that contain one fault as opposed to those that contain multiple faults. As explained below, the most computationally intensive part of recovering the private key is performing repeated searches over the pool of faulty signatures looking for a particular single fault pattern.

Guessing and Verifying Exponentiation Windows

The signature of a message M is computed as the exponentiation M^D mod N where D is the private RSA exponent, and N the corresponding modulus. Exponentiation is computationally intensive, and is achieved through repeated (modular) multiplication. The well-known binary method computes M^d mod N by processing D bit-by-bit from left-to-right (most significant to least significant bit) in a series of squarings and multiplications. The binary method can be improved upon by processing the exponent in groups of bits, say 4 bits at a time. This approach is called the m-ary method and the groups of exponent bits are called windows (the binary method can be thought of as the 1-ary method, processing 1-bit windows).

At each step in the signature computation, m squarings are performed followed by a single multiplication if the window is non-zero. The attack devised by the researchers works by recovering the bits in the most significant window, followed by the next most significant window, until the entire private key is recovered. If the current window targeted for recover is window W, then the attacker requires a faulty signature on M such that a single fault was induced during the processing of the exponent bits represented by W.

The researchers derive an equation that involves the message to be signed M, the faulty signature S, the value of the window W, the position of the fault, and the sign of the fault (add or subtract). By equation here we mean an expression that has a left-hand side and a right-hand side which can be compared for equality. The attacker can then plug all possible values of W, the position fault and fault sign into this equation and collects solutions. There will either be no solutions, one (unique) solution, or more than one (multiple) solution. In the first and last cases, no information about D can be extracted since either the fault did not occur during the multiplication for W, or there are multiple faults in S. and another pair (M, S) must be examined. If the solution is unique then the bits of W are determined and the attacker can move on to breaking the next window using the same guess-and-verify approach.

The search for a given pair (M, S) that has a single fault in a position covered by a specified window W is computationally intensive. If S is a faulty signature then the attacker cannot easily determine the number or position of the faults in the signature. The researchers generated 10,000 signatures, of which 8,800 were faulty, and tried to recover the 1024-bit exponent. Using an 81-processor cluster this took 104 hours, with the guess-and-verify step for each window taking 2.5 seconds. The private key was recovered after 650 single fault signatures processed.

image

Conclusion

The Register has headlined the announcement as breaking OpenSSL, but this unfair. OpenSSL was used in the experiments but other libraries are also likely to be vulnerable to restricting voltage to induce hardware faults. As to the practicality, the attacker is required to have physical access to the device housing the private key, and be able to request or observe 10,000 or so signatures, computed under reduced voltage. These seem to be quite generous circumstances for the attacker, and given such proximity the attacker may prefer to try for a Cold Boot Attack instead. In any case, the attack shows the importance of verifying the correctness of signing operations – all the faulty signatures could be detected by merely checking that M = S^E before returning any results. Apparently this is what OpenSSL developers are doing at the moment.

Monday, March 8, 2010

More Microsoft SDL Giveaways

Recently Microsoft published a simplified version of their SDL methodology, reducing the detail in the hope of making implementations a bit easier. Microsoft has also made available its four core SDL Training classes (introductions to SDL & Threat Modeling, Basics of Secure Design, and Privacy for SDL) as well as the supporting tools. Finally, Adam Shostack has also made available Elevation of Privilege, the Threat Modeling Game, which he thinks is the easiest way to get started threat modeling – just try it!

Sunday, March 7, 2010

Passwords for USB Keypads

Bruce Schneier recently posted about a new USB stick that comes with its own on-board numeric keypad, permitting a password consisting of digits to be entered directly into the USB device to authorize unlocking. Such a stick and keypad would circumvent the recent USB password vulnerability that was derived from a poor implementation of password verification on the desktop.

image

The stick in question from Corsair (shown above) also uses AES-256 encryption to protect the data on the stick. The AES-256 key for the stick is then likely to be derived from the user-supplied password (say using PKCS #5 or RFC 2898), or used to protect a file which contains a full-length 256-bit key. In either case the 256-bit key will be derived from, or protected by, a password which has a much lower entropy.

Bruce points out that a 77-digit password would be needed to produce the same entropy as a 256-bit key (since the logarithm to the base 10 of 2^{256} is about 77 ). I made the same point in Are AES 256-bit keys too large? where I calculated that a password based on the 94 printable ASCII characters would need to be 40 characters in length to achieve the same entropy of a 256-bit key (since the logarithm to the base 94 of 2^{256} is about 40). Deriving or bootstrapping AES keys from passwords is really an exercise in self-deception, especially when considering 256-bit keys. The discrepancy between the low entropy of passwords and the astronomical keyspace of AES-256 simply cannot be reconciled.

Perhaps the situation would improve if a biometric such as a fingerprint was used to bootstrap a 256-bit key. I did some research about a year ago and posted what I found in On the Entropy of Fingerprints. Some work has been done by IBM researchers who estimate the entropy of fingerprints to be at most 85 bits, or approximately the same as a length 13 password based on the 94 printable ASCII characters. An improvement, but still a long way from 256 bits of entropy.

Monday, March 1, 2010

RSA-512 factoring service: two weeks effort for $5,000

Ron Kane is offering a service to factor 512 RSA keys for a cost of about $5,000, taking two weeks or so. He describes the service as

Estimation on calculating the private key is 2 weeks (we have 2 separate clusters running, sometimes its rented to another company) .

We will be calculating on our private cluster / super computer, no groups / companies / other individuals involved, your private key will not be exposed to the internet anywhere!


Your private key will be sold once, only to you. In case someone else asks us to factor the same numbers, we will decline the request.


How we work:

  • You make a down payment
  • We will start calculating the key
  • When the private key is ready, we will sign something with it and send it to you to verify it
  • You pay us the remaining sum we agreed
  • We give you plain numbers, or we can embed the private key in a smartcard (multos or JCOP)

You can contact him here, but if you are a bit more patient you can do it yourself. Some recent sampling results showed that a few percent of web servers are still running 512-bit keys.

Saturday, February 27, 2010

Month Summary, Feb 2010

A quick summary of this month’s posts

Security

SSL

Risk

Visualization

Other

A look back, Jan – Feb 2009

As the No Tricks blog steadily builds up a body of posts (about 150 now), I can look back a year or so and even surprise myself at what I was posting about. Here are most of the topics I was considering early in 2009.

Opinion and Information

Twitter

Scribd

Visualizations

image

Friday, February 26, 2010

A Short Security Manifesto

From the Falcon's View

Stop talking about traditional "risk management" as some sort of magical rubric or panacea.
Start talking about threat modeling and legal defensibility.

Stop using ad hoc approaches to security architecture and solutions.
Start adopting a holistic, systemic ISMS-like approach.

Stop delegating ownership of security to IT or other non-business leadership.
Start requiring execs and the board to directly own and be responsible for security.

Stop relying on shortcuts to survive audits.
Start demonstrating actual due diligence by adopting a reasonable standard of care.

Stop looking for ROI to "justify" security.
Start thinking of security as a business enabler that facilitates better decisions and helps protect the business during both the good and the bad times.

Thursday, February 25, 2010

USB devices back on duty for the DoD

The US DoD has tentatively rescinded its universal ban on USB devices issued over a year ago, reintroducing them under controlled conditions and for limited use, as reported by Stars and Stripes. The DoD introduced the draconian ban to prevent malicious software from infecting defence networks. However it seems that the combat need to transfer data quickly and conveniently has trumped any blanket security veto. The new devices can only be connected to military networks, and used for data transfer when network resources are unavailable or overloaded. In short, as a method of last resort.

According to Defence News, the drives are designed so that they can be tracked by system administrators, are password-protected, and store information in encrypted form. Additional features include on-board anti-virus software and security rules that prevent copying or forwarding of certain information from the drive or saving unapproved information on the drive.

The move may seem somewhat untimely since suppliers of secure USB sticks are still reeling from a vulnerability that permits password-protection to be bypassed. Wired reported on the announcement as saying that both hackers and troops will be rejoicing.

NodeXL: Network Overview, Discovery and Exploration in Excel

Microsoft Research has released a new Excel 2007 add-in for rendering network visualizations

NodeXL is a powerful and easy-to-use interactive network visualisation and analysis tool that leverages the widely available MS Excel application as the platform for representing generic graph data, performing advanced network analysis and visual exploration of networks. The tool supports multiple social network data providers that import graph data (nodes and edge lists) into the Excel spreadsheet.

The graph visualizations seem stunning for Excel. An example is shown below from Visual Business Intelligence, where the graph depicts shared Board memberships of major US companies.

image

More information on using NodeXL and the external people Microsoft collaborated with to create the tool can be found here at CodePlex.

A dissection of Koobface

There is a very informative analysis of the social network trojan Koobface at abuse.ch. The analysis details the four stages of the victim infection, which involves malicious shorts links, registering false Blogger accounts and hijacked web sites serving out malicious javascript. At the time of writing (early December last year), there were just over 34,000 malicious blogposts and short URLs, directing victims to over 500 hijacked websites. Ultimately code is downloaded onto the victim machine to make it part of the Koobface command & control infrastructure.

A CAPTCHA breaking infrastructure is used to register new accounts with Blogger, as shown below.

image 

According to the post, the infrastructure is very sophisticated:

  • The time between grabbing a CAPTCHA and breaking it is less than three minutes (most of the time just a few seconds!)
  • Due to the way how Koobface’s infrastructure works, it’s possible to break hundreds of CAPTCHA per minute!
  • In this way it’s possible to register thousands of fake bit.ly/Blogspot accounts per day

The author wonders if the security industry is placing too much faith in CAPTCHAs.

Tuesday, February 23, 2010

Major Risks in the IT Industry

Researchers at the University of Wisconsin, from the Actuarial and Insurance department, conducted a study on risk terms in 2007. The study involved comparing notions and definitions of various terms in risk across several sectors and industries, including Information Technology (IT). The IT respondents listed the following major risks for their industry (click to enlarge)

image

The researchers noted that the IT sector had the largest number of risks. By way of comparison, the major risks for the energy industry looked like this

image

Notice that IT Failure risk is on the list but very much towards the bottom.

Metrics for Managing Project Risk

I was in a bookstore over the weekend and saw of copy of Identifying and Managing Project Risk by Tom Kendrick from HP. The book was published last year but I know of his work on project risk metrics from an earlier whitepaper that really showed how to get a handle on measuring and managing project risks.

Here are some examples of predictive risk metrics which serve as a distant early warning system for project difficulties.

Project size/scale risk

  • Project duration (elapsed calendar time)
  • Total effort (sum of all activity effort estimates)
  • Total cost (budget at completion)
  • Size-based deliverable analysis (component counts, number of major deliverables, lines of non-commented code, blocks on system diagrams)
  • Staff size (full-time equivalent and/or total individuals)
  • Number of planned activities
  • Total length (sum of all activity durations if executed sequentially)
  • Logical length (maximum number of activities on a single network path)
  • Logical width (maximum number of parallel paths)

Schedule risk

  • Activity duration estimates compared with worst-case duration estimates
  • Number of critical (or near-critical) paths in project network
  • Logical project complexity (the ratio of activity dependencies to activities)
  • Maximum number of predecessors for any milestone
  • Total number of external predecessor dependencies
  • Project independence (ratio of internal dependencies to all dependencies)
  • Total float (sum of total project activity float)
  • Project density (ratio of total length to total length plus total float)

General risk

  • Number of identified risks
  • Quantitative (and qualitative) risk assessments (severity analysis)
  • Adjusted total effort (project appraisal: comparing baseline plan with completed similar projects, adjusting for significant differences)
  • Survey-based risk assessment (summarized risk data collected from
    project staff, using selected assessment questions)
  • Aggregated overall schedule risk (or aggregated worst-case duration estimates)
  • Aggregated resource risk (or aggregated worst-case cost estimates)

And the last example, the Dilbert Correlation Factor: collect 30 recent Dilbert cartoons and circulate to staff. Have people mark each one that reminds them of your organization. If the team average is

  • under 10: Low organization risk.
  • 10-20: Time for some process improvement.
  • Over 20: Hire a cartoonist and make your fortune….)

Sunday, February 21, 2010

Simplified implementation of the Microsoft SDL

Microsoft has announced a new 17-page whitepaper that presents a simplified version of their Security Development Lifecycle (SDL). From the announcement

One of the common misconceptions about the Microsoft SDL is that you have to be an organization the size of Microsoft in order to be able to implement it. Another misconception is that the SDL is only appropriate for Microsoft languages and Microsoft platforms, and that you need to use some other methodology if you’re writing code with Ruby for OS X. The Simplified SDL white paper helps address these misconceptions by explaining how the SDL can be implemented with limited resources and applied to any platform.

image

Why use SSL?

Here is a short introductory post on the advantages of using SSL, and a nice FAQ as well. Cost and performance are listed as the main disadvantages. However you may want to also check out How to Render SSL Useless from Ivan Ristic and the additional comments here at Pat’s Daily Grind.

image

When to use Pie Charts

image

from Emergent Chaos.