Weeve Testimony Technical Deep Dive

This blog is a continuation and final part of 2 blog series of “Weeve Testimony” product technical overview. We are covering the client-side technical details of Weeve Testimony, it runs on Arm Trustzone based microcontrollers such as Arm-Cortex-M23/M33.

Weeve Testimony Client in Action

In the previous post, we described the different component of Testimony client and necessary steps to generate an instrumented firmware so that original application firmware is made aware of Testimony trusted application(Testimony TA, guard process running in Trustzone) and also made to pass control flow information to Testimony TA.

Now we will see what happens at runtime. Below is a GIF that animates the thing a little bit. In this example, we will see how a C-function call is protected using Testimony. In original firmware a Login() function is called from somewhere. Now when this firmware is patched or instrumented using Testimony Patcher tool, the call to login is replaced with another routine trampolineBL(). Since the original binary is modified, Testimony tool has already made available the original source and destination addresses in BranchTable. The dark green component in below diagram indicates the Testimony TA, NotifySecureWorld() is a API in TA.

Weeve Testimony Control Flow Integrity in Action

Step 1. When the normal world process runs the instrumented firmware and a control flow instruction is executed, it jumps to trampolines routine TrampolineBL() instead of original Login() function. TrampolineBL() saves the current processor state. The current processor state also provides the information from which sourceAddress 0xC5AE the Trampoline routine is called.

Step 2-3. Using sourceAddress 0xC5AE, TrampolineBL() searches(BinarySearch()) the BranchTable to find the originalDestinationAddress 0xC568.

Step 4–5. Trampoline TrampolineBL() passes this control flow information tuple {sourceAddress, originalDestinationAddress}{0xC5AE, 0xC658} to Testimony Trusted Application(TA) running in Arm Trustzone, a call to NotifySecureWorld().Testimony TA cumulatively hashes the above control flow information.

Step 6–7. After returning from Trustzone call, a call to original intended function Login()(Branch BX to address 0xC568) is made.

The above steps(1 to 7) are run for all control flow branches i.e. the function calls-returns, if-else, goto block, and loops of a C-program of the binary.

With the help of Weeve Testimony Run Time Profiler Tool, running multiple times with varying input to the whole program with a fair coverage of the program, a set of golden hashes is captured and stored. A single golden hash represents a valid execution flow path of “the whole program for a given input”, not to confuse with the hash of a single control flow information tuple {sourceAddress, originalDestinationAddress}.

Weeve Testimony Remote Attestation

All these golden hashes with corresponding program inputs are stored in a database in a remote attestation server.

1. A remote attestation server challenges a remote device running Weeve Testimony protected firmware to prove its control-flow integrity, optionally for a given program input.
2. Weeve Testimony Trusted Application running on device prepares a device-specific cryptographically signed authenticated response with the latest calculated control flow golden hash. For this part we intend to follow Arm Platform Security Architecture(PSA) remote attestation shown below for maximum interoperability of our solution.
3. The server Upon receiving the device response, the remote attestation server validates if the respondent golden hash matches with one of the available hashes. If the integrity check fails, the subscribed parties are notified to take action against the device. Depending upon the severity of the deployed use case, these actions could be as simple as rejecting all data coming from the device to forcefully updating the firmware on the device.

ARM PSA Remote Attestation, courtesy Arm Inc.

We are looking to partner with microcontroller vendors and device manufacturers having Arm-Cortex-M23/M33 based devices to test, tune, and ship our product. Currently Testimony client runs on Nordic Semiconductor’s NRF9160DK boards and ZephyrOS.

We love OSS and will be open-sourcing the Testimony client implementation in coming months.
Please reach out at info@weeve.network for any information related to our products and me for your valuable feedbacks on this post.