DRM using embedded private key

Question

I've started learning about cryptography used for DRM solutions, and curious to know if this is a valid solution for a custom embedded system running purchased software assets.

ECDSA public / private key is generated before device manufacture.

Private key is embedded in device, and public key is registered on company server against device's serial number.

When software is purchased, the hardware's serial number is sent to server as part of the transaction.

Before being made available to download by purchaser, the software is encrypted using the hardware's public key, associating the software with that particular hardware.

Once stored on the hardware, the software is decrypted Just In Time for execution using the embedded private key.

Answer 1

While this system may be functional and may deter the inexperienced and slow down others, this is ultimately not an effective defense.

The problem lies with the fact that the private key is embedded in the device, and the customer who has purchased said device has unrestricted physical access to it. Communicating with debug interfaces, taking memory dumps, shelling the device etc. may allow the private key and/or the proprietary software to be recovered. The ease of this may depend on the design of the device's hardware and software, but it is likely beaten with enough time and effort in any case.

In short, once someone else has possession of the device, you can't expect confidentiality of anything stored on or processed by it.

Answer 2

This happens to be a very simple, if not to say naive version of part of how Denuvo works. Although no one seems to know how exactly, it turns out you don't need to understand the egg to crack it.

There are at least a few vulnerabilities in your proposed solution:

1. The end user is responsible for deciding what serial number they want to send to the server.

2. Unless the encryption/decryption module is well-protected, the private key is easily extracted. Extracting it from a well-protected module is more difficult, but positively doable.

3. The software is decrypted.

All the while, it imposes a massive burden on the users, which makes the software more difficult to sell:

• It only works with hardware made to your specifications.
• Every piece of hardware has to be registered on your servers.
• It requires a unique copy of the software to be completely downloaded by every user.

If your solution is meant to be an actual embedded system, piracy isn't a problem to begin with. Copying the entire system is too much effort, unless it's useful for other purposes. You just sell the complete hardware and software package.

If it's truly worth copying, decapping a chip is not rocket science, the key will be downloaded, and the chip itself will be copied, maybe even complete with your copy protection solution.

If it's meant for a general market, that market becomes at least tens of thousands times larger by supporting hardware other than your own custom chip, so even with an unrealistic 99% piracy rate universal hardware support wins in profitability.