Entries Tagged "RSA"

Page 4 of 6

The Cryptopocalypse

There was a presentation at Black Hat last month warning us of a “factoring cryptopocalypse”: a moment when factoring numbers and solving the discrete log problem become easy, and both RSA and DH break. This presentation was provocative, and has generated a lot of commentary, but I don’t see any reason to worry.

Yes, breaking modern public-key cryptosystems has gotten easier over the years. This has been true for a few decades now. Back in 1999, I wrote this about factoring:

Factoring has been getting easier. It’s been getting easier faster than anyone has anticipated. I see four reasons why this is so:

  • Computers are getting faster.
  • Computers are better networked.
  • The factoring algorithms are getting more efficient.
  • Fundamental advances in mathematics are giving us better factoring algorithms.

I could have said the same thing about the discrete log problem. And, in fact, advances in solving one problem tend to mirror advances in solving the other.

The reasons are arrayed in order of unpredictability. The first two—advances in computing and networking speed—basically follow Moore’s Law (and others), year after year. The third comes in regularly, but in fits and starts: a 2x improvement here, a 10x improvement there. It’s the fourth that’s the big worry. Fundamental mathematical advances only come once in a while, but when they do come, the effects can be huge. If factoring ever becomes “easy” such that RSA is no longer a viable cryptographic algorithm, it will be because of this sort of advance.

The authors base their current warning on some recent fundamental advances in solving the discrete log problem, but the work doesn’t generalize to the types of numbers used for cryptography. And they’re not going to generalize; the result is simply specialized.

This isn’t to say that solving these problems won’t continue to get easier, but so far it has been trivially easy to increase key lengths to stay ahead of the advances. I expect this to remain true for the foreseeable future.

Posted on August 19, 2013 at 6:47 AM • View Comments

Twitter's Two-Factor Authentication System

Twitter just rolled out a pretty nice two-factor authentication system using your smart phone as the second factor:

The new two-factor system works like this. A user enrolls using the mobile app, which generates a 2048-bit RSA keypair. The private key lives on the phone itself, and the public key is uploaded to Twitter’s server.

When Twitter receives a new login request with a username and password, the server sends a challenge based on a 190-bit, 32 character random nonce, to the mobile app—along with a notification that gives the user the time, location, and browser information associated with the login request. The user can then opt to approve or deny this login request. If approved, the app replies to a challenge with its private key, relays that information back to the server. The server compares that challenge with a request ID, and if it authenticates, the user is automatically logged in.

On the user end, this means there’s no string of numbers to enter, nor do you have to swap to a third party authentication app or carrier. You just use the Twitter client itself. It means that the system isn’t vulnerable to a compromised SMS delivery channel, and moreover, it’s easy.

Posted on August 8, 2013 at 12:20 PM • View Comments

Full Extent of the Attack that Compromised RSA in March

Brian Krebs has done the analysis; it’s something like 760 companies that were compromised.

Among the more interesting names on the list are Abbott Labs, the Alabama Supercomputer Network, Charles Schwabb & Co., Cisco Systems, eBay, the European Space Agency, Facebook, Freddie Mac, Google, the General Services Administration, the Inter-American Development Bank, IBM, Intel Corp., the Internal Revenue Service (IRS), the Massachusetts Institute of Technology, Motorola Inc., Northrop Grumman, Novell, Perot Systems, PriceWaterhouseCoopers LLP, Research in Motion (RIM) Ltd., Seagate Technology, Thomson Financial, Unisys Corp., USAA, Verisign, VMWare, Wachovia Corp., and Wells Fargo & Co.

News article.

Posted on October 28, 2011 at 3:21 PM • View Comments

Details of the RSA Hack

We finally have some, even though the company isn’t talking:

So just how well crafted was the e-mail that got RSA hacked? Not very, judging by what F-Secure found.

The attackers spoofed the e-mail to make it appear to come from a “web master” at Beyond.com, a job-seeking and recruiting site. Inside the e-mail, there was just one line of text: “I forward this file to you for review. Please open and view it.” This was apparently enough to get the intruders the keys to RSAs kingdom.

F-Secure produced a brief video showing what happened if the recipient clicked on the attachment. An Excel spreadsheet opened, which was completely blank except for an “X” that appeared in the first box of the spreadsheet. The “X” was the only visible sign that there was an embedded Flash exploit in the spreadsheet. When the spreadsheet opened, Excel triggered the Flash exploit to activate, which then dropped the backdoor—in this case a backdoor known as Poison Ivy—onto the system.

Poison Ivy would then reach out to a command-and-control server that the attackers controlled at good.mincesur.com, a domain that F-Secure says has been used in other espionage attacks, giving the attackers remote access to the infected computer at EMC. From there, they were able to reach the systems and data they were ultimately after.

F-Secure notes that neither the phishing e-mail nor the backdoor it dropped onto systems were advanced, although the zero-day Flash exploit it used to drop the backdoor was advanced.

Posted on August 30, 2011 at 6:25 AM • View Comments

RSA Security, Inc Hacked

The company, not the algorithm. Here’s the corporate spin.

Our investigation has led us to believe that the attack is in the category of an Advanced Persistent Threat (APT). Our investigation also revealed that the attack resulted in certain information being extracted from RSA’s systems. Some of that information is specifically related to RSA’s SecurID two-factor authentication products. While at this time we are confident that the information extracted does not enable a successful direct attack on any of our RSA SecurID customers, this information could potentially be used to reduce the effectiveness of a current two-factor authentication implementation as part of a broader attack. We are very actively communicating this situation to RSA customers and providing immediate steps for them to take to strengthen their SecurID implementations.

Here are news articles. The worry is that source code to the company’s SecurID two-factor authentication product was stolen, which would possibly allow hackers to reverse-engineer or otherwise break the system. It’s hard to make any assessments about whether this is possible or likely without knowing 1) how SecurID’s cryptography works, and 2) exactly what was stolen from the company’s servers. We do not know either, and the corporate spin is as short on details as it is long on reassurances.

RSA Data Security, Inc. is probably pretty screwed if SecurID is compromised. Those hardware tokens have no upgrade path, and would have to be replaced. How many of the company’s customers will replace them with competitors’ tokens. Probably a bunch. Hence, it’s in RSA’s best interest for their customers to forget this incident as quickly as possible.

There seems to be two likely scenarios if the attackers have compromised SecurID. One, they are a sophisticated organization who wants the information for a specific purpose. The attackers actually are on RSA’s side in the public-relations spin, and we’re unlikely to see widespread use of this information. Or two, they stole the stuff for conventional criminal purposes and will sell it. In that case, we’re likely to know pretty quickly.

Again, without detailed information—or at least an impartial assessment—it’s impossible to make any recommendations. Security is all about trust, and when trust is lost there is no security. User’s of SecurID trusted RSA Data Security, Inc. to protect the secrets necessary to secure that system. To the extent they did not, the company has lost its customers’ trust.

Posted on March 21, 2011 at 6:52 AM • View Comments

768-bit Number Factored

News:

On December 12, 2009, we factored the 768-bit, 232-digit number RSA-768 by the number field sieve. The number RSA-768 was taken from the now obsolete RSA Challenge list as a representative 768-bit RSA modulus. This result is a record for factoring general integers. Factoring a 1024-bit RSA modulus would be about a thousand times harder, and a 768-bit RSA modulus is several thousands times harder to factor than a 512-bit one. Because the first factorization of a 512-bit RSA modulus was reported only a decade ago it is not unreasonable to expect that 1024-bit RSA moduli can be factored well within the next decade by an academic effort such as ours…. Thus, it would be prudent to phase out usage of 1024-bit RSA within the next three to four years.

[…]

Our computation required more than 1020 operations. With the equivalent of almost 2000 years of computing on a single core 2.2GHz AMD Opteron, on the order of 267 instructions were carried out. The overall effort is sufficiently low that even for short-term protection of data of little value, 768-bit RSA moduli can no longer be recommended.

News articles.

Posted on January 11, 2010 at 8:00 AM • View Comments

Texas Instruments Signing Keys Broken

Texas Instruments’ calculators use RSA digital signatures to authenticate any updates to their operating system. Unfortunately, their signing keys are too short: 512-bits. Earlier this month, a collaborative effort factored the moduli and published the private keys. Texas Instruments responded by threatening websites that published the keys with the DMCA, but it’s too late.

So far, we have the operating-system signing keys for the TI-92+, TI-73, TI-89, TI-83+/TI-83+ Silver Edition, Voyage 200, TI-89 Titanium, and the TI-84+/TI-84 Silver Edition, and the date-stamp signing key for the TI-73, Explorer, TI-83 Plus, TI-83 Silver Edition, TI-84 Plus, TI-84 Silver Edition, TI-89, TI-89 Titanium, TI-92 Plus, and the Voyage 200.

Moral: Don’t assume that if your application is obscure, or if there’s no obvious financial incentive for doing so, that your cryptography won’t be broken if you use too-short keys.

Posted on September 25, 2009 at 6:17 AM • View Comments

1 2 3 4 5 6

Sidebar photo of Bruce Schneier by Joe MacInnis.