WebAssembly: A "C Change" for Embedded Device Security

Summary from the full blog on Atym's website

Implementing appropriate cybersecurity measures has historically been especially difficult in the embedded space due to the skills required, tight code coupling to resource-constrained and heterogenous hardware, and broad geographical distribution.? Organizations are faced with “right sizing” security measures for their products while providing an excellent user experience, maximizing profit, and complying with regulatory requirements.???

A good starting point to strike a balance between these goals is borrowing from cloud practices in terms of zero trust security, modularized software, hardware abstraction and continuous integration and delivery (CI/CD). In recent years, data center technologies like Docker and Kubernetes have made their way to capable edge hardware but there has been a gap for resource-constrained devices.?The adoption of WebAssembly is changing this – enabling developers to build secure embedded edge solutions similarly as they would in the cloud.???

Initially designed as an augmentation for JavaScript in web browsers, WebAssembly (Wasm) is increasingly being leveraged for cloud architectures and edge use cases.? Wasm was designed with security as a top concern, and its light footprint makes it especially suitable for resource-constrained devices, including ones powered by microcontrollers (MCUs).??

Some of the key elements of the Wasm security model include:?

• Wasm modules are designed to execute within a sandboxed environment, meaning they are isolated from both the host hardware and other software modules.? Since each module is a virtual machine instance, it provides an increased level of isolation over even Linux-based containers such as Docker.?

• By default, access outside of the Wasm virtual machine is not possible.?Only explicitly injected interfaces can be called from within the VM, supporting a zero trust security posture.?

• Wasm modules have restricted memory access, only being able to access their own allocated memory.? This effectively creates a “soft MMU” for MCU-based devices. Further, Wasm code can’t jump to arbitrary addresses or execute data in non-code locations (e.g. data memory).? This prevents a large variety of potential code vulnerabilities.?

• Wasm provides a protected call stack to prevent vulnerabilities due to buffer overruns.?Traps provide a way to immediately terminate execution in the case of abnormal behavior.? If termination occurs, only that specific container/VM is affected, and control is returned to the underlying runtime for handling.?

Atym takes this a step further by integrating WebAssembly into our full device edge orchestration platform.? Enabled by the open source Ocre device runtime, our solution greatly simplifies developers’ ability to implement robust zero trust security measures for embedded devices powered both by CPUs and MCUs with as little as 1MB of memory. They can do so while reusing legacy code investments alongside new applications written in choice of programming language.?

Some examples of how Atym's commercial offer further enhances security include: ?

• Container Orchestration – The central Atym Hub orchestrates and manages application containers deployed on the Atym Runtime and has full control over when and how container modules execute.? Policy can be enforced for fault handling should a container start exhibiting security vulnerabilities or terminate unexpectedly. A specific compromised container can also be quarantined so the remaining containers can continue to operate on a device. Fractional container updates means that only necessary code needs to be replaced.?

• Marshalled Execution – Access to any device resource can only happen through the Atym Runtime.? Direct access to any hardware resource is never granted directly to Wasm code.? For example, if a socket is opened from code within a container, all access to that socket is brokered by the Atym Runtime based on policy established through the Hub.???

• Granular Permissions - Each container needs to have permissions to call specific sets of APIs.? For example, a container would need the “network” permission to call methods for making network connections.? Without this permission, the Atym Runtime will not allow the call to execute, and the container can automatically shut down if configured to do so per security policy.????

• Container Signatures – Devices can be configured to execute only code that has been signed.? This integrity check ensures that 1) only code from trusted sources is allowed to run, and 2) container code has not been modified.? Like container permissions, this provides an additional layer of defense in depth.? The overall process of signing certificates can be fully controlled by the end user so Atym does not have access to the signing secrets.?

• Bookended AOT Compilation Process – Atym employs Ahead-of-Time (AOT) compilation of Wasm modules to optimize each instance for the specific architecture of the target hardware to yield near-native performance.? This AOT compilation process is fully managed in the Atym Hub and is performed seamlessly when application containers are deployed to the Atym Runtime on edge devices.? This “bookending” eliminates the potential for an attacker to hijack the compilation/optimization process to inject or run infected code on deployed devices.?

• Simplified Regulatory Compliance – The Atym solution helps developers programmatically address regulatory requirements like the Cyber Resiliency Act while requiring less specialized developer skills than traditional embedded firmware and software.? Separation of code provenance helps with SBOM compliance, and developers can “lift and shift” existing C/C++ code into protected containers while developing new applications in memory safe programming languages.?

Our mission is to help our customers strike a balance between implementing appropriate cybersecurity measures, accelerating innovation, meeting budget and schedule, and scaling field deployments. As part of this, we're committed to helping customers address growing cybersecurity regulations such as Software Bill of Materials (SBOM), the Cyber Resiliency Act (CRA), and utilizing memory safe programming languages.??

Check out the full blog for a deeper dive on macro trends that are necessitating a new approach for embedded device security and how WebAssembly has emerged as a key enabling technology. Make sure to follow us here on LinkedIn for future content and updates!