5G Hotspot Hardware Specification
5G Hotspot Minimum Specifications
| Component | Minimum Requirement |
|---|---|
| CPU | x86_64 Linux compatible, 2.42 GHz Quad Core suggested, Must be TPM 2.0 compliant* |
| RAM | 4 GB |
| Storage | 64 GB: Both SATA and NVME SSDs are supported |
| Secure Element | Enhanced Secure Element required |
| USB 3.0 | Required for imaging process |
| Software | Rust, Python, Magma (check Magma dependencies) |
* FreedomFi partners only. TPM 2.0 not required for non-Freedom Fi partners
Security
Helium 5G/ Mobile Hotspots must have several security features in order to participate in the Helium network and receive network rewards. These include a secure boot process and a secure element feature for managing the cryptographic keys which identify the Hotspot on the network.
Secure Boot
Helium 5G/ Mobile Hotspots must only run authenticated firmware that has been provided by the manufacturer. This authentication process ensures that the Hotspot can be trusted by the rest of the network. This is especially important in the 5G network because Hotspots make observational reports on behalf of the entire network, such as:
- User Equipment ("UE") attachment events
- Signal strength (RSSI, RSRP, RSRQ)
- Upstream bandwidth measurements
Observational reports are ripe for “gaming” by the Hotspot owner because they directly impact the rewards that the Hotspot will receive.
When designed and used correctly, a secure boot process can overcome these problems, leading to a more resilient and trustable network.
Secure Boot Requirements
To be effective, the secure boot process you propose must meet these requirements:
- There must be a secure hardware boundary encompassing:
- A boot CPU
- A one-time programmable memory area capable of storing:
- A trusted public key (or hash of such a key) for authenticating external boot code.
- A device-unique secret key
- A cryptographic hardware element capable of public key and private key cryptography.
- An unalterable (fused or masked) boot ROM.
- A static RAM.
- The buss(es) within the secure hardware boundary must be protected.
- Activity on the bus cannot be inspected nor altered by any entity outside of the boundary.
- No outside entity shall be able to inspect the device-unique secret key in unencrypted format.
- No outside entity shall be able to alter the contents of the memory elements (SRAM, boot ROM, OTP memory) inside the boundary.
Secure Update Process
A manufacturer-controlled process encompassing:
- The external boot code signing key (private portion).
- A process for securely managing access to the signing key to trusted employees.
Enhanced Secure Element
Helium has always required a Secure Element for all Hotspots that participate in LoRaWAN (soon to be IOT) PoC rewards. This requirement will continue with the 5G network, however, the security requirements for 5G will be more strict than what is in place for LoRaWAN. To prevent confusion, these new requirements are known as Enhanced Secure Element.
An Enhanced Secure Element is one which performs cryptographic digital signature and shared secret derivation (currently ECDSA & ECDH) and does so only at the request of the verified and trusted firmware on the Hotspot. This requirement effectively means that the secure element must be bound the secure boot process.
Enhanced Secure Element Binding
The secure element needs to be installed in such a way that the identity (private key) inside the element cannot be easily removable or swappable. For example, secure element placement in a socket, PCI card, or any other device that is easily removable yet retains the private key after removal is unacceptable.
The secure element also should refuse to function unless it is under the control of the manufacturer’s verified firmware. A secure element which continues to function when the firmware has been altered or replaced is unacceptable.
Enhanced Secure Elements Requirements Questionnaire
When submitting your Hotspot design, please submit an Enhanced Secure Element amendment. The amendment should be phrased: "HIP19 amendments for alternate security implementations" and should answer these questions about the gateway’s private key:
- How is the private key loaded onto the device? (Is it generated on-device or is it imported externally?)
- Where is the device located when this happens? (Factory? A subsidiary? When booted by the end-customer?)
- What kind of non-volatile memory is used to store the private key?
- Is the private key encrypted when it is stored in this memory?
- If so, where is the key necessary to decrypt the encrypted private key stored?
- Again, if the key is encrypted, does each device possess its own unique storage key, or is it shared across all devices?
- Again, if the key is encrypted, is there also a verification check to ensure that the key has decrypted properly when it is loaded?
- How is the trusted code loaded?
- How is the code checked for authenticity when it is loaded?
- Who in your organization has access to the keys used for signing this code?
- Your implementation should have the ability to be updated. Please share the update method.
- 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).
- Considering the algorithms your implementation implements, are there certain operations/messages that you are aware of that the code must never perform lest it leads to an exposure of the private key?
- Does the code protect against these messages/operations?
- 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).
- 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).
- Does the code have any entry point such that an external entity can ask for the private key directly?
- What steps have you taken to audit the code for quality and ensure that it performs only as designed?
- Do you, the developer of this code, have the ability to extract the private key of a device?
- Will you, the developer of this code, have the ability to extract the private key of a device in the future?
Additionally, during the audit phase, please be prepared to provide an SDK and/or API (with header files if in C) that exposes the two cryptographic functions that your engine performs, and the source code to a simple program that uses this API to generate test signatures and Diffie-Hellman key agreement.
Re-Auditing and Hotspot
A Maker should notify the Helium Foundation of any changes made to an approved Hotspot(s), even if it does not require a re-audit or new HIP19 application.
Indoor and Outdoor Hotspots with the same hardware layout arriving together will be audited together (additional $500 fee). An example of this would be the same Hotspot model with the same hardware, but one has an exterior case making it an outdoor unit.
Different Hotspot models or indoor and outdoor Hotspots arriving at the same time with different hardware layouts will require a separate hardware audit (additional audit fee).
Indoor and Outdoor Hotspots arriving more than 2 weeks apart or with different hardware layouts will be audited separately.
Re-Audit Requirements
Re-audit (such as a change in model) will be required only if any of the following:
- Change from an indoor model to an outdoor model
- CPU changes
- RAM decreases
- Storage decreases
- Change in radio or radio location
- No re-audit is required if one SX130x PCIe card with the same chipset is swapped for another, such as SX1302 for SX1303.
- Change in security element
- Change in any parameter that requires regulatory recertification
Re-Voting on Radio Certification
If manufacturers add additional radio certifications after the MCC's initial voting and approval they will be invoiced for a fee of $2,000 (USD). All radio certifications must be in order prior to the initial MCC voting process. Due to an increase in requests for Radio Certification approvals, the MCC will only review new radio certifications once every 90 days for each manufacturer.
Fees can also be reviewed here.
Radio Certifications for China
The MCC has voted (December 2021) to require radio certifications for China. Manufacturers will need to provide radio certifications to be approved to sell in China. Previously approved Hotspots will have until May 1, 2022 to send in their radio certifications for China. If radio certifications are not provided by this date manufacturers will no longer be approved to sell to China.