Security in Short-Range Wireless Solutions and Mesh Networks
April 20, 2021
While wireless connectivity brings many advantages, security is where it adds weaknesses. A wired connection can be probed or diverted, but it requires physical access and quite visible interference. Wireless connectivity, by contrast, makes it possible to spy on data transfer or inject malicious content remotely and unseen. This article discusses how security in short range wireless is evolving as solutions – and threats – become increasingly sophisticated.
There has been an explosion in the use of short-range wireless solutions in recent years, driven principally by the arrival of the Bluetooth Low Energy (BLE) standard. While plenty of short-range wireless solutions existed previously, their uptake was limited. This was either because they focused on niches – such as Zigbee or ANT – or were ill-suited to battery-powered or intermittent use cases – like Bluetooth “classic”. BLE fulfilled the general “cable replacement” objectives of the original Bluetooth standard, and with BLE quickly becoming natively available on phones, laptops, and tablets, there was a ready-made market of devices to connect to.
Most early BLE solutions were quite simple point-to-point (P2P) connections between one device and another. A BLE connection has two main levels of security: a “pairing process” whereby a secure link is established between two devices and then data encryption for actual data transmission.
Pairing is in many ways the weak point of P2P connection security and can be open to “man in the middle” attacks, whereby a third-party device connects to the two legitimate devices and places itself between them, allowing it to spy on or manipulate data traffic. This risk can be reduced via an “out-of-band” exchange of data for pairing, which involves either manually entering a passcode or exchanging keys via a different channel such as NFC. The downside is increased complexity for the user and cost of devices.
This highlights a key issue when considering security – there is rarely a “right” answer. The challenge is to find the right trade-off between security, usability, and cost.
Data Encryption & Beyond
Once a connection is established, data is encrypted via AES-CCM 128-bit symmetric key cryptography which is generally considered secure. However, this is only true provided the key remains secret. One issue with many simple BLE devices is that their integrated microprocessors are limited with no secure memory storage. Therefore, it is possible for an attacker to temporarily gain access to a device and steal the key for future spying purposes.
Even if we assume that the link is secure, this only establishes a secure P2P connection. Newer applications are increasingly more widely connected, and data is ultimately transferred far beyond a simple P2P link – perhaps from a device to a cell phone then up to the cloud, and then on to a further proprietary system. This introduces a vastly enlarged “attack surface” for those with malicious intent.
In such an environment, link-level security may no longer be enough and an end-to-end security layer could be required to ensure safe operation. If one considers the example of a medical wearable, erroneous data could, in extremis, be life threatening.
End-to-End Security Considerations
For an end-to-end secure system, there are two major considerations. Encryption is one – that data can pass from one end to the other, but not be readable by anyone even if they had full control of an intermediate relay point. The second is authentication – that data apparently coming from an end device really is indeed coming from that device, and not being injected by a malicious actor, or the reverse.
Encryption is often seen as the principal issue in security, but authentication is often the most crucial step. To illustrate, you might not want people spying on your financial transactions when you use a credit/bank card, but you would probably be far more concerned if someone could easily pretend to be you and access your bank account.
Public/private key encryption methods provide the means to both authenticate and secure a transaction. Encryption with the public key of the receiver means only they can decode it. Encryption with the private key of the sender means anyone can validate the sender’s identity.
Unfortunately, in the security realm, solving one problem often leads to simply creating another. In this case, the immediate issue that arises is how you exchange and store keys securely. Mesh networks, for example, provide additional challenges for security architecture because, by design, their aim is to make it easy to add devices to networks like smart home networks. The risk is that a malicious hacker could find a way to join a device to the network, then cause damage, gain entry, or adopt devices for a denial-of-service attack.
Mesh networks can be particularly vulnerable because they can have universal network keys. So if this key is obtained, free access to the entire network is available. In such a system, key storage becomes critical because even if an intruder has temporary access to a device, the keys remain hidden.
The ultimate solution for key storage is to use a hardware “secure element” that is programmed in a secure factory by a trusted partner (Figure 1). This approach has been applied successfully in smart cards to protect bank cards and in SIM cards to limit access to the cellular networks.
(Figure 1. This diagram shows how a secure processor restricts access to data and resources in the trusted zone.)
However, this solution is only applicable directly to systems that are produced in extremely large quantities by a small number of multi-national digital security companies. Clearly, transposing this to the world of short-range communication poses several issues related to market fragmentation, with many products and industry players.
While the older generation of wireless devices were typically entirely open, newer generations of products integrate additional security features into the system. Amongst other things, ARM’s “TrustZone” includes a secure key unit. Here, a key storage unit and cryptographic services are held in a secure part of the processor (Figure 2). In practice, this means keys can be put in, but once inside cannot be read out, and cryptographic operations are carried out inside the secure part.
(Figure 2. This diagram shows a BLE module with an integrated secure element, which can only be interfaced with via predefined functions/operations.)
The “trust zone” can be considered the first step in improving security from zero towards the ultimate “smart card” level. Nevertheless, it suffers from being implemented in standard silicon without specific hardware protection against key reading through side channels, such as power fluctuations. It is also arguably too flexible, meaning inexperienced designers may leave security flaws through mistakes.
Security Next Steps
The next step towards security is to add a hardware secure element that would act much in the same way as the secure element in a smart card. Here, the issue is to manage the provisioning of keys in such a way as to be relatively secure without the high overhead of the secure “Fort Knox” trusted factory.
Future chipsets and modules will certainly have a higher level of security than is currently the norm. Key storage solutions will be included that are based on embedded zones in the communication SoC or on a companion hardware secure element. Provisioning of keys will also evolve to satisfy the needs of different levels of security while avoiding the cost and complexity of the approach used in the smart card industry.
Over-the-air updates are a common feature of the latest generation of wireless devices, offering another line of attack for hackers. This is protected by a secure boot process that, on startup, verifies that the code to be loaded has not been changed since the last boot, and also that any update package contains the correct digital signature to authenticate the origin of the code.
Many newer generation devices also integrate a secure boot processes into the secure hardware element.
Integrating Security into Wireless Devices
Ultimately, security is always a trade-off. Adding security features will variously add cost, design complexity, and degrade performance characteristics including throughput, power consumption, and usability. This is especially significant for small wireless devices, which often aim to be low cost and use simple, limited interfaces.
Nevertheless, as the sophistication and connectivity of wireless devices grow, so does the interest of malicious hackers. It is an ongoing challenge waiting for wireless designers to respond.