Guidelines for Security in Embedded Hardware

[rakeshm55]

Hi,
Is there any guidelines available for realizing security for  embedded hardware ??

My aim is to make sure that hardware I develop should support below features

1. User Authentication
2. Secure Boot
3. Secure Key Storage
4. KeyErase/Zeroize
5. Crypto accelerators/TRNG
6. Tamper proof
7. IP protection

I have glanced through Controllers like SAMA5D2(Microchip)....

What are things I should take care while realizing hardware?? So that at a later stage S/w developers may not face any hardship in realizing requirements

[NorthGuy]

Start by asking yourself what exactly you want to protect, who are your attackers, and what kind of attacks they may use to gain access to the things you're protecting.

[Siwastaja]

These are very hard things to do right, require a lot of deep understanding and experience from an experienced designer, and cannot be handled as a list of requirements, or "guidelines".

Your only option is to find someone who can do this, or start really learning now, full time, and be able to do it in maybe 5-10 years.

Also, you need to work together with the SW team on this.

[MosherIV]

2. Secure Boot
6. Tamper proof

2 and 6 are kind of the same thing. You would need a MCU that provides something like Trusted Boot.
Basically, you produce a series of verification keys (like checsums or crcs) for your boot loader, os and application. The keys must be stored in a way that is tamper proof, for secure boot the key is a write once PROM. The MCU has a boot mode where is will verify the boot loader against the stored key (the algorithm is determined by the MCU and cannot be changed). Once the key is stored in the MCU, it cannot be changed, so you will usually need a number of MCUs to work with.

I never did the next stage - verifying the OS, sorry cannot help you there.

[mark03]

This is a huge topic which cannot be answered in a single post, and which you are highly unlikely to get "right" the first time by yourself.  But @NorthGuy has given you the correct starting point IMO.

The embedded product landscape is rife with devices which are locked down tight when they have no real need for security, alongside easily hackable devices with truly frightening potential.  From working in the embedded-systems world, my observation is that every company believes their device needs airtight security, without really asking themselves why.  As a consequence the products on the market with good security are merely those which came from competent development teams, i.e., little correlation with actual product needs.

I will now state a contrarian opinion which I think deserves greater consideration in the industry:  If this is a consumer product, please remember that your users own it, not you.  I see lists of "security best practices" bandied about as if more security is always a good thing.  It is not.  Although you do have certain responsibilities, ethically and legally, for failures or malicious use of your product after sale, it is not unreasonable for technically inclined users to expect to access (aka "hack") the device for their own purposes.  Unless there is legitimate IP to protect (and often this is just an excuse to avoid critical thinking), IMO it is unethical to unnecessarily restrict access to the firmware.  Additionally, the goodwill generated by permitting an open-source development community to form around your product can be significant; the WiFi router and digital camera markets both offer concrete examples.  OTOH, if you are the "little guy" facing likely competition from cloners in China, that may be reason enough to lock down the firmware... although I am unsure how effective such efforts are in practice.

[hans]

Also this story seems applicable: https://www.schneier.com/books/secrets_and_lies/pref.html

That being said, cryptography is not useless, but advice can only be given if we know the application. I.e. what is "secure"?

Moreover, using cryptographic algorithms doesn't solve any problem. You can apply private-key encryption/decryption on your communication, but still have a dead easy (or even fixed) key rotation system in place that makes it trivial to compromise.

[NiHaoMike]

If it's a device that requires a cloud service to work, one very robust approach is to have the MAC address and serial number correlated by some cryptographic signature. Then copies will either have duplicate MAC addresses/serial numbers or serial numbers that do not match up to their MAC addresses. To make it even more of a trap, wait until a large number of copies to start to appear before enforcing the check.

[SiliconWizard]

Moreover, using cryptographic algorithms doesn't solve any problem. You can apply private-key encryption/decryption on your communication, but still have a dead easy (or even fixed) key rotation system in place that makes it trivial to compromise.

This is true. But that doesn't mean you shouldn't use any cryptographic means. Most security-related features are not implemented to completely prevent any unwanted access, but to severely slow down the process and thus lower the probability of such unwanted access.

Key rotation, however trivial it is, will still slow down hacking attempts. A better approach, though, would be not to just rotate keys, but  to periodically "rotate" encryption algorithms themselves as well.

The whole point being to make hacking harder than it's worth for a given application - not necessarily to make it impossible (which we can't do anyway).

[nctnico]

If it's a device that requires a cloud service to work, one very robust approach is to have the MAC address and serial number correlated by some cryptographic signature. Then copies will either have duplicate MAC addresses/serial numbers or serial numbers that do not match up to their MAC addresses. To make it even more of a trap, wait until a large number of copies to start to appear before enforcing the check.

A MAC address isn't unique (nobody guarantees that and there are duplicate MAC addresses out there) and a MAC address isn't used on internet anyway. Either way a MAC address is very easy to spoof.

To the OP: security is something you design and implement at the system level. Embedded firmware/hardware is only a small part of that. Just pouring encryption over some software/hardware isn't making a system as a whole secure.

[NiHaoMike]

A MAC address isn't unique (nobody guarantees that and there are duplicate MAC addresses out there) and a MAC address isn't used on internet anyway. Either way a MAC address is very easy to spoof.

To the OP: security is something you design and implement at the system level. Embedded firmware/hardware is only a small part of that. Just pouring encryption over some software/hardware isn't making a system as a whole secure.

It would be obvious to the cloud service that there are a lot of devices with duplicate MACs and serial numbers or MACs that do not match up to serial numbers. The only way they would be able to make new MAC/serial number pairs that satisfy the rule would be to crack it, which is next to impossible with a good implementation. (And in that case, after a certain serial number, change the rule so they'll be back to the start again.)

[nctnico]

A MAC address isn't unique (nobody guarantees that and there are duplicate MAC addresses out there) and a MAC address isn't used on internet anyway. Either way a MAC address is very easy to spoof.

To the OP: security is something you design and implement at the system level. Embedded firmware/hardware is only a small part of that. Just pouring encryption over some software/hardware isn't making a system as a whole secure.

It would be obvious to the cloud service that there are a lot of devices with duplicate MACs and serial numbers or MACs that do not match up to serial numbers. The only way they would be able to make new MAC/serial number pairs that satisfy the rule would be to crack it, which is next to impossible with a good implementation. (And in that case, after a certain serial number, change the rule so they'll be back to the start again.)

The cloud server doesn't see the MAC! MAC=ethernet and that isn't visible beyond an ethernet segment. Only IP packets go through a router and the MAC address isn't part of IP traffic.

[Mr. Scram]

It would be obvious to the cloud service that there are a lot of devices with duplicate MACs and serial numbers or MACs that do not match up to serial numbers. The only way they would be able to make new MAC/serial number pairs that satisfy the rule would be to crack it, which is next to impossible with a good implementation. (And in that case, after a certain serial number, change the rule so they'll be back to the start again.)

MAC filtering isn't an effective technique, though it does seem you're arguing two things at the same time. You don't need a unique identifier to be connected to the MAC to do what you're suggesting. You can just pick a unique number or use some sort of seeding technique.

[rakeshm55]

  The keys must be stored in a way that is tamper proof, for secure boot the key is a write once PROM. The MCU has a boot mode where is will verify the boot loader against the stored key (the algorithm is determined by the MCU and cannot be changed).

Do you mean to say that the initial boot code in MCUs internal ROM will have a hardcore verification Algorithm that would verify the Bootloader to be executed. There would be fixed location for storing the key from where the Internal bootcode would search for Key

Key is one time programmable(OTP) and requires an MCU change for new key.

[rakeshm55]

How to handle Secure storage of keys (Not Public keys). say symmetric keys??

Is it by encrypting keys and then storing it in flash??
If so then where to store the decrypting keys how to prevent exposing that key