Project:
Design Secure DIY Concentrator for HIP-22
Elevator Pitch:
HIP-22 is the next step in securing the Helium network. In addition to allowing DIY-hotspots it also increases the security of hotspots in general, removes the need for HIP-19 and prevents a number of cheating approaches.
Our intended design is unique in the sense that it doesn't interrupt traffic between the concentrator and the main CPU. The default lora-pkt-fwd software-libraries can still be used. The secure MCU monitors all the traffic and provides only certain signatures on the observed radio traffic, GPS locations and specific other operations. In addition to focussing on digital security, we will also propose physical anti-tampering methods.
We will select components that don't require an NDA and open-source the used firmware-code, schematics, layouts and manufacturing details
Design
The idea of this HIP-22 design is to have a secure MCU that monitors the SPI traffic that is used to receive and transmit RF-packets between the SX130x LoRA IC and the main CPU. This secure MCU will use a FIFO buffer to store any observed RF-packets with their properties. A ECDSA-signature can be requested of the observed packets in a format compatible to the blockchain. Basically the secure-MCU will be a replacement of the ATECC608 security IC, but it will refuse to sign any witness that it didn't observe.
Of course to be a full replacement, it will also support specific operations to support onboarding a hotspot. To (optionally) prevent location spoofing, the secure-MCU will also monitor the GPS UART and allow the observed location to be signed.
Development Board
To allow development of both the firmware and the integration of this HIP-22 concentrator in the gateway-rs software to start, a development board will first be designed and manufactured, possibly this requires a number of iterations. This development board has a mini-PCIe edge-connector to allow installation in most gateways. Most importantly it carries the secure MCU and the circuitry required to do the monitoring. As RF-frontend it will have a mini-PCIe "socket" to allow installation of readily available concentrators. Due to this socket, this development-board will be bigger compared to a full mini-PCIe form factor. However most gateways allow for bigger mini-PCIe PCBs.
Development Boards will be sold at cost-price to interested parties and will be provided to core developers. Please note that these development-boards are not HIP-22 compliant and are only intended for development. Lead-times of required secure-MCUs are high, so available volumes will be very low. All schematics and layouts will be designed in KiCad.
Secure MCU firmware
Using this development board we can start development of the secure MCU firmware to support the monitoring of the LoRA SPI and GPS UART interfaces and to sign specific messages containing data from these interfaces. The MCU firmware will be developed in FreeRTOS and open-source compilers will be used.
We will also develop a secure bootloader to allow over-the-air updates and develop the required procedures to allow for key-generation. Alongside the development of the secure MCU firmware, the required gateway-rs changes will be made. The source-code for the secure-MCU, any tooling and the changes to gateway-rs will be made open-source.
Secure Concentrator Design and Anti-Tampering
Based on the schematics of the development board, an actual secure concentrator will be designed and tested. This secure concentrator will have a full mini-PCIe form-factor, just like any other concentrator. This design may require a number of iterations. We will not only develop the concentrator itself, but also test the design in combination with a number of anti-tampering methods to make physical attacks on the board harder. This requires special attention because epoxy encapsulation normally used has an influence on the sensitive analogue circuitry as used on LoRa concentrators.
The schematics and design files of the concentrator will be open-sourced. We will also provide details about the manufacturing steps used to implement anti-tampering methods. By using a development board we can start the design of the secure concentrator while the software is still in development. All schematics and layouts will be designed in KiCad.
Tests according to the requirements of FCC and CE certification will be executed. However actual FCC and CE certification will be left to the manufacturers of the boards, as FCC and CE certifications cannot be carried over between manufacturers and manufacturing processes.
Roadmap:
Milestone
Deliverable
Summary
Cost
MS1
Development board designs ready. Development boards produced
The Development Board is produced and designs are available. After this milestone development of the firmware and software integration can start
15.000 USD
MS2
Firmware and software that can be used together with the development board to run a HIP-19 approved light-hotspot is working and published. Including “surrounding” tooling for OTA updates, and provisioning.
The firmware and integration in the gateway-rs code is working, allowing a light-hotspot using the HIP-22 development board to operate just like a HIP-19 approved light-hotspot.
40.000 USD
MS3
Secure Concentrator design files available and tested, including manufacturing instructions for anti-tampering. Including FCC and CE-like tests
The secure concentrator will be designed and verified. This will include anti-tampering methods.
Project: Design Secure DIY Concentrator for HIP-22
Elevator Pitch: HIP-22 is the next step in securing the Helium network. In addition to allowing DIY-hotspots it also increases the security of hotspots in general, removes the need for HIP-19 and prevents a number of cheating approaches. Our intended design is unique in the sense that it doesn't interrupt traffic between the concentrator and the main CPU. The default lora-pkt-fwd software-libraries can still be used. The secure MCU monitors all the traffic and provides only certain signatures on the observed radio traffic, GPS locations and specific other operations. In addition to focussing on digital security, we will also propose physical anti-tampering methods.
We will select components that don't require an NDA and open-source the used firmware-code, schematics, layouts and manufacturing details
Total fiat/hnt ask:
90.000 USD
Name and Address:
HeNet B.V. (also known as LongAP)
Code Repos of team or key applicants:
https://github.com/henet HeNet B.V. is the company behind the LongAP Helium hotspots.
Project Details:
Design The idea of this HIP-22 design is to have a secure MCU that monitors the SPI traffic that is used to receive and transmit RF-packets between the SX130x LoRA IC and the main CPU. This secure MCU will use a FIFO buffer to store any observed RF-packets with their properties. A ECDSA-signature can be requested of the observed packets in a format compatible to the blockchain. Basically the secure-MCU will be a replacement of the ATECC608 security IC, but it will refuse to sign any witness that it didn't observe.
Of course to be a full replacement, it will also support specific operations to support onboarding a hotspot. To (optionally) prevent location spoofing, the secure-MCU will also monitor the GPS UART and allow the observed location to be signed.
Development Board To allow development of both the firmware and the integration of this HIP-22 concentrator in the gateway-rs software to start, a development board will first be designed and manufactured, possibly this requires a number of iterations. This development board has a mini-PCIe edge-connector to allow installation in most gateways. Most importantly it carries the secure MCU and the circuitry required to do the monitoring. As RF-frontend it will have a mini-PCIe "socket" to allow installation of readily available concentrators. Due to this socket, this development-board will be bigger compared to a full mini-PCIe form factor. However most gateways allow for bigger mini-PCIe PCBs.
Development Boards will be sold at cost-price to interested parties and will be provided to core developers. Please note that these development-boards are not HIP-22 compliant and are only intended for development. Lead-times of required secure-MCUs are high, so available volumes will be very low. All schematics and layouts will be designed in KiCad.
Secure MCU firmware Using this development board we can start development of the secure MCU firmware to support the monitoring of the LoRA SPI and GPS UART interfaces and to sign specific messages containing data from these interfaces. The MCU firmware will be developed in FreeRTOS and open-source compilers will be used. We will also develop a secure bootloader to allow over-the-air updates and develop the required procedures to allow for key-generation. Alongside the development of the secure MCU firmware, the required gateway-rs changes will be made. The source-code for the secure-MCU, any tooling and the changes to gateway-rs will be made open-source.
Secure Concentrator Design and Anti-Tampering Based on the schematics of the development board, an actual secure concentrator will be designed and tested. This secure concentrator will have a full mini-PCIe form-factor, just like any other concentrator. This design may require a number of iterations. We will not only develop the concentrator itself, but also test the design in combination with a number of anti-tampering methods to make physical attacks on the board harder. This requires special attention because epoxy encapsulation normally used has an influence on the sensitive analogue circuitry as used on LoRa concentrators.
The schematics and design files of the concentrator will be open-sourced. We will also provide details about the manufacturing steps used to implement anti-tampering methods. By using a development board we can start the design of the secure concentrator while the software is still in development. All schematics and layouts will be designed in KiCad.
Tests according to the requirements of FCC and CE certification will be executed. However actual FCC and CE certification will be left to the manufacturers of the boards, as FCC and CE certifications cannot be carried over between manufacturers and manufacturing processes.
Roadmap: