Safecracking for the Computer Scientist

secureman writes "It looks like Matt Blaze (the University of Pennsylvania CS professor best known for finding security flaws in the NSA Clipper Chip and in master keyed locks) is still causing trouble in physical security circles. There's a draft paper (dated December '04) on his web site entitled Safecracking for the Computer Scientist, which is a pretty in-depth look at what computer security can learn from safes (and vaults). The interesting thing is that it describes in detail the different ways that safes are cracked, probably revealing techniques that locksmiths would rather you didn't know about (there's a lot of security-by-obscurity there). The conclusion seems to be that while safes can fail, at least they do so in better ways than computer systems do. Warning: it's a 2.5 meg pdf file with lots of pretty pictures."

Comments

A point well made

[gateman9]

I think his comparison is on to something here.

A good safe is designed in layers, so that to get in, you have to break through each layer. And the more layers, the more time it takes. Safe-makers know no safe is completely secure, and all safes are crackable.

Time is the enemy of anyone looking to commit theft/robbery, whether that person is working physically or digitally. So the longer it takes the more secure the system it is.

While we defeinitely know security by obfuscation is stupid in terms of computer security, safety by layers makes sense.

If there were several layers of encryption (asymmetrical and symmetrical), compromising the system takes more time, and if one layer fails, the game isn't over just yet.

Admittedly secure traffic would be much slower than unsecured traffic, the benefits of this kind of layered approach would be more than worth it for data that needs to be as secure is possible.

general coding v. coding for security: assumptions

[G4from128k]

The challenge for IT security is that computer science loves to use abstractions, encapsulation, APIs, libraries and what not that let the programmer ignore the details of the internal complexity of systems. The problem is that it leads one to assume that these systems behave in some idealized fashion (the logical, black-box model of the system). In reality, the systems don't always follow the assumed logical model or the ignored internals create side-effects that are unforeseen by the original programmer, but exploited by malicious actors.

For example, assumptions about metadata and syntax give rise to buffer overflow or malformed string exploits. In trusting that an input string will be its stated length or follow the official syntax, the programmer adheres to the logical model of the system but creates a vulnerability. Similarly, physical power consumption artifacts can let a cracker guess the state or internal activities of a smartcard encryption chip. The original programmer is unaware that the code creates these artifacts since most coding paradigms ignore issues such as the exact execution time of subroutines, power consumption of CPU instructions, etc.

Becoming security conscious means unlearning all the tricks that let a programmer ignore the complexity inside a system. It means understanding the real behavior of all the internals, all the side-effects, and all the system properties that might be observable or influenceable by a malicious party. That makes programming for security very different and very much harder that standard programming.

To mangle a metaphor, security means that one must peel the onion to ensure that it does not have contain an open door in its core.

Similar

[irefay]

Similarly, you can have as many security layers as you wish but if you forget to weld the back end of the safe or network on than they still do nothing for security... your only as secure as your weakest point of security.

Re:Massive Keyspace?

[charyou-tree]

I can't count how many times I have read "...will take longer than the age of the Universe itself to brute force this /insert encryption scheme of choice here/..." when reading about some new fangled encryption scheme. Naturally, that claim is based on computational power at the time, but doesn't this exactly dispute his claim?

No. Physics gets involved ... From Schneier's Applied Cryptography page 157:

One of the consequences of the second law of thermodynamics is that a certain amount of energy is necessary to represent information. To record a single bit by changing the state of a system requires an amount of energy no less than k T, where T is the absolute temperature of the system and k is the Boltzman constant. (Stick with me; the physics lesson is almost over.)

Given that k = 1.38*10^-16 erg/deg Kelvin, and that the ambient temperature of the universe is 3.2 deg Kelvin, an ideal computer running at 3.2 deg Kelvin would consume 4.4*10^-16 ergs every time it set or cleared a bit. To run a computer colder thant the cosmic background radiation would require extra energy to run a heat pump.

Now the annual energy output of our sun is about 1.21*10^41 ergs. This is enough to power about 2.7*10^56 single bit changes in our ideal computer; enough state changes to put a 187-bit counter through all its values. If we built a Dyson sphere around the sun and captured all its energy for 32 years, without any loss, we could power a computer to count up to 2^192. Of course, it wouldn't have the energy left over to perform any useful calculations with this computer.

But that's just one star, and a measly one at that. A typical supernova releases something like 10^51 ergs. If all of this energy could be channeled into a single orgy of computation, a 219-bit counter could be cycled through all of its states.

These numbers have nothing to do with the technology of the devices; they are the maximums that thermodynamics will allow. And they strongly imply that brute-force attacks against 256-bit keys will be infeasible until computers are built from something other than matter and occupy something other than space.

IOW, you can't brute-force a 256-bit key.