In recent years, Android has proved to be one of the driving forces behind the success of the Internet of Things (IoT). The combination of a stable kernel, availability of open source libraries and the absence of license fees has made Android a popular IoT-embedded-as-a-Platform solution.
Concept Reply has gained extensive expertise in developing Android-based IoT embedded systems by creating custom versions of the Android operating system to meet customers' increasingly differentiated demand for connectivity. For these requirements, the competence of the Concept Reply IoT experts ranges from kernel customization to application level development.
In a recent project, Concept Reply provided two controllers of its IoT embedded platform, housed in two separate Electronic Control Units, with a Bluetooth Personal Area Network (BT-PAN) for a major automotive manufacturer. Thanks to BT-PAN, one of the controllers can act as an internet gateway for the other and ensure communication with the backend.
Setting the preconditions for the local Bluetooth adapter (radio turned on, enabled, remote address set, etc.)
Triggering the traditional pairing process
Activating the local PAN service, set the correct role (e.g. PANU or NAP) and connect to the PAN service of the remote device
In Android, the functionality for performing these three steps is available and well documented. While this traditional approach has the advantage of delivering results quickly, there are other options that have proven to be more appropriate for ensuring the highest level of security. The reason for this lies in its core - the pairing process, which is illustrated in the diagram:
Parts Authentication: Local and remote devices generate their keys and exchange them among themselves relying on an asymmetric encryption mechanism (in this case the Elliptic Curve Diffie-Hellman (ECDH) protocol).
Channel encryption: Once both parts have completed the authentication phase, they have everything they need to generate a session/link key with which to encrypt data passing through the Bluetooth channel from that moment on. This is carried out by using a symmetric encryption algorithm that is traditionally faster than asymmetric ones.
The authentication part requires device discovery, which in turn demands that the device in question is detectable, meaning that it advertises itself. And this is where the security problem lies: by keeping Bluetooth devices detectable, they provide a point of attack for hackers who want to harm the system.
To address this security vulnerability at the design level, Concept Reply follows its own approach:
Implementing the authentication part indirectly, by using another controller, already in the targeted system, as a third-party taking care of:
Generating the session/link key
Sharing the generated session/link key to the Android controller and the new controller.
Both parties, for example the Android controller and the new controller, perform Encryption Key Injection on their respective stacks. This means that the key received at the application level by the third-party controller propagates it to the lower layers and stores it in its Bluetooth adapter, which is the component ultimately responsible at the physical layer.
The injected key is used to encrypt the communication channel with a symmetric encryption algorithm, as is the case with the traditional approach.
The alternative approach requires careful analysis and rework of the existing stack.
In Android this can be illustrated as follows:
The careful revision of such a large stack (performed in C, C++ and Java) can be summarised as follows:
In the Application Framework a Java service in charge of receiving and validating the link key from the third-party controller in charge of the orchestration has been added.
If a received link key is valid, it gets propagated to the Bluetooth Process layer, though an AIDL-based remote procedure call defined specifically for this purpose.
In the Bluetooth Process layer, in turn, the roles of the controller (i.e. which one shall act as an internet gateway and which one shall act as the client) and the C++ API in the Hardware Abstraction Layer (HAL) has been defined to forward the link key to the Bluetooth Stack (bluedroid).
Inside the Bluetooth Stack, the proper functions in C language to create an XML profile of the remote device/link key pair have been built, cache it in the controller memory and inject it to the Bluetooth adapter memory.
As described above, this approach to establishing a Bluetooth PAN connection required massive refactoring across the entire stack.
Nevertheless, together with Concept Reply as an experienced partner, the design and implementation challenges were mastered in order to provide the customer with a stable and effective solution on time.
Concept Reply is an IoT software developer specializing in the research, development and validation of innovative solutions and supports its customers in the automotive, manufacturing, smart infrastructure and other industries in all matters relating to the Internet of Things (IoT) and cloud computing. The goal is to offer end-to-end solutions along the entire value chain: from the definition of an IoT strategy, through testing and quality assurance, to the implementation of a concrete solution.