PointPerfect Key Management – u-blox Services

Dynamic Keys in UBX format

For the u-blox receivers that are in devices that do not implement a UBX parser, the users can subscribe to the following topic to get the keys in UBX format and transfer them to the receiver without having to construct the message. The key data generated by this topic is in binary format and is not encapsulated in any envelope, so it can be transferred to the receiver as it is.

/pp/ubx/0236/ip (Topic for IP dynamic keys in UBX format)
/pp/ubx/0236/Lb (Topic for L-band + IP dynamic keys in UBX format)

F9 Modules

The F9P, F9R, and F9H modules store the keys in RAM(short-term memory) so they will be lost upon power off, this is intentional for security reasons. When the F9P powers on it will need to receive the keys from the MQTT Client or Local storage.

u-center

If you need on-demand keys, u-center's built-in MQTT client can work. However, it cannot pass keys to local storage. In this case, you should use an external MQTT client, such as our Python sample script PointPerfect MQTT Client or any other of your choosing.

Storing Keys Locally

Storing sensitive information (such as encryption keys) in plain text within local storage for future use is typically not recommended. Ensuring the security of stored data is a vital aspect of real-world safety. Depending on our client's risk tolerance level, we can suggest different options to meet their needs. It's important to remember that security solutions are not one-size-fits-all and require careful consideration.

Keys are stored in UBX-RXM-SPARTNKEY format. We prioritize the security of device ports and connectivity interfaces to prevent any vulnerabilities. Ultimately, it's up to each customer to decide whether to store the key as UBX or in an SQLite file. Be aware of the associated risks.
In our R5 modules, we provide data protection services using HSM (hardware security module) encryption. While there are software encryption options available, they are not as stable as HSMs.
After obtaining keys from the MQTT broker, you can store them in NVM (non-volatile memory) that is encrypted. In general, it is not advisable to store keys locally due to security risks unless needed. It's best to obtain fresh keys on demand from the MQTT broker if an Internet connection is available.

Key Cycles

The UBX file contains keys for "Current" and "Next" to enable simultaneous key provisioning. These encryption keys are designed to last for a period of four to five weeks each, allowing for a total time frame of 28-63 days before a fresh set of keys is required.

"Next" Key Logic

When deciding to use the "next" key, have your application verify the "valid from/start date" fields and only proceed if the start date of the second key matches or exceeds today's date. This will prevent a key mismatch and allow you to focus solely on the start dates, instead of relying on the duration.

Known Issue

It has been discovered that the F9P firmware experiences a bug when transitioning from the current key 1 to the next key 2. Once the current key expires, which typically occurs after 4-5 weeks, the F9P will begin to use the "Next" key three hours before it is supposed to. This causes the F9P to stop receiving corrections due to a key mismatch. As a temporary solution, we suggest that the host CPU only sends the current key 1 to the receiver and disregards the "next" key 2. We apologize for any inconvenience and assure you that we will resolve this issue in a future firmware update.