Security is an important consideration for healthcare devices, so we have taken care to ensure the HealthyPi 5 provides a secure platform. Since the start of the campaign, we’ve received a few questions about security from our backers, so we thought we’d answer them in this quick update. Security, and medical device security in particular, is a vast and multifaceted topic that cannot be covered in its entirety here. However, we have attempted to cover the basics of the security capabilities in the latest version of the HealthyPi 5.

A New Microchip Crypto Chip

A last-minute update to the latest HealthyPi 5 (v5.3) design is the addition of an onboard Microchip ATECC608A crypto chip called as a "secure element;" it’s used to store the private key and provide other crypto capabilities. The combination of this secure element with the Zephyr OS running on the RP2040 provides a secure, future-ready platform for the HealthyPi 5. Here are a few examples of how this works:

Firmware signing and encryption

The private key stored in the secure element can be used for several functions of the HealthyPi 5 workflow, including signing the firmware image, encrypting the data files, and communication security. The private key cannot be read out, which is why it’s called "private". Meanwhile, the public key is used to verify the firmware signature to make sure it is from a secure source. Once the bootloader is up and running, the device can be updated using either over-the-air (OTA) or USB-based device firmware upgrade (DFU).

To verify the integrity or find any tamper-evidence of the firmware, the image is signed using the private key and the signature is stored in the firmware image. The bootloader then verifies the signature before loading the firmware. If the signature verification fails, the bootloader will abort, avoiding the download of malicious firmware to your device. This ensures that only the firmware that was meant to be loaded on the device is loaded (this is not fixed by us, but the private key also be available to developers). If you would like to know more, Memfault has a good blog post on the use of code signing.

Unique Identification and authentication

If the HealthyPi 5 is connected to the cloud or a BLE app, mutual identification of the device is important to prevent any attacks. The ATECC608A secure chip has a unique serial number which is used to identify the HealthyPi 5. This allows the device to scale and work with mutiple cloud-based IoT platforms with no ambiguity about the integrity of the received data. The device ID can also be used to generate a unique encryption key which is used to encrypt the data transmitted from the device to an external data receiver.

Secure data logging, storage and communication

The HealthyPi 5’s Zephyr-based firmware supports the encryption of data stored on the device. This is especially useful for certain clinical research applications where privacy of the data is critical. For this case, the data is encrypted using the unique encryption key generated from the device ID (described above). When the data transfer is inititated, both the sender and receiver first do a Key Exchange process, which is supported in hardware by the secure hardware element chip.

The same concept is applied to data going in and out of the device as well. Although wireless protocols have their own security architecture, if you wish to add an extra layer of encryption, this can be done in the Zephyr application before the data leaves the system. This is also of great use in a multi-processor system such as the HealthyPi 5 where there is a channel of communication between the RP2040 and the ESP32C3 processors on the same board (consider a hacker who has access to the devices and could listen to data transferred between the two chips).

Support for security in Zephyr

At the time of writing, basic functional security, including the cryptographic algorithms and protocols, is supported in Zephyr. Support for hardware secure elements is limited at this time, but we will provide any drivers for using the secure element for security as needed. Zephyr security functionality currently provides support for the following:

• TinyCrpyt 2 Cryptographic algorithms library (tiny footprint, limited algorithms)
• Execution protection and memory protection for the Zephyr kernel and application code
• Open design - security is not a black box on Zephyr, you can see the code and understand how it works
• Monolithic binary - the entire firmware including the kernel, drivers, and the application are signed and encrypted as a single binary without the need to load separate modules in runtime.
• Works well with MCUBoot for a secure boot process, including support for bootloader code signing and encryption
• Support for certifiable security applications where cybersecurity is critical (e.g., FIPS 140-2 or Common Criteria)

We will have a better picture of security support as we near completion of the Zephyr firmware and we will post an update once that happens. Meanwhile, if you would like to see anything specific in the security implementation or you see any glaring security issues, please let us know.