CODEWITHSUNDEEP
c++ccryptographyembeddedpublic-key-encryption
Praetorian
Praetorian

Reputation: 109079

Password protecting embedded firmware download

I need to protect against the users of our product from downloading firmware that is incompatible with the revision of the hardware that they're trying to download to. I'll describe what exists right now and what I'm looking for.

We have an alpha-numeric hardware part number and revision stored in EEPROM that is only factory programmable. When a customer attempts to download a firmware file he will have to enter a password that is distributed with the firmware release. The existing firmware needs to be able to use this password to verify that the new firmware is compatible with the current hardware revision. Keep in mind that more than one hardware revisions may be compatible with a single released version of firmware.

Is there some form of public key cryptography that can be used to validate multiple hardware revision numbers to a key that is generated during the firmware build process? The hardware revision number(s) would act as the private key while the password entered by the customer to unlock the download mechanism would be the public key.

The embedded firmware is written in C and it would be great if the encryption algorithm were the same. It can be C++ as long as it has an interface that lends itself to being called from C functions.

There are a couple of hardware revisions out in the wild, but we can ignore those exist for now. Let's say a brand new product is going to be released that includes this feature, so it will be revision 0.

The password will be transferred from the client's computer to the embedded hardware without any modifications. So the decryption and password matching needs to happen in the embedded firmware, which will then report success / failure back to the client. The reason for this is that it may not always be a laptop being used to download the firmware. It'll more likely be a handheld download tool so options for executing custom software are limited.

Upvotes: 0

Views: 996

Answers (2)

Yahia
Yahia

Reputation: 70369

So we assume this is a fresh design:

I am not really how much security you want/need and how processing power your device has...

I would make the firmware package consist of two parts - a header and the "real thing". Both should be encrypted differently and then signed independently plus together (this is the public key cryptography part).

  • first check the outer signature

  • then check the signature of header (which must be calculated based on the header, header length plus the password)

  • The header is encrypted with the password you distribute and contains a list of hashes of the compatible hardware revisions (these hashes are calculated from the hardware revision + password). The device decrypts the header, hashes its own revision from the EEPROM accordingly (again revision + password) and tries to find a match in the list. IF it finds a match then it takes the hash of the list in the header.

  • with the hash of the list it check the signature of the the "real thing" (calculated on the encrypted content plus length plus password plus hash of the list)

  • if the signature is valid it proceeds decrypting the "real thing" (key would be password + hash of list)

For the signature part you create a cert, sign that cert with your root cert... the derived cert would be embedded into the devices... so you create the signatures with the private key of that cert and check them in the device with the public key.

The above is NOT 100% secure but provides several aspects:

  • tampering with package would be always detectable (as long as you don't loose your private key that is)
  • it won't be installable on any incompatible hardware revision
  • figuring out the scheme wouldn't allow for installation on incompatble hardware revisions (except if your customer somehow modifies your hardware)

IF that is two much calculations etc. you could always simplify the scheme... at the bare minimum I would keep the outer signature and the password...

EDIT - after some discussion (see comments):

The base algorithms to create the "password" I suggest consists of 2 parts - a hashing algorithm and an encryption algorithm:

  • hashing algorithm
    The respective firmware should be hashed ("good" algorithms are SHA-512, SHA-384, SHA-256, MD5 - "VERY WEAK" algorithm would be CRC32)

  • encryption algorithm
    The password would be encrypted using either an asymetric algorithm (like RSA, EC etc.) or a symetric algorithm ("strong" ones are AES, Blowfisch etc. - "weak" ones are for example DES - "VERY WEAK" is for example XOR)

The scheme consists of the following steps:

  • hash the firmware with any of the above hashing algorithms

  • build a string consisting of part number/ revision number + firmware hash

  • encrypt the string with any of the above mentioned encryption algorithms (asymetric means you use the private key, symetric means you use the same key for encryption/decryption)

The device need to contain a secret key (which is either the public key if asymetric encryption is used or the key in case of symetric encryption) and the part number/revision number.

Checking the firmware against the password means decrypting the password, hashing the firmware and comparing the part number/revision number and firmware hash...

Security aspects versus processing requirements:

  • asymetric encryption means handling big number (1024 bit or bigger)
    IF the device is not capable of handling that you should perhaps take a symetric encryption.
  • symetric encryption means that IF your customer reads out the key from your hardware he would be able to create "valid passwords" himself while in the asymetric case this won't be possible
  • you could stick with hashing only (hash the firmware plus part numerb/revision number) and provide the result as a password but this leaves you open to a customer figuring the algorithm used out and then they can create themselves "valid passwords"

Some relevant links:

Upvotes: 1

caf
caf

Reputation: 239011

Forget the passwords.

The simplest way to do this is to include in the firmware file, at a known location, a list of compatible hardware IDs. This could be stored as a length-prefixed array. When a new firmware is to be loaded into a device, the device looks for its own hardware ID in the list, and rejects the firmware if it is not present.

Such a system is robust, easy to understand and easy to debug. If space is a concern then you can store the list as a bitset, with each hardware revision allocated a bit.

If you wish to prevent active tampering, you can further sign the entire firmware file, including the list of compatible hardware IDs, with a normal public key signature algorithm like DSA or RSA.

Upvotes: 6

Related Questions