The repository contains a link to the Zenodo repository of the Board Support Package (BSP) for the AMD Xilinx ZCU104 of the Petalinux project to implement the MQTT client node of the Digital Manufacturing Internet-of-Things Pilot demonstrator (a.k.a. Pilot 1) MPU version for the QUBIP project (https://qubip.eu/). Refer to the following lines for the upstream version of the project:
- Current Version: v2.0
- Name of the BSP: qubip_dm_iot_mpu_2v0.bsp
- SHA256 of the BSP: 2ec72f04f59b64aab9fb0a27386c2cd6953bd8b37818978385a6e0994a89c53b
- DOI: 10.5281/zenodo.21355541
- Link: https://zenodo.org/records/21355541
The BSP package contains all the necessary files and scripts to recreate the Petalinux and Vivado projects for the PQC-protected MQTT client device on an AMD Xilinx ZCU104 development board (https://www.amd.com/en/products/adaptive-socs-and-fpgas/evaluation-boards/zcu104.html). The whole project has been created using the following tools and operating system:
| Purpose | Tool | Version |
|---|---|---|
| Software and Firmware | Petalinux | 2024.2 |
| Hardware | Vivado | 2024.2 |
| Host OS | Ubuntu | 22.04LTS |
The main device implementing the MQTT client is the AMD Xilinx Zynq UltraScale+ XCZU7EV-2FFVC1156 MPSoC. Both, the Programming System (PS, hard-macro processors) and the Programmable Logic (PL, FPGA resources) are used in this project.
The re-generate the project starting from the BSP, it is recommended to, at least, use the same version of Petalinux and Vivado tools mentioned above to avoid compatiblity issue. Once downloaded the BSP file, open a terminal and enter what follows:
petalinux-create project -s <bsp-package> -n <path-to-project>This command will create a folder with the whole project. As some components are built out-of-tree, we strongly suggest to use the automated shell script to build the project.
cd <path-to-project>
cp <path-to-this-git> automate_build.sh
./automate_build.shAfter the build, the output artifacts in the images/linux/ folder needs to be packed to be written in a properly formatted micro-SD card (see https://docs.amd.com/r/2024.1-English/ug1144-petalinux-tools-reference-guide/Preparing-the-SD-Card). It is important that the micro-SD card has two partitions, as the rootfs partition is used a non-volatile storage and it will be available at /home/petalinux/card/. This partition is useful to store keys and certificates. Before packing, copy the fsbl.elf file to the images/linux/ folder, as this particular FSBL can enable OPTEE for measured boot and remote attestation.
In case secure boot is needed, please do refer to [cinhgioGithub's repository for optee] (https://github.com/cinghioGithub/petalinux-optee-zynq-zcu104), as the board needs to be prepared for the decryption key and the aforementioned artifacts needs to be properly encrypted. It is also possible to enable measured boot as well as remote attestation features (ensure that the keylime package is included in the build). To enable all these features during the packing, please refer to the transfer_SD.sh script.
This will generate the following files:
- BOOT.BIN
- image.ub
- boot.scr
Once these artifacts are properly transferred on the micro-SD, it is sufficient to power-up the ZCU104 with micro-SD card inserted in the the dedicated slot. At the boot, an MQTT-client and a MODBUS server will spawn automatically and will start to gather and publish data to the given MQTT broker. You can customize the broker parameters as well as the MODBUS server parameters in the start_mqtt_composite.sh or start_mqtt_classical.sh files in the project-spec/meta-user/recipes-app/mqtt-client/files/ folder.
The Petalinux build has only two functional users:
- root (no password needed, USE AT YOUR OWN RISK!)
- petalinux (default password petalinux, AS ABOVE!)
Users, passwords and configurations can be easily changed by using the "petalinux-config" command, before build.
To open a simple shell on the system, it is enough to connect the board to a host computer with a USB cable connect to J164 (near the micro-SD slot), and use a terminal like minicom or PuTTY, configured to a baudrate of 115200bps. On Linux systems, the board is enumerated with 4 USB endpoints. Assuming that its enumeration starts at ttyUSB0, the proper endpoint to use for this connection is ttyUSB2:
minicom -D /dev/ttyUSB2 115200If the packing has included also OPTEE, the secure OS will log on ttyUSB1.
The project contains many useful tools and applications for MQTT and PQC/PQC-hybrid TLS connection, backed up by the hardware acceleration offered by the SE implemented on the PL part of the Zynq. A block diagram of the implemented system is shown below:
The py-mqtt-client.py is a Python3 script that allows the system to act as a MQTT publisher towards a remote MQTT broker with mutually authenticated TLS, where the published value comes from the local MODBUS server. The py-mqtt-client.py script leverages on OpenSSL 3.2.3 to perform the mutually authenticated TLS connection. The PQC and PQC-T functionality are enabled by the OpenSSL3 compatible provider libaurora, which is a porting of the QUBIP's PQC Provider for OpenSSL (see https://github.com/QUBIP/aurora) that leverages on the hardware Secure Element (SE) (see https://github.com/QUBIP/pq-se) connected to the PS through the AXI4 on-chip interface.
The hardware Secure Element functionalities are available for the operative system by means of a dedicated kernel module namely telsy_mod, also available in the BSP.
The py-mqtt-client.py is launched with the following command:
python3 py-mqtt-client.py --ca-cert <CA_certificate> \
--client-cert <client_certificate> \
--client-key <client_key> \
--modbus-ip <modbus_server_ip> \
--modbus-port <modbus_server_port> \
--modbus-register <modbus_server_register> \
--mqtt-broker <mqtt_broker_ip> \
--mqtt-port <mqtt_borker_port> \
--mqtt-device-name <device_name> \
--mqtt-topic <mqtt_topic>As previously mentioned, a dedicated systemd service, named mqtt-client.service ensure that the MQTT publishing functionalities is started as soon as there is an available connection (through the ethernet interface). A similar service is spawned for the local MODBUS server which can receive requests from remote PLC.
In addition to the default set of algorithms and implementation supported/provided by the baseline OpenSSL3.2.3, we do support:
| Algorithm | SE-backed | Type |
|---|---|---|
| X25519 | Yes | Classical |
| Ed25519 | Yes | Classical |
| ML-KEM-[512/768/1024] | Yes | PQ |
| X25519MLKEM768 | Yes | PQ/T |
| id-ml-dsa-[44/65/87] | Yes | PQ |
| id-MLDSA44-Ed25519-SHA512 | Yes | PQ/T |
| id-MLDSA65-Ed25519-SHA512 | Yes | PQ/T |
| SLH-DSA-SHAKE-[128f/192f/256s] | No | PQ |
Our custom kernel module support also all other algorithms that are not listed above but provided by the hardware Secure Element. We did not include all of them in the embedded Linux version of the aurora provider at this time.
The system is configured to run as ramdisk, therefore all the changes to the system once the system itself is running are volatile. This has been necessary to correctly run the OPTEE secure OS on this specific platform. The complete system with all security features enabled (remote attestation and measured boot included) requires a ZCU104 board that supports the cryptography extensions. As far as we know, the only version of the board that does not support cryptographic extension on the Cortex-A53 cluster is the EK-U1-ZCU104-G-ED. We mainly used the EK-U1-ZCU104-G for our development and tests.
See LICENSE.
The BSP we prepared includes build recipes and integration logic for third-party components. Certain proprietary software components (e.g. ARM Mali Userspace Driver and firmware) are not included in this repository and must be obtained directly from the vendor under their original licence terms during the build process.
- Davide Bellizia (davide.bellizia@telsy.it)
- Agostino Sette (agostino.sette@telsy.it)
- Ruggero Russo (ruggero.russo@telsy.it)
- Fabrizio Gambetti (fabrizio.gambetti@telsy.it)