> Do you mean they should have pre-encrypted the CC number before encrypting it again in the standard SSL transaction? Would that have helped? Because if the PS3 knows how to encrypt and you own the server, decrypting is as trivial as just looking at the plain text
You are wrong; They could have done that. That's the whole premise of public key cryptography (google/wikipedia if you are not familiar). It's possible, (and easy) for the client to encrypt something that a client cannot in general decrypt, nor can anyone else without the decryption key. And it is actually a good idea to not put the decryption key on the server you talk to - only on a server that actually talks to the payment gateway.
> And how would you use that hashed CC number on the server? Unhashing (impossible)? Send the hash to the CC company (good luck)?
Many credit card processors let you do something similar - i.e. you register the CC details once, get a "reference id", and then use that reference id to charge. I'm sure Sony could have used one of them if they cared.
> For people who don't own the server and are listening in SSL is enough and for people with access to the server neither SSL nor any other encryption is enough.
That is true. However, that is just one facet that needs defense, and one that has had almost no attacks in the last 5 years -- because SSL (if practiced correctly, which it rarely is) solves that problem, and attacking the server is usually easier than listening on the pipes.
> They have done a lot of things wrongly, but this IMHO is not one of them.
Everything they have done about this is wrong. And the fact you think they didn't, implies that you shouldn't be working on systems that have any sensitive information in them. I sincerely hope you don't, for the sake of your users.
It's possible, (and easy) for the client to encrypt something that a client cannot in general decrypt, nor can anyone else without the decryption key.
And that's exactly how your typical SSL/TLS handshake works.
The problem is how does the client know he's encrypting to the correct public key? He has to have something stored giving him the key in advance or telling him how to authenticate the public key he's asked to use.
This is how the protocol messages were decrypted. The hackers modified their own console to trust a new public key, one to which they had the private key.
> And that's exactly how your typical SSL/TLS handshake works.
True.
> The problem is how does the client know he's encrypting to the correct public key? He has to have something stored giving him the key in advance or telling him how to authenticate the public key he's asked to use.
True again. In the SSL/TLS, this is the "trusted roots" certificates, that the browser was created with.
Why wouldn't the PS3 have a "trusted root" as such?
> This is how the protocol messages were decrypted. The hackers modified their own console to trust a new public key, one to which they had the private key.
Cool. But that doesn't let them decode _other_ clients' transmissions -- much like putting a new root certificate in your own browser doesn't make a session less secure for anyone else.
Sony made many mistakes here, most of them due to either extreme hubris or extreme incompetence.
But that doesn't let them decode _other_ clients' transmissions -- much like putting a new root certificate in your own browser doesn't make a session less secure for anyone else.
Right, we don't know that's happened yet, except we hear that Sony's backend systems were compromised too. That could be completely unrelated, or the client and server hacks could combine in a way that makes every PS3 compromised. I find it an interesting question but we probably have to wait for more details from Sony.
You are wrong; They could have done that. That's the whole premise of public key cryptography (google/wikipedia if you are not familiar). It's possible, (and easy) for the client to encrypt something that a client cannot in general decrypt, nor can anyone else without the decryption key. And it is actually a good idea to not put the decryption key on the server you talk to - only on a server that actually talks to the payment gateway.
> And how would you use that hashed CC number on the server? Unhashing (impossible)? Send the hash to the CC company (good luck)?
Many credit card processors let you do something similar - i.e. you register the CC details once, get a "reference id", and then use that reference id to charge. I'm sure Sony could have used one of them if they cared.
> For people who don't own the server and are listening in SSL is enough and for people with access to the server neither SSL nor any other encryption is enough.
That is true. However, that is just one facet that needs defense, and one that has had almost no attacks in the last 5 years -- because SSL (if practiced correctly, which it rarely is) solves that problem, and attacking the server is usually easier than listening on the pipes.
> They have done a lot of things wrongly, but this IMHO is not one of them.
Everything they have done about this is wrong. And the fact you think they didn't, implies that you shouldn't be working on systems that have any sensitive information in them. I sincerely hope you don't, for the sake of your users.