UBITECH
The present blog comes from the presentations took place during the REWIRE Cybersecurity Awareness Webinar Series, entitled: “Trust or Bust: Reinforcing the IoT Interoperable Security Stack with Efficient Secure Lifecycle Management Capabilities – The RISC-V Opportunity”.
During the webinar session focusing on “Efficient and Scalable Attestation Mechanisms for RISC-V Devices”, Stefanos Vasileiadis and Nikos Varvitsiotis introduced the configuration integrity verification designed for the REWIRE project. In the present blog article we are going to explain the demonstration and setup on StarFive VisionFive 2 of the configuration integrity scheme on the StarFive VisionFive 2 board, with five terminals representing different components. These include an orchestrator, the attestation agent, the verifiable policy enforcer (VP), a dummy tracer, and the domain manager. For the set up of a demo case, while the domain manager would typically run outside the device, it should be included on the device for the creation of the demo, but without affecting the overall flow. In addition, the attestation agent and VP currently run as normal applications for the demo, but have been benchmarked as trusted applications.
In REWIRE, the execution modes include the Join, Runtime, and Software Update phases. In REWIRE, the first phase includes the device enrollment, the integrity verification during runtime phase and the SW update.
After running the onboarding phase, the device is ready to be included within the ecosystem of devices, after running a successful device enrollment process. To this end, during the Join Phase the steps that need to be followed are the following: a) the attestation agent sends its root ID public key and attestation key name to the domain manager via the helper client. b) the domain manager then sends back the credential, authorization digest, encrypted random secrets, and the IV for encryption to the helper client, which forwards them to the attestation agent c) the attestation issuer verifies the device state, sends the credential back to the domain manager, and the VP verifies the domain manager’s signature, after which the join phase concludes, and the device is enrolled.
After the successful onboarding and during the Runtime Phase for Integrity Verification, which is executed whenever a verifier requests proof-of-integrity. A main requirement is that the join phase must have been completed at least once before running the runtime phase and then upon initiating the runtime, a verifier sends a challenge to the helper client, which notifies the tracer to begin its runtime function. The tracer produces and signs runtime traces with its private key and sends them back to the helper client, which forwards them to the VP.
On the Runtime Verification and Signature Generation process, where the VP ensures the traces are from an authenticated tracer and that the attestation agent has not been compromised. The tracer authorizes the attestation agent to check the validity of the traces against their predefined policy. If the attestation agent confirms a valid device state and verifies the traces against the expected ones defined by the domain manager, it can then sign the verifier’s challenge with its attestation key. The resulting signature, along with the nonce from the verifier, is sent back to the verifier as evidence of integrity. These steps summarize the initial flow for a successful demonstration of the CAV on the StarFive VisionFive 2 platform, running on an actual device.