Machine learning workloads are moving from datacenters onto edge devices for privacy and efficiency reasons. Machine learning deployments in datacenters can be protected using conventional cybersecurity measures. At the same time, running neural networks in edge and endpoint devices brings new security challenges to system designers.
Machine learning at the edge is quickly moving from prototypes to commercial deployments across wide range of use cases. Arm expects endpoint ML to grow explosively over the coming years. In February 2020 Arm launched industry’s first Arm® Ethos-U55 microNPU. When the Ethos-U55 is combined with newest Arm® Cortex®-M55 processor it can deliver up to a 480x improvement in ML performance in endpoint devices.
“Enabling AI everywhere requires device makers and developers to deliver machine learning locally on billions, and ultimately trillions of devices,” said Dipti Vachani, senior vice president and general manager, Automotive and IoT Line of Business, Arm. “With these additions to our AI platform, no device is left behind as on-device ML on the tiniest devices are the new normal, unleashing the potential of AI securely across a vast range of life-changing applications.”
In traditional machine learning architecture, data is sent to the datacenter where it is pre-processed and fed to machine learning models to generate insights and drive decisions. Such centralized approach presents multiple challenges in IOT deployments due to large amounts of data flowing from sensors to the datacenter, including:
Running neural network in edge and endpoint devices solves these challenges by dramatically reducing amounts of data that devices send to the datacenter. On the other side of the coin, moving intelligence and decision making to the edge significantly raises the bar for device security. The end customer, being it enterprise or consumer, expects to have trust in the insights and decisions generated by machine learning models in the device.
Arm’s Platform Security Architecture (PSA) defines solid foundation for designing secure connected devices. PSA is a certification program and a framework providing step-by-step guide to building-in the right level of security in connected devices, see more at this link.
At the level of System on Chip (SoC), PSA recommends such security mechanisms as hardware isolation of Secure Processing Environment (SPE), trusted boot, support for security lifecycle (assembly, test, provisioning, provisioned and debug), and secure storage of keys. This proven PSA security toolbox can be utilized to secure machine learning models on the edge and ensure decisions made by connected devices can be secure.
With machine learning, devices contain a pre-trained inference model defining structure of the neural network and its weights. Neural network models require protection since such models can be very expensive to create, can potentially reveal information about the data they were trained on, and expose its vulnerabilities to adversarial attacks.
Protection of inference models in connected devices needs to achieve two key security goals:
Proving the model authenticity is important to prevent attackers from manipulating insights and decisions generated by the device by replacing or modifying the inference model. Hiding the model’s internals from attackers is important to avoid IP theft, reverse engineering, and leakage of private training data.
There are five security mechanisms system designers need to consider when protecting machine learning models in edge and endpoint devices.
Machine learning allows connected devices process sensor data and make decisions locally. If attackers can replace or modify the inference model in the device, they are able to manipulate insights and decisions produced by the device. To prevent attackers from replacing or modifying the model, the device must verify that the model is authentic. This is to ensure the model is created by a secure entity.
Usually verification of the model authenticity can be combined with trusted boot process recommended by PSA specifications. With trusted boot, the firmware image is signed by the private key of the developer and corresponding immutable firmware verification public key is provisioned in secure storage of the device.
For example, constrained devices using TensorFlow Lite Micro have the inference model encoded as a data structure in the firmware binary at build time. More capable devices using TensorFlow Lite can have the inference model stored as a file on the device’s filesystem.
If system designers implement trusted boot and properly integrate the inference model in the firmware image (and root filesystem if applicable) of the device, the model authenticity is proved together with verification of the firmware.
This approach works with secure software update, another requirement of PSA certification.
In more complex cases when the firmware and the inference model are coming from different companies and have independent lifecycles (that is, can be updated separately), the device needs to be provisioned with additional immutable verification keys for verifying inference models. These keys need to be stored in secure storage of the device.
Inference model is a data structure that contains the structure and weights of a neural network trained to solve a problem. The model is often a core part of the device maker’s intellectual property and therefore needs to be kept confidential to avoid IP theft, reverse engineering of the model, and leakage of training data.
Encrypting the data structure representing inference model prevents attackers from gaining access to this valuable intellectual property. PSA recommends that Secure Processing Environment (SPE) handles model decryption keys in isolated protected subsystem in the device. Handling model decryption keys in SPE avoids exposing the keys to less secure application environment where they can be compromised by attackers.
Encrypted inference model often is part of the firmware image or root filesystem, and therefore will be programmed in the device’s flash memory during manufacturing. It is complicated and expensive to enforce strict control over access to sensitive cryptographic material in manufacturing environment. As a result, there is substantial risk that unauthorized access at the factory exposes model decryption keys to attackers compromising confidentially of the inference model. Manufacturing and provisioning procedures need to ensure that model decryption keys are kept secret from unauthorized personnel at the factory. There are multiple approaches to solving this challenge. Device OEM may install special-purpose provisioning equipment providing physical security at the manufacturing floor. Or they may use a more modern approach of creating initial root of trust in the SoC in trusted distribution facilities or during silicon manufacturing process. With this second approach, SoC parts are shipped to the factory pre-configured with the initial set of provisioning keys. These provisioning keys can then be used to securely deliver and install the model decryption keys. One of the key advantages of this approach is that provisioning of model decryption keys can take place during either assembly at untrusted contract manufacturing facilities, or later in the device lifecycle during device commissioning. It can even take place in the field after device connects to the backend systems.
Machine learning models in edge and endpoint devices can be easily compromised if the attackers get physical access to the device’s debug interfaces allowing full access to memory at any point of the device operation. To avoid this, debug interfaces of the SoC must be protected from unauthorized access.
This realized by supporting security life cycle in the SoC in accordance with PSA recommendations. PSA defines assembly, test, factory provisioning, provisioned, and debug life-cycle modes. Access to debug interfaces is only allowed in debug mode which are activated by authorized entities.
Attackers increasingly use the physical properties of the SoC, such as timing or voltage, to either extract information or manipulate logic to force unwanted behavior. Such attacks are called side channel attacks. Emergence of inexpensive and easily accessible automated side channel attack tools makes such physical attacks available to even casual hackers.
It is still too expensive and cumbersome to scale physical attacks to many devices at once. At the same time, extracting sensitive information from just one device using physical attack allows an attacker to mount a scalable software attack affecting hundreds and even millions of devices. An example of this would be model decryption keys or decrypted inference model.
PSA plans to provide PSA level 3 certification program testing countermeasures against physical attacks of different kinds.
To ease design and development of ML-capable SoC and applications at the edge, Arm provides Corstone-300 reference design. This integrates in one package, all the IP necessary to create highly efficient and secure SoC based on Arm Cortex-M55 and Ethos-U55.
Arm CryptoCell and CryptoIsland security IP are used by multiple chipset makers today to enable wide range of use cases, including creating PSA-certified SoC. The CryptoCell and CryptoIsland security IP from Arm support the necessary capabilities to design secure machine learning applications in edge and endpoint devices. These include secure key storage, decryption of inference models, provisioning at untrusted factories, secure debug, and protection against physical attacks.
The Arm CryptoCell family of IP focuses on providing essential cryptography and platform security services needed to build secure devices. The Arm CryptoIsland family of security IP in addition offers high levels of integration in a self-contained subsystem that can be used to build security enclaves.
To learn more about Arm Cortex-M55, Ethos-U55 processors and Corstone 300 reference design please visit https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/cortex-m55-and-ethos-u55-processors-extending-the-performance-of-arm-ml-portfolio-for-endpoint-devices.
[CTAToken URL = "https://developer.arm.com/ip-products/security-ip" target="_blank" text="Learn more about Arm Security IP" class ="green"]