Blockchain Validation for OTA Configuration Security
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Mobile devices are vulnerable to unauthorized and malicious over-the-air (OTA) configuration commands, which can alter settings such as MMS messaging servers, proxy servers, browser configurations, and mail servers, without proper validation.
Innovation Solution
Implementing a blockchain ledger to store and validate permissibility information for OTA configuration commands, ensuring that only authorized settings are applied by verifying the integrity and updating the blockchain regularly to disregard any unauthorized commands.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If OTA configuration commands are accepted without validation, then device configuration can be updated easily and quickly, but the device becomes vulnerable to unauthorized and malicious configuration changes
Solution Approach 1:
The patent applies preliminary action by pre-provisioning the mobile device with a public key and certificate authority information during device provisioning, before any OTA configuration commands are received. This allows the device to independently validate incoming configuration commands against a trusted blockchain ledger without requiring complex real-time validation infrastructure.
Solution Approach 2:
The patent introduces a blockchain ledger as an intermediary between the configuration command source and the mobile device. The blockchain serves as a trusted mediator that stores and validates configuration permissions, allowing the device to verify commands without directly trusting the command source. This intermediary layer adds security while keeping the device validation logic relatively simple.
2Reliability
If a validation mechanism is implemented for OTA commands, then security against malicious commands is improved, but the complexity of the device configuration system increases
Solution Approach 1:
The validation infrastructure is prepared in advance by provisioning the device with cryptographic credentials and blockchain access information during initial device setup. This preliminary configuration enables the device to perform self-validation of OTA commands without requiring complex runtime validation infrastructure or continuous external verification.
Solution Approach 2:
The patent uses cryptographic copying and verification mechanisms where the device holds a copy of its own public key and validates configuration commands by verifying digital signatures against this copied credential. The blockchain serves as a distributed copy of the truth that multiple devices can independently verify without central coordination complexity.
3Reliability
If blockchain validation is performed for each OTA command, then unauthorized commands are blocked, but the time required to process configuration updates increases
Solution Approach 1:
Cryptographic validation credentials are pre-loaded into the device during provisioning, enabling immediate validation of OTA commands without requiring time-consuming real-time certificate verification or blockchain synchronization. The device can independently verify command authenticity using pre-configured public keys and stored blockchain data.
Solution Approach 2:
The device performs validation checks selectively based on the configuration command type and criticality. Not all configuration parameters require full blockchain validation - less critical settings can use simplified verification, while only critical configuration changes require complete cryptographic validation against the blockchain, reducing overall validation time while maintaining security for essential settings.
Data Source
AI summary
In a wireless communication network such as a cellular network, cellular devices may receive over-the-air (OTA) configuration commands that specify requested device configuration settings. For example, an OTA configuration command may be a binary short message service (SMS) message specifying a configuration parameter and a requested value of the configuration parameter. Upon receiving an OTA configuration command, the cellular device refers to a blockchain that specifies permissible values for various configuration parameters. If a requested configuration parameter value is not indicated by the blockchain to be permissible, the cellular device disregards the OTA configuration command and refuses to implement the requested setting. The cellular device may periodically retrieve updates to the blockchain and may attempt to validate any updated blocks, based on previously validated blocks. If the updates cannot be validated, the cellular device may decline to implement any requested configuration settings.