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, 2 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.

caution

The Manufacturing Compliance Committee ("MCC") is only currently accepting Light Hotspots and 5G Hotspots for audit at this time.


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 Outdoot 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 stopping and starting Packet Forwarder.
  3. Provide the location of the Packet Forward configuration file global_conf.json.
  4. Provide the path to the gateway-rs executable (ie: helium_gateway)
  5. Provide the architecture/distribution used by the CPU.
  6. Provide the commands to start and stop the gateway-rs executable (ie, helium_gateway)
  7. If using the ECC608 as a security element, provide the key slot and bus address
  8. Upon power up, is gateway-rs running and ready to audit? Y/N
    • gateway-rs must automatically update; the Auditor shall not update the firmware.
  9. Is the Hotspot using Helium's gateway-rs updater? Y/N

LoRaWAN Capable Full 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 Forward configuration file global_conf.json.
  4. Provide instructions for stopping and starting Miner.
  5. Provide location of miner data.

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 Forward 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 which 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.