Securing the Internet of Things with OTrP

Software security and technology in automobiles

Software security and technology in automobiles

Security is vital to the devices on the IoT, and too often it's not strong enough. Botnets grab up connected devices that aren't properly secured. In an industry that plays a critical safety role, the stakes are even higher. A compromised device regulating a machine could make it catch fire. A dangerous condition could go unreported, or false alarms could draw attention and resources away from real problems. These devices need to aim for six sigma security — 99.999996% defect-free operation. Meeting this need will require a radically new approach to their software, software written by those in coding classes today.

The Open Trust Protocol, abbreviated OTrP, aims at creating those standards. ARM, Solacia, Intercede, and Symantec joined their efforts and announced the protocol in June of 2016. It's currently available as a draft from the IETF. The current draft expired in January, but expirations are fairly common among IETF drafts and don't mean the work has been abandoned. The terminology is loose in places, with more than one name being used for exactly the same concept. Hopefully the next draft will fix this.

Its central concept is the Trust Execution Environment. The idea of a TEE is to isolate security services, so that a general-purpose “Rich Execution Environment” can access them only indirectly. This scheme limits the amount of damage that security weaknesses in the REE can do. A Trust Service Manager provides the mediation.

The TEE and TSM need to make sure they trust each other. Certificates from a trusted CA provide the mechanism for doing this. The process starts with a Secure Boot Module (SBM), which checks the TEEs as it starts them up. The TEE in turn can check if the SBM's firmware is valid. Thus, no single compromised component can go undetected.

OTrP in automobiles

Current automotive data technology uses the CAN bus, which wasn't designed for security. It was devised before there was any notion that devices in a car could connect to an outside network. Some highly-publicized tests have spectacularly shown the danger of that approach in a connected car.

A car with electronics built around OTrP would be far safer against external attacks. A recent article on the Embedded Systems Engineering website goes into detail about how it would work.

Applications in a car can come from different sources, and they're installed and upgraded separately. No one can assume that code from outside is trustworthy. Hostile software in a relatively harmless component, such as the stereo system, might try to subvert more critical components, such as steering control.

At the same time, these components need to communicate with one another. A collision-avoidance needs to get input from external sensors and control the speed, steering, and braking units. The stereo shouldn't be able to do those things. First, it has no need to, and second, it's typically connected to the Internet, which makes it less trustworthy.

The TSM will make sure that components do only what they're supposed to do. It will verify all software upgrades for authenticity, so that malware can't be installed. There can be multiple TSMs for different parts of the car's functionality; this allows subsystems to control their own components without adding any risk to the manufacturer's systems. The TSMs can operate on different business models; add-on systems might operate on a third-party payment or subscription model. If the add-ons have to shut down because of a breach, the car keeps running.

An opportunity for developers

Devices in industrial environments need to be safe against outside tampering, to keep both property and lives safe. A compromised temperature regulator could start a fire. Misbehaving switches on a power grid could cause a large-scale outage; malware doing just that may have been behind the December 2015 Ukraine power outage. The suspected attack came by way of phishing email. A system based on OTrP would isolate critical systems from desktop systems.

Software developers who have learned to develop failsafes in programming school and can understand and can implement OTrP will be highly in demand. Device makers are under increasing pressure to deliver reliable, secure products, and they'll need to rethink their coding approach if they're going to do it. With the training we offer in our coding bootcamps, you'll be in a position to meet their needs. Contact us to get more information about the coding classes we offer today!. 

Jan Wagner

Powered by Top Rated Local® --------------------------------------------------->