Closeup of a Volkswagen symbol on a cars front grille

IoT Security and 100 Million Volkswagens

Researchers just published a startling discovery we’d never want to read about. It turns out that 100 Million Volkswagen vehicles sold since 1995 can be relatively easily hacked to open doors wirelessly without having the key.

It turns out 100 million vehicles used only a handful of private shared keys. Once a single private key is breached, millions of vehicles are compromised. The way cryptography based on Pre-Shared Key (PSK) works is that two devices (a vehicle and a key fob, in this case) share a secure private key that was programmed at a factory or at a dealership. This private cryptographic key, along with a rolling code are used for encrypted wireless transmission of authenticated commands to open/close doors.

With enough compute power, pretty much any secure communication can be cracked with brute force attack. But, in many cases, this may not be practical. The older VW Remote Keyless Entry (RKE) systems were trivial to crack, but the latest schemes ones are more robust. However, another, easier attack, is to snoop the memories of vehicle’s electronics for the private keys. This is what happened here. The secret keys were not so securely stored, and they were read out from the vehicle microcontrollers by people skilled at this. Normally, only one vehicle would be compromised (and only after hackers broke into the vehicle’s interior, in the first place). But, whether by ignorance, laziness, or mindless “cost-cutting”, 100 millions of vehicles and their key fobs were programmed with just a few common secret keys used worldwide over decades. So, once one vehicle got hacked, millions of others were compromised. Oops, another of Volkswagen’s expensive screwups. (To be fair, VW is not the only large corporation to suffer from such a security breach, but this one has been the most spectacular so far.)

IoT Security

So, how does this relate to security of IoT connected devices and sensors? Think of Volkswagens as IoT devices. Similar cryptography schemes are used to secure the communications between sensors and cloud services. While older obsolete cryptographic algorithms offer little protection to eavesdropping or spoofing, more advanced algorithms, such as AES-CCM are considered state-of-art for resource-constrained devices.

They use secret Pre-Shared Key along with another piece of information, called Initialization Vector (IV) are used for authentication and encryption of the information being transmitted. The IV is additionally incremented with a monotonic counter, so that the transmissions with the same payload data, always generate different encrypted messages. If there is enough secret key and IV bit length and randomness, this scheme can be very effective in resisting brute force hacking and spoofing attacks, especially for low-cost IoT devices that use low-power, long-range wireless communication.

But, these state-of-art cryptographic algorithms are only as good as the secrecy of the private keys, the design of the security system, and deployment methodologies being followed. Just like your credit cards are secure as long as you are careful whom you hand them to and how well you protect your wallet.

IoT security is a rightfully serious vulnerability today because, many times, it is designed and deployed by people who don’t understand the interplay of the technology nuances and the application’s  business risks. When cost pressures inevitably show up (these are supposed to be low cost devices, after all), wrong compromises are made. While there were many security breaches similar to the Volkswagen’s, and a few were as well publicized, my feeling is that the majority received little press and many more are the “ticking time-bombs” still waiting to happen.

Zenseio’s IoT device platform offers strong built-in security features. The private keys are uniquely and randomly generated for each device and stored in secure hardware crypto vault. After being written once, private keys can never be read back. Our devices will also prevent revealing of internal secrets through physical hacking or reverse-engineering, such as probing for voltage, temperature, frequency, light, or electromagnetic field signatures. Even if one of the devices is cracked with brute force cryptanalysis, others are unaffected. Additionally, as each device uses unique internal secrets for authentication of messages, spoofing attacks are also prevented.

Not every IoT application needs this high level of security. In fact, most applications are better served by less stringent key management schemes, but still using the state-of-art cryptography algorithms (which we support out-of-box) as they are easier to use and maintain. However, if your application needs ironclad security, we have built-in hardware features to deliver a hacker-resistant solution.

Sources:

https://www.wired.com/2016/08/oh-good-new-hack-can-unlock-100-million-volkswagens
https://www.documentcloud.org/documents/3010178-Volkswagen-amp-HiTag2-Keyless-Entry-System.html#document/p1
Numerous clocks representing the passage and monitoring of time

IoT Epoch Time Disaster? Only Time Will Tell

Ever heard of the “epoch time”? I’m not talking here about  history periods or geology. Epoch time is simply a standardized time and date reference used in UNIX and many other computers. It defines time, measured in seconds, starting from January 1, 1970 epoch. This is based on an arbitrary, somewhat historical epoch, but, what matters is that it is a commonly followed standard.

Why is this important and what does it have to do with IoT? Many IoT sensor devices have to keep track of time, so when they collectdata readings from sensors, they time-stamp them. IoT devices may collect sensor data for hours, days or weeks before sending them to the Cloud for Big Data analytics. Time-stamping helps to precisely know when the data was measured, not when it was received by a Cloud server. This is very important if the data analytics is to be correct and accurate.

Many IoT devices use what is called Real Time Clock (RTC, for short) to keep track of time. It’s a very low power electronic circuit that counts pulses from an internal clock generator. These pulse counts are converted to seconds and, then, the seconds are counted. What is the count referenced to? A convenient epoch (and, sometimes, the only one possible) is the time of the device power up. But then, the time reference would vary greatly from one device to another. If one device was powered up a month ago and another one yesterday, they  would be both showing different timestamps for the data measured at the same time, say an hour ago. Exacerbating the problem, this time-stamp reference could never be relied upon in absolute terms since the devices could be powered up at arbitrary time. It’s only good for relative time-stamps.

So, this is where the epoch time can be helpful. It’s the standard that all Cloud servers already use. There are standard software libraries written to convert human readable time to epoch time. These libraries have been ported even to IoT devices and utilized to support the epoch time reference (provided they have a communication downlink to synchronize the time reference from the Cloud server, in the first place).

Looks peachy – so, what’s the problem? Well, the IoT devices are very resource constrained because of their low power and low cost requirements. They typically use 32-bit counters for keeping the epoch time. A 32-bit signed counter can hold up to 2^32 values. That is 2,147,483,647 seconds. A quick calculation shows that this seconds counter will overflow sometime on 19 January 2038 – about 21 years from now. For industrial IoT devices this is definitely within their active deployment lifespan. But until the time rolls around, few will worry about these device limitations.

What will happen is that the sensor data time-stamps suddenly wrap around to start from January 1, 1970. Remember “Y2K bug” deja-vu, anyone? Perhaps the Big Data analytics AI algorithms may get very confused about this and draw wrong decisions and cause massive damage. Or perhaps, the AI may be smart enough to figure out what’s wrong and readjust the timestamps without a hiccup. Only time will tell.

But, why risk it? There are solutions that can be used today, that make this epoch time overflow a non-issue.

At Zenseio, we specialize in robust, industrial IoT sensor devices. In our hardware platform, we pay attention to details big and small, so our customers don’t have to worry about them. We are quality freaks.

Closeup of a pile of lego bricks in a wide range of colors

Key considerations for IoT sensor devices: 1-Versatility

With my two decades of experience designing complex electronic systems as well as recent two years focused on building IoT systems and solving System Integrators’ pain points, several key characteristics became evident to me that define the best-in-class industrial IoT sensor devices:

  1. Versatility
  2. Power consumption efficiency
  3. Ease of use
  4. Security
  5. Industrial deployment readiness
  6. Cost effectiveness

Now, I will cover each consideration in more detail.

1. Versatility

Executive Summary:

  • Most IoT applications undiscovered and undeveloped
  • IoT applications as diverse as business needs are
  • Most deployments will be small to medium size
  • Versatility and adaptability is key

Details:

While IoT is not a new concept, collectively, we’ve just scratched the surface of its real-life benefits and utilization. Although there are some good, well publicized examples of businesses benefitting from this technology on a large scale, most of the IoT applications are still to be discovered and implemented. Widespread technology adoption and its business benefits always significantly lag the technological development curve. Risk mitigation, forces even large companies to start small and to expand from there once the benefits are proven in practice. Needless to say, majority of businesses will benefit from IoT sensor deployments that are on a small to medium scale (10 to 50,000 devices). Much fewer IoT applications will be ready for deployments of identical IoT sensors on very large scale in the foreseeable future, if ever.

The reason is that there are nearly as many specific IoT application requirements, such as different types of sensors or data communication methods used, as there are industries and business processes. With so many combinations of specific sensor device configurations and low volume installations, single-purpose-built sensor devices fall short of practical business realities in terms of the total development cost, deployment time-to-market, and adaptability to constantly evolving application requirements. Furthermore, System Integrators – people or companies that put together these complex IoT systems – work with varieties of system solutions from project to project. So, they can be a lot more efficient if they use a flexible and adaptable hardware platform they learn once instead of starting from scratch with a new embedded programming environment each time they start a new project. They need a versatile toolbox to create what they need for a given project.

While it is impossible that single, fixed solution fits all IoT applications, it is possible to create a versatile platform that adapts to many (but definitely not all) industrial applications.