Scottsigel
commented
3 years ago The code dependencies have been discussed with the core devs and they are supportive of the project.
Open dinocore1 opened 3 years ago
Scottsigel
commented
3 years ago The code dependencies have been discussed with the core devs and they are supportive of the project.
stefloyd
commented
3 years ago Beautiful project, I am enthusiastic. Thanks
Project:
Design Secure DIY Concentrator for HIP-22
Elevator Pitch:
We propose designing a 100% open-source DIY Concentrator hardware prototype for use as a reference implementation of HIP-22. This grant proposal would fund development of electrical schematics, PCB board design, firmware, and corresponding software changes needed to build a DIY Concentrator in accordance with the HIP-22 vision.
Total fiat/hnt ask:
61,000 USD
Team or key applicants:
Paul is a senior software/firmware engineer with a specialty in embedded systems and C and C++ programming languages. Paul has 15+ years of experience working professionally at several startups in the Boston area. Paul has written firmware for several novel hardware products including hand-held X-Ray and LIBS analysis devices and a hand-held X-Ray imaging product.
RAK Wireless is a leading provider of LoRa and cellular connected IoT devices. RAK willprovide engineering hours to help design the electrical schematic and board layout. RAK will alsomanufacture PCB prototypes.
[https://github.com/dinocore1](team member Paul github: https://github.com/dinocore1)
[https://github.com/RAKWireless](organization RAK Wireless)
Project Details:
Technical Objectives:
The new hardware architecture for DIY Concentrators is based on Semtech’s LoRa Corecell Gateway reference design. The major change involves the addition of a Secure MCU placed in between the communication path of the Host CPU and the SX1303. The Secure MCU’s primary job is to cryptographically sign RF data received over the air such that other nodes participating on the Helium network are able to verify the data is authentic and unaltered from it original form.
The MCU stores a unique cryptographic private key generated at manufacturing time in its non-volatile memory. It is important to note that the MCU’s private key is not the same as the Host CPU’s libp2p swarm key. The private key is considered a secret and stored in a special section of the MCU non-volatile memory used for secure storage. The MCU prevents read-out of secure storage using debugging tools and the like.
The secure MCU acts as a data proxy between the Host CPU and SX130x. It forwards SPI read/write commands passing data back and forth unaltered. In fact, most of the time, the MCU does not need to be aware of the contents or meaning of the data it is transferring. The exception to this rule is when dealing with received RF data.
When LoRa RF data is received over the air, it is temporally stored in a special FIFO buffer located on the SX1303 (RX DATA BUF DATA). Periodically, the Host CPU will send a SPI command to read the contents of the RX DATA BUF DATA. When this operation is performed, the MCU will also keep a local copy of the data in RAM. After reading the RX DATA BUF DATA, the Host CPU can send a new command to the MCU to read the digital signature of the the RX DATA BUF DATA.
There are some changes to the Helium blockchain transactions required to support the new DIY Concentrator architecture. When hotspots receive a PoC Beacon over the air, they respond back to the Challenger with a poc receipt v1 message via libp2p. To support the new architecture, the poc_receipt and poc_witness type message will need to contain the hardware signature of the RF data. Additionally, Validators will need to check the signature of each poc message type.
Proof of Concept with Software Emulation
To prove feasibility of the DIY Concentrator, Paul will write a thin software emulation layer to simulate the new hardware architecture. The functionality of the Secure MCU will be simulated in Semtech’s packet forwarder application. The modification would simply add the newly proposed hardware signature field to the JSON object for rxpk types exactly as a real Secure MCU would on a DIY Concentrator. The Proof of Concept code will run on a Raspberry Pi with a RAK2287 RPi HAT and RAK2287 Concentrator. In this way, software development to support the new hardware architecture can begin well before actual hardware is available. Also, because the emulation code will run on a Raspberry Pi device with a RAK2287 Concentrator, it can be used for real-world testing on the TestNet.
Paul will create a branch of the Semtech packet forwarder application on Github. When the emulation code is ready, he will issue a pull request to the official Helium fork. Paul and Helium’s core developers (and/or Erlang blockchain developer) will collaborate to make the necessary changes to Helium’s Miner project. The proposed changes are outlined in the document Secure DIY Concentrator Project (HIP-22). Paul does not have experience with Erlang programming language and will require Helium’s core developer (and/or Erlang blockchain developer) to write code changes. When this milestone is complete, it will be possible to run full Proof of Coverage hotspot on a Raspberry Pi + RAK2287 in TestNet.
Hardware Design and Prototype
Paul and electrical engineering resources from RAK Wireless will collaborate to develop electrical schematics, BOM, PCB board layout, and routing design documents. Collectively, these documents represent everything required for a PCB fabrication facility to build PCB prototypes. Paul and all other electrical engineers will use a shared Git repository to store all engineering documents. The Git repository will be hosted publicly on Github under the Helium account (https://github.com/helium). All engineering documents will be licensed under open-source MIT license or equivalent.
Paul’s primary responsibility related to this milestone are to oversee development of electrical schematics and PCB prototypes. Paul will create high-level block diagrams, provide technical requirements, and meet with the RAK engineering team on a regular basis. RAK’s primary responsibilities related to this milestone are to develop electrical schematics, BOM, create PCB routing and layout documents, and to build PCB prototypes. We anticipate needing up to three PCB revisions before finalizing the PCB design. Each revision will have its own design, fabrication, and testing phases. RAK will deliver at lease two PCB prototypes of each revision to Paul for firmware development and testing purposes.
Secure MCU Firmware Development
Paul will write the firmware for the DIY Concentrator’s secure MCU. The primary function and basic criteria for success of the firmware is to digitally sign LoRa data received over-the-air. Additionally, the firmware will implement secure storage of the private key and will implement secure boot and secure firmware upgrade. These security features are critically important to the success of DIY Concentrator and will be implemented on the final version of firmware. However, the security features will not be implemented until after the initial beta version of firmware is functional. The firmware will be written in C programming language and will make use of FreeRTOS. C language is an excellent fit for microcontroller firmware development due to its rich development tools and availability of example code and libraries. Paul will store all firmware source code in a Git repository hosted under Helium’s Github. All source code will be licensed open-source MIT license or equivalent.
In addition to firmware development, Paul will also provide documentation needed for manufacturing DIY Concentrator including firmware installation instructions and key provisioning. The final version of firmware (and all future updates) will be digitally signed with the Firmware Key. The Firmware Key is considered a high-priority secret and should be under Decentrialized Wireless Aliance (DeWi)’s control only. Paul will work with DeWi resources to develop a secure process firmware signing process.
FCC Certification
The final PCB revision will be submitted to a FCC approved laboratory for certification testing. The lab will perform all necessary testing and handle the full certification process.
Roadmap: