by Richard Fetik
LTE (Long Term Evolution) is emerging as a viable and valuable alternative to other RF (Wi-Fi, etc.) connection technologies for some classes of IoT devices. This article analyzes LTE IoT design considerations and security requirements as a result of differences in the attack surface and connection feature set. The requirements for LTE connected IoT designs differ somewhat from other RF connected IoT designs. The security objectives are the same (for the device to reliably provide the intended services), but LTE poses some different challenges. LTE is valuable for certain classes of applications (devices) such as automobiles (and other transportation mechanisms), and mobile (including communication, computing devices, video capture, UAVs/drones, smart clothing).
LTE is the dominant fourth-generation (4G) cellular technology, partly because of higher throughput in mobile communication in bands below 6 GHz, partly because it has some technical advantages over earlier cellular technologies including that LTE is more secure (affords more privacy, etc.) But LTE still has security vulnerabilities: these include that it is possible to completely take down the LTE network, as well as to partially block communication, intentionally with the help of jamming signals, or unintentionally through various forms of interference.
An example of unintentional interference issues includes the coexistence issues with Air Traffic Control (ATC) S-band radar and Digital TV bands. Device multi-standard transceivers also present coexistence issues. From the perspective of designing a reliable device that can protect its operation and data, there are several larger problems. It is possible to spoof phone numbers and messages, to eavesdrop on calls and texts, and to spread malware through exploiting LTE vulnerabilities. These vulnerabilities affect potentially every Android device. More information on this and related issues can be found in advisory http://www.kb.cert.org/vuls/id/943167, posted by Carnegie Mellon University’s public vulnerability database (CERT). As late as October 2015, Android devices on LTE networks were found to be at risk because, to quote the advisory: “The Android operating system does not have appropriate permissions model for current LTE networks”.
Compared to Wi-Fi, the LTE IoT device design would seem to have some inherent security advantages such as a unique device identity provided by the LTE / system, but cell phones can be cloned, such as by cloning the SIM card, so these are illusory advantages. The strongest device identity and PKI seems to be that based on the device itself generating a unique private/public key pair, employing something like the PUF (physically unclonable function), but the LTE / GSM cell network employed IMEI (International Mobile Equipment Identity) number is useful as a network identifier.
The reason I mention this is to counter the idea that LTE and/or Android provide a magically secure environment and platform for your device development; there is no out-of-the-box security you can leverage, you will have to design security into your device from the hardware up. This means I am writing that the recommended approach to ameliorate and remediate the vulnerabilities in LTE and Android is the same advice I would provide for non-LTE and non-Android environments. This is to build layers of security, into both the endpoint devices and the network equipment resources.
Ideally, these layers should include:
- virtualization support in the processor,
- a secure virtualization-enabled kernel,
- a device identity mechanism that ties into a strong PKI (Public Key Infrastructure) solution – (I currently recommend the use of PUFs, Physically Unclonable Functions, as the foundation of the device identity),
- additional layers of communication encryption – including an end-to-end, application layer, encrypted datapath,
- a storage firewall that provides access control to the internal storage resource, preventing unauthorized writes and reads,
- and a network firewall that leverages the device identity and PKI, and communication encryption,
- to protect access to the device through an authorization and access control scheme,
- and to protect communications by maintaining a secure tunnel to the server through intervening network routes (hops).
This secure design approach is built upon principles and mechanisms such as “separation” (virtualization and firewalls), authentication, verification, authorization, access control, layers of encryption, and key management. But even with all of this, there may still be penetrations leading to unauthorized configuration and software changes. To detect anomalies and then to remediate discovered problems there needs to be a monitoring and management system. The most useful approach is to capture the correct configuration of this and every other managed device in a database, then to securely monitor and scan each device to find differences in the actual device configuration from the stored configuration. If a difference is discovered, then the stored configuration should be reset into the device.
An LTE connected security camera can be used to demonstrate this security design approach. There are Hollywood movies with the plot device of replacing live security camera signals to mask the unauthorized activities. Obviously, it is important that the transmission mechanisms (protocols, etc.) detect tampering with the video signal, prevent man-in-the-middle attacks, etc. And, the security design must prevent successful tampering with the configuration of the device.
An application (use case) of this camera could be to keep an eye on agricultural equipment stored on farms’ fields such as heavy equipment such as tractors, irrigation pumps and pipes, diesel fuel tanks, etc. The objective of this physical security application is to obtain images of thieves as they steal; real-time transmission of the evidence may enable their capture. Conceptually, the camera would be one or more CCDs (charge coupled devices, the actual semiconductor that provides the video signals), a processor, some software processing RAM and storage, video memory cache (as a video buffer), a power supply and battery, and an LTE transceiver (such as the Digi XBee Cellular LTE Cat 1 embedded modem). Power may be provided by the grid, or by a solar panel.
Attempts to electronically attack this device will generally be defeated by the network firewall access control, and secure communications enabled by device-generated (unspoofable) identities and end-to-end encryption, all of which are supported by the underlying foundational technologies such as virtualization and the storage firewall. But don’t forget the management and monitoring solution.
Author Bio: Richard, CISSP, a recognized security expert, is CEO/CTO of Data Confidential, a consulting, services, and technology licensing firm for the embedded, IoT, and cloud spaces. Richard is the inventor of Data Confidential’ s innovative technologies such as the Storage Firewall, secure container objects for cloud computing and secure IoT-to-cloud interactions, and a customizable storage controller architecture, built on a security framework, that accelerates application performance 100x to 1000x.