At this point, I think that any good undergrad computer engineering education should include a class on practical security patterns, and design for security. Or, at the very least, training on when you need proactively call on a developer with better chops.
It would save the world so, so much grief and cheap insecure consumer devices. I will flip my lid if I see another kiddy-cam on Shodan.
I don't think the the conclusion is right. It's just that the security had cost money, why pay a developer for 5 days when he can do it in 3 without proper security? There is no proper security needed, so don't pay for it. And thats exactly the same that happens with bigger software too. As long as it doesn't creates pain for the seller to sell insecure tools, they will stay insecure.
This seems like it's missing the forest for the trees. The point of security measures is to make executing the attack more expensive than the expected payoff of successfully executing it.
What is the payoff here? Is the projector sold below cost and is the manufacturer recouping that via the cartridges? If not, what's the loss to them?
Regarding the proposed mitigations, I'm very doubtful on whether they would substantially change anything here:
> Use real crypto (AES-128 or lightweight stream) and make the cartridge carry per-title key (or an IV)
> Copying now requires cloning/extracting the original token secrets.
Sounds like a great idea, and fortunately we don't even need to speculate about whether it would work: Nintendo did this with Amiibo.
> If true anti-cloning matters, this requires an authenticated token (DESFire / NTAG 424 DNA class).
And where do you securely store the validation key for a symmetric encryption/authentication scheme? This would require adding a SAM to the projector as well.
The "use non-default NFC keys" suggestion shares the same problem: Where would you securely store these?
If your keys are in 3/4 parts, that's probably sufficient...
You bake in a public key for the device/projector... you sign the files on disk against the private key (for the encrypted hashcheck as a sanity check), you use an IV that combines with a secret key on the device to decrypt the file.
As long as you aren't too obvious, this would make the effort to play your own files at a different level without opening the device. Once you're willing to do that, you're probably going to be able to maybe just push your own firmware, which is a different issue.. assuming most of the internal are common/available hardware with relatively open/common reference implementations. For a $10/pound device, I'm guessing so.
In the end, it was probably as much about satisfying the content rights holders as anything else. If it looks like a lock, it doesn't matter if you can cut it off with scissors.
One of the fun things about the World Wide Web is that without specifically intending to do so we provided all of the Worst Case Scenario cryptographic properties, things a good cryptographic solution can cope with, but which were often treated as difficulties that aren't really worth worrying about because why would you need that?
For example, what kind of moron would put a secret you mustn't learn right next to data you can choose? A good solution wouldn't care, but surely a bad solution where that would cause a problem would never encounter real world scenarios where.... oh right HTTP Cookies
Good solutions won't lose security from repeating transactions, but while accidents might cause one or two repetitions surely no real world systems would need to withstand millions of... oh yeah, Javascript loops exist
A bit absurd really, the image of the manufacturer locking this down with robust security signed payloads and bootloaders is truly comical.
Unpopular opinion here: but this article is perfect proof of concept that when trying to take something to market you need a non technical person put the brakes on some technical teams.
You might have a point regarding security in general but what is the specific problem here? It is your device to use as you please. I might be thrilled if all devices were as broken as this.
While the article's a fun exploration, I do wonder if the key point of the XOR cipher was actually to allow the manufacturer to claim that encryption was in use so that the DMCA could be invoked and make reverse engineering illegal.
10 comments
[ 2.7 ms ] story [ 33.7 ms ] threadIt would save the world so, so much grief and cheap insecure consumer devices. I will flip my lid if I see another kiddy-cam on Shodan.
What is the payoff here? Is the projector sold below cost and is the manufacturer recouping that via the cartridges? If not, what's the loss to them?
Regarding the proposed mitigations, I'm very doubtful on whether they would substantially change anything here:
> Use real crypto (AES-128 or lightweight stream) and make the cartridge carry per-title key (or an IV)
> Copying now requires cloning/extracting the original token secrets.
Sounds like a great idea, and fortunately we don't even need to speculate about whether it would work: Nintendo did this with Amiibo.
> If true anti-cloning matters, this requires an authenticated token (DESFire / NTAG 424 DNA class).
And where do you securely store the validation key for a symmetric encryption/authentication scheme? This would require adding a SAM to the projector as well.
The "use non-default NFC keys" suggestion shares the same problem: Where would you securely store these?
You bake in a public key for the device/projector... you sign the files on disk against the private key (for the encrypted hashcheck as a sanity check), you use an IV that combines with a secret key on the device to decrypt the file.
As long as you aren't too obvious, this would make the effort to play your own files at a different level without opening the device. Once you're willing to do that, you're probably going to be able to maybe just push your own firmware, which is a different issue.. assuming most of the internal are common/available hardware with relatively open/common reference implementations. For a $10/pound device, I'm guessing so.
In the end, it was probably as much about satisfying the content rights holders as anything else. If it looks like a lock, it doesn't matter if you can cut it off with scissors.
For example, what kind of moron would put a secret you mustn't learn right next to data you can choose? A good solution wouldn't care, but surely a bad solution where that would cause a problem would never encounter real world scenarios where.... oh right HTTP Cookies
Good solutions won't lose security from repeating transactions, but while accidents might cause one or two repetitions surely no real world systems would need to withstand millions of... oh yeah, Javascript loops exist
Unpopular opinion here: but this article is perfect proof of concept that when trying to take something to market you need a non technical person put the brakes on some technical teams.