Guidelines for Security in Embedded Hardware - Page 1
Forum section: electronics / general

author: rakeshm55
author_rank: Regular Contributor
timestamp: April 24, 2018, 04:07:36 am
content: 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 features1. User Authentication2. Secure Boot3. Secure Key Storage4. KeyErase/Zeroize5. Crypto accelerators/TRNG6. Tamper proof7. IP protectionI 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

author: NorthGuy
author_rank: Super Contributor
timestamp: April 24, 2018, 04:29:18 am
content: 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.

author: Siwastaja
author_rank: Super Contributor
timestamp: April 28, 2018, 02:23:11 pm
content: 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.

author: MosherIV
author_rank: Super Contributor
timestamp: April 28, 2018, 06:24:44 pm
content: Quote2 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.

author: mark03
author_rank: Frequent Contributor
timestamp: April 29, 2018, 05:10:48 pm
content: 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.

author: hans
author_rank: Super Contributor
timestamp: April 29, 2018, 05:33:08 pm
content: Also this story seems applicable:https://www.schneier.com/books/secrets_and_lies/pref.htmlThat being said, cryptography is not useless, but advice can only be given if we know the application. I.e. whatis"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.

author: NiHaoMike
author_rank: Super Contributor
timestamp: April 29, 2018, 06:19:50 pm
content: 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 29, 2018, 06:40:36 pm
content: Quote from: hans on April 29, 2018, 05:33:08 pmThis 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).

author: nctnico
author_rank: Super Contributor
timestamp: April 29, 2018, 10:09:56 pm
content: Quote from: NiHaoMike on April 29, 2018, 06:19:50 pmA 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.

author: NiHaoMike
author_rank: Super Contributor
timestamp: April 29, 2018, 11:05:35 pm
content: Quote from: nctnico on April 29, 2018, 10:09:56 pmIt 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.)

author: nctnico
author_rank: Super Contributor
timestamp: April 30, 2018, 10:07:04 am
content: Quote from: NiHaoMike on April 29, 2018, 11:05:35 pmThe 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.

author: Mr. Scram
author_rank: Super Contributor
timestamp: April 30, 2018, 10:17:39 am
content: Quote from: NiHaoMike on April 29, 2018, 11:05:35 pmMAC 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.

author: rakeshm55
author_rank: Regular Contributor
timestamp: April 30, 2018, 04:21:16 pm
content: Quote from: MosherIV on April 28, 2018, 06:24:44 pm

author: rakeshm55
author_rank: Regular Contributor
timestamp: April 30, 2018, 04:51:55 pm
content: 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