Although servers are primary targets some attacks focus on comparatively simple and seemingly innocuous devices. Who would consider the electronic thermometer inside a fish tank as a potential threat to corporate network security? For a casino, this turned out to be the case. Hackers used the comparatively weak defences of the thermometer to gain initial access to the core network. From that foothold they gained much better access and soon found a key customer database that they copied. The breach was only discovered when a security consultant analysed network logs and found data being sent to a remote server in Finland using protocols that are normally used for streaming media.
Banking networks have been penetrated through the close-circuit television (CCTV) networks that were installed to improve physical security, and hackers have found ways to spy on home users through the cameras in their robot vacuum cleaners. However, these attacks are avoidable. It is possible to fend off the attacks and keep devices and the core network protected. The key is to provide multiple levels of security barriers that will make it very difficult and time consuming for potential hackers.
Today, hackers can often take advantage of poor decisions made by development teams. One common mistake is for devices to be provided with a default password that lets remote users log into a control shell. Such passwords can often be found in the apps provided to make these IoT devices easy to set up. Best practice is to provide each device with its own unique password. But as manufacturers improve their basic security skills, cybercriminals will employ more sophisticated tactics similar to those they use against servers. Embedded systems cannot rely on their lower perceived value as targets for hacks in this changing environment. As the casino owners discovered, any IoT device can open up a network to a dedicated attack.
There are numerous types of attack that can be staged against a networked system. For example, a common technique employed by hackers is to harness flaws in software. For example, if the device receives more data in a packet than has been allocated to a buffer on the system stack, the additional bytes will overflow into neighbouring data structures. When a later routine pops those bytes from the stack, the data may well be used by other routines, which crash or make mistakes as a result. The processor may even interpret those values as branch-target addresses and attempt to execute the wrong code. A hacker familiar with the memory layout of the device will use that knowledge to construct mini-programs that open the device up to them. A similar exploit is to send erroneous data to the device that cause the subroutines used to process the bytes to fail and potentially make the device vulnerable.
Some attacks focus on communications protocols rather than core device software and attempt to overwhelm the system to cause it to fail. As the device tries to recover, they can try to gain access at that point. If the attacker is able to control nearby network equipment or even gain direct physical access, they may be able to spoof legitimate servers with which the device wants to communicate.
Such man-in-the-middle attacks may be used to analyse data coming from the device that may be useful for a future attack. Alternatively, the hacker may attempt to load their own firmware onto the device. Once rebooted with the replacement malicious firmware, the device will perform any function the hacker wants.
Ideally, the system would reject communication attempts by machines that cannot demonstrate they have access rights. By doing so, the device would reject the fake firmware provided by the hacker. It could also ignore attempts to connect in a denial-of-service attack and thus avoid tying up resources that force it to crash. And it would avoid sending sensitive data to a machine that cannot be authenticated reliably. For packets that the device does accept, it would check them for length and correctness, rejecting any malformed frames that might open the device up to a buffer-overflow or command-injection attack. However, implementing all these protections in the device’s firmware may be prohibitively expensive for any large codebase, particularly one that makes extensive use of third-party software libraries and applications.
A more realistic approach is to divide the firmware into sections that need high security assurance and those that can be allowed to fail under attack because they will not compromise the secure functions. For example, a subroutine that simply packetises temperature data into a JSON format so that it can be relayed to a smartphone app need not be checked for security properties. Secure code, however, will ensure that authentication is carried out before that data is sent anywhere.
Dual Developer Approch
The amount of software on the device that needs full security hardening need only be a fraction of the total codebase. However, this separation is only effective if there are no backdoors from the non-secure code to the high-security routines that hackers can exploit in privilege-escalation attacks. For example, if a buffer-overflow attack succeeds in loading into memory that is designated ‘secure’ data that makes the attacker’s identity that of a system administrator any protection is lost. Isolation of secure memory from non-secure areas is essential and can only be reliably enforced in hardware.
Embedded microcontrollers such as those in the Microchip SAM L11 family contain security-enforcement hardware based on Arm® TrustZone® architecture extension augmented with proprietary protections against software attacks. The hardware enforcements in the SAM L11 make it possible to construct a root of trust and use that to extend security protections to the rest of the system, forming the basis of a comprehensive security framework.
The root of trust can perform cryptographic operations that extend the trusted zone out from itself to include other elements of the system, allowing communications to be protected on an untrusted network. A built-in cryptographic controller streamlines the operation of generating per-session keys as well as the encryption and decryption operations. The controller can also help check the authenticity not only of incoming messages from the network but the code that the system runs. The cryptographic protections even guard against counterfeit hardware. In this case, software running within the trusted zone can interrogate other boards in a chassis by issuing challenges to which only valid boards can respond correctly.
Cortex-M 23 Interrupt Mechanism
To maintain a root of trust, the SAM L11 hardware employs a secure boot process. To prevent this from being compromised, the initial boot sequence is from code held in a boot ROM area that cannot be altered after manufacture and so cannot be circumvented. Once initial startup has completed, services in the boot ROM code check the remaining firmware needed to complete the boot process for authenticity. It does this, with the help of the cryptographic accelerator, by checking the hash stored with each firmware segment matches and that it is consistent with a reference hash encoded by fuses set at manufacture. A mismatch in the value will reset the device and restart the secure-boot process. In this way, even if a hacker succeeds in altering the firmware stored in on-chip flash memory, the device cannot boot successfully until the manufacturer’s version has been restored.
Once the device has booted successfully and is running known good firmware, the Arm TrustZone technology implementation on the SAM L11 acts to maintain a clear separation between secure and potentially hazardous software. Arm TrustZone technology on the SAM L11’s Arm Cortex-M23 processor code provides a set of secure instructions that ensure any function calls made by non-secure code sent into the secure domain can be checked for problems. Arm TrustZone technology allows the creation of software security domains that restricts access to selected memory, peripherals, and I/O to trusted software without compromising system performance. By allowing secure code to be collected and protected, Arm TrustZone technology greatly simplifies the security assessment of an embedded device.
To differentiate and isolate secure code from non-secure code, the SAM L11 memory is partitioned into different memory regions, with each region configured by fuses to resist against software attacks. Any attempts to access regions marked as secure from non-secure code, or a mismatch between the code that is executed and the security state of the system results in a hard-fault exception that prevents the access succeeding and which may trigger a reboot of the system. This protection is maintained even during interrupt handling and debug.
Standard Interactions Between Secure and Non-Secure States
For example, the Arm TrustZone technology implementation maintains two stack pointers that separate secure and non-secure execution and prevent compromises to data on the stack that might be attempted through an interrupt handler. During debug, secure and non-secure code are treated differently using debug access levels. A developer working on non-secure sections cannot alter secure code or access debug information on it directly. This supports a clean separation of responsibilities so that only developers with security credentials can work on the protected code.
Typically, a developer charged with writing secure applications will provide header files and library routines that allow non-secure code to make requests, such as encrypting a network packet to be sent over the internet. The secure application is then loaded in a protected memory region. When a developer without security clearance develops the networking code, they will use the library and linker files provided but they will only have API-level access: the secure code and its data will be a black box. Attempts to alter the secure code can be forced to fail at boot time because its hash does not match at runtime. This is possible through the consistency checks made by the immutable secure boot process offered by SAM L11. For example, pointer manipulation to refer to an improper location will trigger a fault.
Peripherals can also be designated as secure or non-secure, with the result that only authorised software can access or control them directly. For peripherals that may provide services to both types of region, access to them is protected in a similar manner to secure function calls. The non-secure code makes a request through an API provided by the secure-code developer. This ensures any direct control of the peripheral is maintained by authenticated code that can check for attempted malicious use. For example, non-secure code may be allowed to read the state of a timer-counter but be prevented from resetting it.
External peripherals and subsystems may only be allowed to make requests to the microcontroller if they provide a hash value that tallies with a digital certificate held in secure on-chip key storage and the data they send. This prevents any attempt by a hacker to use a compromised peripheral to subvert system operation and is also the basis for manufacturers to ensure their device cannot be used with counterfeit subsystems. Even if the attacker is able to probe and alter 256 bytes of RAM meant for key storage, the SAM L11 contains mechanisms that will zero-out keys and data if it detects that kind of activity.
The result of the interlocking security measures on the SAM L11 that extend from physical protection of memory to the Arm TrustZone separation technology provides OEMs with the ability to build holistic security into their embedded devices and ensure its applications are not the weak link in the IoT.
Author: Ramanuja Konreddy,
Senior Product Marketing Engineer 32-bit MCU
Microchip Technology | https://www.microchip.com
