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?
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....
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.
> 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.
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.
The article makes a strong case that, at least for minimum viable/ordinary security measures, the cost is $0.
The projector in question wasn't missing features that would have consumed any amount of the issuing company's margin to implement; it was missing features that would have consumed at most a couple of meetings and a junior dev spending 30min watching the first three YouTube results for "consumer device security issues", and then another 30min copy/pasting standard mitigations into place.
If they'd done the basic due diligence of putting a lock on the metaphorical door, they wouldn't have even had to spend the QA cycles making sure the lock was secure (though that would be nice). But instead they opted to ship sans security entirely.
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.
Can you expand on that? The general wisdom, true most places I and my peers have worked, is that non-technical business stakeholders are often the ones deprioritizing work that would reduce operational (including security) risk.