Skip to main content

Hotspot Audit Process

The hardware audit will require two hardware samples of each Hotspot. For example, if the audit includes indoor and outdoor Hotspots, two of each model are required for submission.

Hardware samples submitted to auditors should be identical to the final hardware sold to customers, including the final enclosure. Prototypes or 3D-printed enclosures are not acceptable for hardware audits.

Documentation Submission Requirements​

PDF Only

Submit all documentation as a single PDF. Do not send Word documents, Excel spreadsheets, or other non-PDF formatted documents.

Each hardware audit requires a PDF copy of the responses to the following questions. Please organize answers in order, and send the document electronically in one PDF with a response to all questions.

Hardware audits are expected to take a minimum of 7 weeks from the time auditors receive hardware samples and payments. Missing information will result in significant delays.

Identifying Hotspots and Components​

  1. Clearly label the hardware with the company name.
  2. Clearly label the hardware with the Hotspot(s) model name(s).
  3. Include a link to the HIP-19 Application.
  4. Ensure the HIP-19 Application matches the hardware and related documentation.
  5. Specify the Hotspot for audit type, Light or Mobile/5G.
  6. If this is a Mobile/5G, specify whether the Hotspot has LoRaWAN capability.
  7. Specify if Hotspot is an indoor or outdoor Hotspot.
    • If only an indoor Hotspot is submitted, state whether or not auditors should expect an outdoor Hotspot later.
    • If only an outdoor hotspot is submitted, state whether or not auditors should expect an indoor Hotspot later.
  8. Include a block diagram (see example) with clearly labeled locations of the security implementation (ECC chip, TrustZone, etc.).
    • A block diagram is a system diagram with CPU/ MCU, memory, ECC/ other security, etc., with all circuits clearly labeled with part numbers.
    • Include a sketch or photo indicating the location of the security module on the PCB.

Auditor Access To Your Hotspot​

LoRaWAN Capable Hotspots​

  1. The Hotspot should arrive running as it would be at a customer's location.
  2. Provide instructions for ssh access.
  3. Provide instructions for stopping and starting Packet Forwarder.
  4. Provide the location of the Packet Forward configuration file global_conf.json.
  5. Provide the path to the gateway-rs executable (ie: helium_gateway)
  6. Provide the architecture/distribution used by the CPU.
  7. Provide the commands to start and stop the gateway-rs executable (ie, helium_gateway)
  8. If using the ECC608 as a security element, provide the key slot and bus address
  9. Upon power up, is gateway-rs running and ready to audit? Y/N
    • gateway-rs must automatically update; the auditor will not update the firmware.
  10. Is the Hotspot using Helium's gateway-rs updater? Y/N

5G Only Hotspots​

  1. The Hotspot should arrive running as it would be at a customer's location.
  2. Provide instructions for stopping and starting Packet Forwarder.
  3. Provide the location of the Packet Forwarder configuration file global_conf.json.
  4. Specify which CBRS radio brand and models are compatible with the 5G Hotspot.

Radio Certifications​

  1. Specify which radio certification intentions.
  2. Specify country/region sales intentions.
    • The MCC will only vote once all radio certifications are complete. Therefore, MCC will not vote on reports only as certifications and reports expected at the time of voting.
  3. Specify whether Hotspots will be sold in a frequency that requires "Listen Before Talk" or "Listen Before Transmit"? Y/N
    • e.g., Japan, South Korea
  4. Specify whether Hotspots will be sold in the AU915 region. Y/N
    • If yes, certify that you can also operate under AS923-1.
    • Transmit test must be checked on AS923-1 channels
    • AS923-1-AU
    • The default AS923-1 freq band ranges from 915 to 928 MHz
    • Verify transmit from 915 to 928 MHz at every 200 kHz interval (915.2, 915.4 ... 927.6, 927.8). At all data rates, i.e., DR0-DR7 (including the FSK)

Notes On FCC​

  1. Provide the FCC ID number in addition to the certification.
avoid delays

Read the Helium PoC FCC Guidelines documentation.

Incorrect FCC certification will experience significant delays, months or more.

Additional Information for Audits​

  1. Explain the OTA/firmware update process.
    • Show the process by which firmware updates are cryptographically verified.
  2. Specify whether or not there is a dashboard or other interface on the Hotspot that allows it to be controlled over the network. Y/N
    • If Yes, this dashboard must require a password that is unique per device and sufficiently random so as to not be guessable or other secure token to access.
  3. Specify whether or not the Hotspot has production-ready firmware, including an over-the-air (OTA) update process for the miner. Y/N
  4. Confirm understanding that the Helium Hotspot app will not be available for customer use after March 1st, 2022? Y/N
  5. Specify whether or not a Maker App for customers to onboard has been created. Y/N
Maker Apps Are Required

A Maker App must be created and tested to continue with the hardware audit.

Additional Information for 5G Hotspots​

  1. Provide a gateway_mfr utility to access the secure element.
  2. Show the secure boot hardware via a diagram.
    • The diagrams should include all the hardware involved in the boot process and the security boundaries of each component.
  3. Hardware items to illustrate include (but are not limited to):
    • Cryptographic hardware accelerator
    • Secure storage for private/secret and public keys
    • Secure RAM
    • Boot ROM
    • Untrusted external RAM
    • Untrusted external non-volatile storage (eMMC, SATA, etc)
    • Communication busses
  4. Using callouts to the secure boot hardware diagram, show how the system can determine that the firmware that it is booting comes directly from an authorized source and has not been altered.
  5. Show how the Secure Element, which contains the private key that identifies the Hotspot on the blockchain, will only obey encryption, decryption and signature generation requests if they come from authorized firmware.
tip

Diagrams must also show the security boundaries of the design. Group each component and bus by the boundary it resides in.

Additional Information needed for TrustZone-based Security Elements​

TrustZone is a security system available on some ARM-based System-on-a-Chip (SoC) designs. When used correctly, a TrustZone-based secure element should be acceptable for use in Hotspots that participate in the PoC system. If you have submitted a TrustZone-based security implementation, please answer the following before the hardware audit:

  1. The code presumably performs several functions using a private key. How is the private key loaded onto the device? (Is it generated on-device or is it imported externally?)
  2. Where is the device located when this happens? (Factory? A subsidiary? When booted by the end customer?)
  3. What kind of non-volatile memory is used to store the private key?
  4. Is the private key encrypted when it is stored in this memory?
  5. If so, where is the key necessary to decrypt the encrypted private key stored?
  6. Again, if the key is encrypted, does each device have its own unique storage key, or is it shared across all devices?
  7. Again, if the key is encrypted, is there also a verification check to ensure that the key has decrypted properly when it is loaded?
  8. Since your implementation is mostly in software, how is the trusted code loaded?
  9. How is the code checked for authenticity when it is loaded?
  10. Who in your organization has access to the keys used for signing this code?
  11. Presumably, your implementation can be updated. Will your code update mechanism prevent “downgrading” to a previously authorized version? If so, how?
  12. What specific signing, encryption, decryption, or verification operations can an external entity ask the code to perform? (External entity means code outside the secure element, such as, say, the Helium “miner” process).
  13. Considering the algorithms your implementation implements, are there certain operations/messages that you are aware of that the code must never perform that would lead to an exposure of the private key?
  14. Does the code protect against these messages/operations?
  15. What side-channel attacks does your implementation work to avoid, if any? (As a reminder, side-channel attacks extract key information from variations in timing, power, temperature, electromagnetic fields, etc).
  16. What fault-injection attacks does your implementation work to avoid, if any? (As a reminder, fault-injection attacks include power-glitching, laser pulses, strong EM fields, etc).
  17. Does the code have any entry point such that an external entity can ask for the private key directly?
  18. What steps have you taken to audit the code for quality and ensure that it performs only as designed?
  19. Do you, the developer of this code, have the ability to extract the private key of a device?
  20. Will you, the developer of this code, have the ability to extract the private key of a device in the future?
  21. Please provide an API or simple program that we can use to generate the test signatures and Diffie-Hellman key generation.
  22. Please provide us either SDK or the header files that we can use or can write C or an example Python program. Provide a simple interface that exercises the two cryptographic functions that your engine does.