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?
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.
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.
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.
But sadly, I have to agree, this is epic fail.
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.
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.
From what I understand, they use the same number every single time without exception.
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.