Device Security: A Guide for Electronic Product Developers

Electronic devices rarely live in a vacuum. Usually electronic products interact with one or more devices, especially in IoT systems. During these interactions, devices pass information to each other, which can cause serious security threats. Luckily, there are precautions electronic product developers can take to minimize these threats.
 
In typical IoT applications, there are (one or more) devices that collect data and transmit it to a data center, through gateway devices. The data center may be a single, local computer or it may be an internet-connected, remote facility. At the data center, the data is aggregated and processed to derive useful information that will be used to control some process and / or be presented to an end user through another network interface and set of devices. This ecosystem of entities has many interfaces that present potential vulnerabilities for bad actors to interfere with the system.

Anticipating Bad Actors

Your job as an electronic product developer is to anticipate potential bad actors (i.e. attackers) against your system and their motivation. You then need to consider the attack surface of your system, what the vulnerabilities could be, as well as the attack vectors that the bad actors are most likely to use to attack your system. Using this information you can develop a system of countermeasures that will meet the security goals of your product within its environment.
 
Bad actors could have many different motivations for interfering with your system, such as greed, thrill-seeking, vandalism, curiosity, or activism, among others. The motivation will give you some clues as to how committed the attacker is to impacting your system and what resources they may use in their attacks.

Does the attacker want to harm you, a particular user, or all of your users? What information can an attacker learn about you and your users by monitoring your system? Does using the system expose financial risks to the user or to your company? What information is leaked from your system about users of the system? Can the information stream from your system be used to track a particular user? Can the attacker use your system to influence people or to control devices? Could your system be taken over and used to attack a third party?
 

Considering The Attack Surface

When considering the attack surface of your product, you need to consider all interfaces from multiple perspectives, including the physical construction, user interfaces, electrical and RF protocols, data flows, and the user interactions. You also need to consider how long the system needs to be secured. Other aspects to consider are whether special equipment is needed to carry out the attack, how costly or difficult an attack would be, and whether it is important to be able to detect tamper attempts.

Sometimes attackers will have physical access to the devices and / or the gateway devices. Physical access opens up the attack surface for many potential attack vectors. The following questions can help you identify vulnerabilities:  

• Would accessing the electronics be detectable by the user of the device?
• Can they access the debug and / or logging ports on the device?
• If so, what information about your customers or your system will they be able to access?
• What equipment would they need to access information from the communication and debug / logging ports?
• Can they read the device memory through the debug ports?
• Could they clone the device configuration? Could they reverse engineer the intellectual property (IP)?
• How much effort would it take to derive useful or damaging information? 

Even if the attacker does not have physical access to the product, they may gain access to the communications from the product wirelessly, or through a data network. Could they derive any information from the communication protocols by listening and / or injecting signals on the communications channel? What equipment would be required to listen to the communications protocols? What equipment would be needed to decode the communications protocols? Would the information still be valuable after it is decoded? After a message is decoded is it easier to decode the next message? How frequently are session keys refreshed?  
 

Extreme Cases

In extreme cases, you may need to consider highly motivated attackers. In these situations, attack vectors can become quite extensive. Can attackers derive extra information by monitoring CPU power and / or computation delays? How does your device behave under extremes in temperature, voltage or other stresses? Can the electronics detect tamper attempts and destroy any critical, secret information? Can an attacker retrieve secrets from your system even after it has tried to erase them?

Sometimes attackers try to take over electronic devices so they can use them for their own purposes. Could an attacker replace or take over the software on any of the processors in the system? Do the nodes check upgrade packages to make sure they are valid and signed before allowing them to be applied? Does the product ship with secure defaults?  Can the user compromise the security of the system accidentally? Could you or your users recognize when a system is insecure?

Many devices require authentication of the user before they are useful. Does your system work securely for all members of the population? What about people with disabilities? How do users interact with the system? Can it use two factor authentications? Can it use biometrics? 

When considering the attack surface you need to consider normal and abnormal use cases for your product. You need to think like an attacker and consider alternative ways that the system may be compromised. 

Preventing An Attack

Once you have accumulated a set of potential attack vectors, you need to consider countermeasures to protect you and your customers. Adjusting the design to eliminate the vulnerabilities is the preferred option; sometimes you can even remove the temptation for attack by removing the valuable pieces of information from your system entirely.

When considering which vulnerabilities to work on, try to anticipate the perceived value of the target, the difficulty in achieving the target, and the motivation of the attacker. Allocate your efforts in developing countermeasures appropriately. Here are some countermeasures to consider:

• Use analysis tools to model the system and manage the security aspects of the design
• Design mechanical enclosures to protect contents
• Add tamper detection (both visual and electrical) where appropriate
• Use secure elements to store secrets
• Use secure boot loaders to validate application code before executing it
• Use secure protocols that include encryption to protect secrets
• Use signed hashes to prevent tampering and prove authenticity
• Setup protocols to protect user identities and information where appropriate
• Choose encryption protocols with sufficient security to protect the information for appropriate length of time
• Use two factor authentication
• Design manufacturing processes to ensure product security
• Design audit and logging systems to monitor and detect exceptions and tampering
• Monitor gateways and data centers, keeping up-to-date on security patches
• Disable debug ports for production systems
• Disable the device under conditions that may compromise their security
• Design security aspects that are compatible for your target users
• Train users how to securely use your products and how to detect tampering
• Train users how to decommission the system securely to prevent information leaks at the product life cycle end

An effective product security system requires vigilance by you and your users. Throughout the product life cycle the security risks will change as your product matures, as your customers mature, and as your product is exposed to more customers and potential bad actors. Plan your resources to adapt to these changes through the life cycle of your product.