3

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.

4

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.

  • 2
    The XBox is generally a cautionary tale. Microsoft left one flaw in the system because they thought that only an organization with access to an extremely fast (and thus extremely expensive) oscilloscope would be able to snoop the key off the unprotected high-speed bus. And they were right: pirates didn't have access to the necessary equipment, or they weren't willing to spend millions of dollars on it. Unfortunately, some student wanting to run Linux on his XBox happened to study at an engineering department that built such an oscilloscope … and the rest is history. – Jörg W Mittag May 12 '18 at 8:05
3

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.

  • Thanks all. The solution I proposed is based on the idea to make a device used for vehicles where it is packaged like an ECU so difficult to get into the case. It may also have some tampervmechanism that wipes firmware. The solution is more to prevent casual piracy of the software. Even if someone does get the hardware's private key, that does not help against another device which will have it's own key. This is my theory anyway. – ATtheincredibleaf May 13 '18 at 12:33
  • yes I see those flaws. Although I wanted to clarify, the user doesn't have to do anything manual. The hardware is connected via bluetooth to a client desktop / mobile device running application software to facilitate management and download of the encrypted software to run on hardware. Its this app that grabs the hardwares unique serial and registers that hardware on company servers. Your other first two points are valid, but see my other comment regarding the use case for the hardware. – ATtheincredibleaf May 13 '18 at 12:45
  • I see. If your hardware is custom enough, all you really need to do is not equip it with a "download firmware" command; keep it a one-way operation. To prevent firmware's interception as it's being updated, a simple standard SSL protocol will suffice. Store it encrypted for good measure, also a standard FDE policy. – Therac May 13 '18 at 12:53
  • Re: if someone does get the hardware's private key - if they do, they can simply decrypt the software. After that, they can remove the whole encryption part of it if they want to. In short, against 'casual piracy', HTTPS will suffice. Against someone who wants to copy the whole device, you'd be looking at far more difficult solutions. – Therac May 13 '18 at 12:56
  • I think you are misunderstanding as I may not have been clear. The software is not a trade secret. The software is like the equivalent of a map file for a TomTom device. The use of public private key encryption is so that it is not so easy to put this software, either in encrypted or decrypted state on another hardware, and use it. The new hardware should not understand the software in either state unless it is modified ofcourse. The secondary protection could then come from tamper protection. This all is not infallible, but it is to stop casual piracy with minimal impact to the user. – ATtheincredibleaf May 13 '18 at 13:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.