He located a private internet of IP addresses (likely other similar devices) that updated regularly (likely moving cars). He then connected the M2M module to his PC, and spoofed the control surface to gain entrance into the vendor network, which had no rogue device identification parameter. Once “inside,” he could have launched a passive attack to map out the network protocols, or an active attack to disrupt services provided by the M2M network.
Since physical attacks on M2M devices must be expected, the need for better device-side protocols is paramount. These include:
- Disabling debugging functions in M2M devices themselves.
- Encrypting the internal memory of microcontroller in the device.
- Eliminating signal pathways that send unencrypted data over external buses (USB, etc.)
- Building in circuitry that detects tampering or intrusion.
Physical security protocols are important whether a device is on a GSM network or a CDMA network, so carriers and M2M service providers should make every effort to ensure “secret” data is encrypted and properly handled through all touch points in the M2M communications chain.
Better Gateways and Encryption
Beyond physical device attacks, communications service providers who offer M2M solutions must also prepare for network-side attacks. As security expert Hunz wrote, “never trust the communications channel; always use extra sound encryption and authentication.” For one, this means stronger gateways.
“CSPs should provide a gateway between M2M endpoints and M2M management platforms and any external interface,” said Scott Swartz. “Consider the recent cell phone hacking scandals. Was the device hacked or the connection hacked? The industry must take into account what confidential information the endpoints contain and how to protect it.”
In other words, even if a device is hacked, the gateway to the network must have robust authentication that prevents and detects unauthorized use and entry attempts, as well as logging and reporting mechanisms. Proper detection, logging, and reporting can contain an attack as a passive intrusion, before hackers are able to launch an active, damaging assault.
Additionally, communications channels used by M2M applications aren’t usually encrypted by M2M service providers. As Denny Nunez at Sprint explained, “a concern is that many M2M applications also open up and utilize both the SMS and Voice channels. SMS and Voice are rarely ever encrypted by third-party M2M solutions and THAT is where a big security hole exists.”
A Standard for Safety
While M2M solutions reside within a latticework of overlapping standards that address various points along the machine-to-machine technological continuum, “There is no ISO standard for M2M security,” says Denny Nunez. There are M2M working groups that are certainly dedicating considerable time to creating security standards, but as of today, a M2M device doesn’t come with a sticker that verifies its compliance with, say, standards for encrypted security key handling in on-board memory. While security standards for M2M communications will certainly be developed, until they do, it is critical that CSPs who offer M2M diligently investigate the security protocols of devices, their third-party partners, and the level of encryption and authentication in their gateways and SMS/voice channels.
The Future is for the Machines
As I pointed out elsewhere in this issue the future of connected devices belongs to machines. Standing at the first stop on the road to the internet of things, we see M2M primarily being used for metering, asset tracking, and dynamic advertising. Although improving security of both the M2M devices and communications networks for these applications is crucial, the importance of M2M security will only increase as M2M applications evolves into active infrastructure management.
Scott Swartz summed up the challenges facing M2M service providers as applications move from simple monitoring and tracking to control: “The scary question is, “What M2M applications control things that are potentially dangerous vs. applications that are primarily benign?” I allow my home automation system to activate my alarm, but do I trust it to deactivate it? Not yet. Let’s hope that critical infrastructure providers use the same common sense until the security issues are sorted out.”
