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?

▲

tracker1 a day ago | parent | next [-]

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.

▲

lxgr 10 hours ago | parent [-]

For the concern of making tags harder to clone: Cheap contactless tags usually don’t support asymmetric cryptography (not even ECC), so this would significantly increase the BOM.

If the tags only carry the keys as storage media instead of using them for authentication, all cloning considerations apply again.

For not allowing playback of user files, this would be doable since the SoC is presumably freely programmable, but now you’re facing another problem:

Do you use one global key (then only one compromised projector is enough to break the entire system and the economics), or do you use a per-device key, which requires installing these keys at manufacturing time and individually recording each SD card?

Real-world defense is really not as trivial as the armchair security blogger perspective suggests.

	▲	tracker1 7 hours ago \| parent [-]
		Of course... I'm just talking about raising the bar enough so that it would take a bit more than some casual observations to crack. Per my final statement in GP comment. > 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. Most locks get broken eventually... the locks on houses, for example, rarely actually secure the home from intrusion... you have windows that are easy to break and enter/exit. It's about adding a modest effort in order to deter such action... nothing will ever stop it altogether. There's a difference between minimal effort, best appropriate effort, creating Fort Knox around your content and doing nothing at all.

▲

donkey_brains a day ago | parent | prev | next [-]

TFA was pretty clear that this is an example which illustrates common issues in enterprise security. It even provides a handy table to map the similar patterns between this toy and a network appliance. No one’s arguing for stronger security in children’s toys, here.

	▲	viraptor a day ago \| parent [-]
		The author is: > And here we have seen a few decisions that are really bad and, moreover, completely compromises the recurring sales business model of a large publishing group. They're actually complaining the toy is bad and should've been more secure.

▲

Yippee-Ki-Yay a day ago | parent | prev | next [-]

Actually, I think your point of view isn't that far off from what the article suggests. The goal shouldn't be to stop a state actor or a reverse engineering expert, but simply to meet basic business requirements at the same cost.

It's more about risk management, like raising the bar high enough so that the revenue model isn't affected by a bored casual user with a free Android app.

That said, your point is correct, it's difficult to make a robust DRM (it has taken industry giants quite some time to come up with models that remain “secure” for a certain amount of time)... but we are talking about a cheap toy, in which I don't think anyone would invest much more than a few hours trying to breach it.

	▲	lxgr a day ago \| parent [-]
		> we are talking about a cheap toy, in which I don't think anyone would invest much more than a few hours trying to breach it. If that's the bar, I feel like the ad-hoc XOR "cipher" also did the job :)

▲

rustyhancock a day ago | parent | prev [-]

Exactly it's very junior mindset from the article author.

Where without giving consideration to the situation they are espousing "best practices". Best practice for what? A children's toy DRM for NFC tag? Come on....