Supplier eBooks

20 The success of the Internet of Things will depend on data and services being protected, and when the security balance is right, it can open up new opportunities and markets. Communication Attacks Non-Invasive HW Attacks Invasive HW Attacks Cost/Eort to Secure The 10 Security Techniques Every IoT Designer Should Consider For design engineers who are striving to enhance the security of their IoT devices, there are numerous options at hand. In the following pages, we describe 10 strategies that can have a direct impact on improving device security. Method Notes Complexity, Resources Needed Notes Packet Encryption Low Foundation for most embedded system security Replay Protection Low Prevents resubmission of recorded messages Message Authentication Code Low Prevents messages from being changed Port Protection Low Secures ports that may be physically accessed by an attacker Secure Bootloader Moderate Ensures only authorized firmware is allowed to run Pre-Shared Keys Low Preferred for smaller systems SSH High Generally on OS-based systems; can prevent malicious connections Public Key Exchange High Generally on OS-based systems; can prevent malicious connections TLS High Generally on OS-based systems; can prevent malicious connections WPA2 High Generally on OS-based systems; can prevent malicious connections Packet Encryption This is the "go-to" method for protecting data exchanges in IoT solutions with smaller embedded terminal devices. Most systems have the resources to implement basic encryption, such as FIPS-197/AES, which can protect messages from unauthorized viewing or malicious changes. This method is easy to implement and use, especially in conjunction with private keys Message Replay Protection In this approach, encrypted packets are enhanced with data fields that vary in a way known to the recipient (which could be as simple as a date stamp). The recipient enforces a rule that messages are only accepted once or in a sequence. This prevents recorded, but not necessarily decrypted, messages from being resubmitted at a later time to cause the original action, such as "open door." This method is also simple to implement and is often used when individual messages can cause state changes. This can also be part of an encryption mode that will use this information within a block cipher. Examples of this is the AES counter mode block cipher. Message Authentication Code In this method, we run a cipher or hash algorithm on the content of a data packet to create a short signature that accompanies the message packet. The recipient uses the same cipher or hash to confirm that the message has not changed. Message authentication provide explicit protection from tampering and enables some systems to safely use clear-text messages. For example, we can use this method for systems that transmit non-confidential data (e.g., air temperatures) that nonetheless must not be tampered with. This is another low-com- plexity method that is useful for many types of embedded systems. Debug Port Protection Hardware ports used for configuration, control, and analysis (e.g., JTAG ports and serial logging ports for firmware development and debugging) are also vulnerable and tempting targets for security attacks. To start, these ports can be protected with a different factory password per unit before further actions are allowed. Of course, the better move is to internally disable these ports in field-deployed units. Secure Bootloader Even for a development team with unrestricted access to required technical information, it can be daunting to correctly build and load firmware into a resource-limited embedded device, which makes it unlikely you'll experience a successful attack based on a malicious firmware modification. But the rapidly increasing sophistication of embedded-system attackers, combined with product requirements for easier field upgrades of device firmware, have created a risk that must not be overlooked. One best practice is to configure the device to check for a HMAC signature in the firmware image during startup to ensure it is authorized to run on the product. The image may also be encrypted for further protection. Secure bootloader solutions demand careful management of keys and support for debugging Pre-Shared Keys Secure IoT communications requires access to compatible keys. The use of pre-shared keys (PSKs) minimizes the demands on the resourceconstrained device. Keys can be transferred through an independent, secure channel and then manually entered into the terminal device. While the overall system to share the keys may have some complexity, the demands on the actual terminal device are minimal. When allowed by the application. Secure Shell The Secure Shell (SSH) protocol protects ports used for debug and configu- ration operations. SSH implements a standard protocol to encrypt console connections (e.g., Linux shell access) to prevent unauthorized viewing or operations. This substantially extends protection beyond a simple debug port password. This can often be too complex to implement on smaller embedded systems. But it's quite straightforward and feasible on larger OS-based systems because the necessary resources are typically present. Public Key Exchange Sometimes, pre-shared keys aren't a viable option, such as when the terminal device can't have the key configured at the factory, the necessary field-installation expertise is unavailable, or there is no keydistribution system available. In these instances, public-key exchange (PKE) is an ideal solution – thought it adds considerable complexity. With PKE, one of several methods is used to select and combine two large numbers, and then send one number and the resulting combination to the recipient. The recipient derives a session key that is known to the sender and this establishes a channel to encrypt/decrypt traffic. While technically

• Cover