[Swannie]

I'm not sure if that was hyperbole or not.

As I understand it, all that was required was for them to use the same random number /twice/. Let's say you're Sony and you sign a patch, release it, realise there is a minor fix, and release within 2hours... maybe in your rush you failed to regenerate the random seed?

Or, my initial thoughts, someone inside Sony did this maliciously?

[JonnieCache]

If your build process requires you to manually generate a random number and copy and paste it in, you need to try harder. If you work for a bank handling payments, you should be fired and never allowed to work in software again.

EDIT: that last bit about banks is OT, sorry about that, I've been watching the chip and pin hacking talk from CCC and got confused.

[uxp]

Personally, I don't think the domain matters. If a developer is required to provide security, either to protect a secret, maintain personal or company profits, or protect customer finances, and that developer fails by "int rand() {return 4;}", that developer should never work with technology again.

[Swannie]

I agree. It is unlikely that the release manager would have been expected to generate a random number. I'd have expected, possibly, a pre-generated list of random numbers, maybe 1000 or so, so a duplicate is not unlikely, and cannot happen maliciously.

I find it most likely that the build process code was flawed. This sort of code is, in my experience, not written by your most talented developer (unless one of your top developers has a build fetish). All too often you only find deficiencies in the build/release process the month of release, when you have the least time to fix them.

[JonnieCache]

If the whole project is about signing code packages to prevent the platform being hacked, you would've thought the key generation would be considered a critical part of the application code, rather than a detail of the build process. Even if the code necessarily exists in the build script. The build script is the project in this case.

If a developer has ever even thought about generating a list of 1000 random numbers to pick from at a later date, then they shouldn't be developing production code.

[phirephly]

Yeah. You don't generate a list. You have make automatically dd 16 bytes from /dev/random, pipe it through hexdump, and then use that as your seed. You don't even have to check for dupes. There are 3.4 * 10^38 possible keys; You will not pick the same one twice.

That way, you can't even accidentally reuse a seed in development, or leak that list of the previously used seeds. When something compromises the system, and you don't need it any more, it should be destroyed.

[Swannie]

I was suggesting a one time list. You need to keep a list of past random numbers anyway so you can verify no repeats.

But sadly, I have to agree, this is epic fail.

[JonnieCache]

You are probably more likely to spontaneously rearrange your constituent atoms into cheese or something than to generate the same random 16 bytes twice, assuming a new number needs to be generated only once for each package of code signed. If there was one needed for each packet on a network or something it might be different.

In any case, this risk is orders of magnitude lower than the risk of someone leaking your list of past numbers, especially when they're this valuable.

[marshray]

Even worse, if you are using a list to eliminate the possibility of repeats then you aren't generating a perfect random distribution any more. The possibility of repeated numbers, however small, is explicitly allowed.

[gnaffle]

No, it was parabole. :)

From what I understand, they use the same number every single time without exception.

[Swannie]

That's really quite astounding. Thanks.

[stcredzero]

maybe in your rush you failed to regenerate the random seed?

Or, my initial thoughts, someone inside Sony did this maliciously?

As always, the human factor is the real weakness. (Key management by users and coders.) There are similar problems with RSA signatures on related numbers or selecting keys for IDEA block cipher and RC4 stream cipher, just to name a few. If you use crypto tools incorrectly, you actually put yourself in a somewhat weaker position than if you hadn't even tried. What you've essentially done is create "security theater" for the bad guys to dupe the unsuspecting with.

[Omega191]

No, it works on any two binaries.