1x1



SEPTEMBER 17, 2002

SECURITY NET
By Alex Salkever

Scary Tales from the Cryptologist
Information-security expert Paul Kocher is worried because as programs grow larger, identifying flaws becomes increasingly harder


  STORY TOOLS
Printer-Friendly Version
E-Mail This Story

Related Items
Security Net Archive

POLL INSTANT SURVEY >>
With which of the following statements on outsourcing do you most agree?

The benefits of outsourcing to corporate America far outweigh the costs
There's an even split between the drawbacks and rewards
Any benefits are overshadowed by the loss of U.S. jobs
Unsure

VIEW POLL RESULTS >>
  PEOPLE SEARCH

Search for business contacts:

First Name :
Last Name :
Company Name :

PREMIUM SEARCH
Search by job title, geography and build a list of executive contacts

Search by Zoominfo
  Tech White Papers
Most Recent
Most Popular
In 1995, Paul Kocher caught the attention of information-security experts when he unveiled a method for cracking a handful of commonly used computer codes by timing how long it took for computers to process requests using those code algorithims. Today, Kocher remains a prominent voice in the cryptography field. As head of Cryptography Research, he and his small band of San Francisco-based cryptographers are paid by banks and credit-card companies to "hack" their products in hopes of uncovering system vulnerabilities.


Far from being an unqualified believer in cryptography, however, Kocher is deeply concerned. What worries him is that the tried and true methods, which rely on increased computing power to crack codes, will fall behind in their capacity to solve information-security problems. I recently spoke with Kocher about encryption's looming challenges. Here are edited excerpts from our conversation:

Q: More and more companies are claiming to use very advanced cryptography or to have very secure systems. Should we believe them?
A: There's a general assumption that, as computers get faster, security should improve. That's [basically] correct. When you double the speed of the computer, you can encrypt with larger and larger keys. But while a computer that runs twice as fast can use encryption that's twice as large, cracking that encryption requires far more than twice as much power.

In other words, the amount of power required to crack longer keys increases much faster than the amount of power required to operate encryption products with longer keys. That means, mathematically, the amount of power required to crack longer keys will never keep up with the ability to effectively use these longer keys on computer systems.

What we're discovering is that while cryptography can be made stronger, as computers become faster and storage systems become larger and computer code grows to fit these systems, the initial complexity that results from the added code makes computer systems less secure, not more secure.

Q: How, specifically, does the size of the code affect security?
A: You can see this complexity in lots of ways. One is the in the number of lines of code running on the PC you're typing on -- probably many millions of lines of code. If you go back a few years, you could really understand everything that was going on inside the system. Today, I don't know if any single person alive knows everything going on inside the PC.

What happens is, the probability of having a security failure increases rapidly as the complexity of the systems increase. We have developed tools for generating, producing, and filling these complex systems. We haven't figured out a way to get the bugs out.

This is almost obvious when you [install] the latest version of Microsoft Windows. Everyone has an expectation that it will have security problems. And the reason for it isn't that there's anything fundamentally broken about the security model. It's that when you have so many lines of code and that much complexity, no one knows how to make the system reliably secure.

We are the guys responsible for making these systems secure. And we are not getting smarter. The complexity of the systems that our customers are giving to us is going up very rapidly. What we're having to tell these customers is that we charge you a lot of money to look at your code -- but, at the end of the day, there's no way you'll able to have any confidence that no bugs are in your system. It's just too complicated.

Q: Is it a mathematical impossibility to make secure systems when you have this many lines of code in play?
A: Impossibility is a difficult word. There's nothing fundamentally that makes it impossible for something to be bug-free. It's more a reflection on human fallibility and statistics, that if you're going to write something many millions [of] lines long, you'll have an error in it the same way that if you're running a story that's 1 million pages long, you'll have a typo in it -- unless you were willing to make some incredible investment in editing. And few can afford to make that investment.

Q: Why haven't past attempts at standardizing software code been more successful at stamping out bugs?
A: Every 18 months or so, the number of lines of code doubles. There have been shifts that give you temporary reprieves, but they aren't a lasting solution because they don't get that "bug density" down to zero.

Q: We're getting to the point in computer power where you can run very formidable cryptography to hide everything happening on a computer. Why hasn't cryptography been able to paper over all the little bugs and errors in making machines safer?
A: Cryptography can solve only certain security problems. It's kind of like [having] perfectly good bricks for building buildings. It doesn't solve all structural-engineering problems. One of those problems that cryptography can't solve is correctness of implementations.

I know at my company when we build systems, we'll spend 10 times as much money and effort testing our work as we do writing the original code. That's pretty unusual, but we have an unusual mix of customers.

Q: Is there a better way to test implementation?
A: That's a problem I don't have a solution to, and I wish I did. Testing security systems requires intelligence. There has been a lot of work trying to build processes like that. There's a standard called FIPS 140 that the U.S. government puts out.

Products that are used for sensitive, but not necessarily classified, communications are supposed to comply with that. But it misses a lot of problems. What it does force engineers to do is document what they've done carefully and to think about it. But we have found plenty of problems with FIPS 140-approved products.


Salkever is Technology editor for BusinessWeek Online and covers computer security issues weekly in his Security Net column
 Edited by Douglas Harbrecht
Get BusinessWeek directly on your desktop with our RSS feeds.XML

Add BusinessWeek news to your Web site with our headline feed.

Click to buy an e-print or reprint of a BusinessWeek or BusinessWeek Online story or video.

To subscribe online to BusinessWeek magazine, please click here.

Learn more, go to the BusinessWeekOnline home page
Back to Top
SEPTEMBER
[an error occurred while processing this directive]


Copyright 2002, Bloomberg L.P.
Terms of Use | Privacy Policy

Media Kit | Special Sections | MarketPlace | Knowledge Centers
Bloomberg L.P.