Securing Invisible Things … or “Why Denial Works!”

The opening keynote of the Embedded World conference in Germany left me with chills. No, it was not a grand theatrical performance letting me crave for more. It simply scared the bejevies out of me with respect to the safety and security of embedded devices, some of which I use each day. Luckily -- as in so many other areas of life -- the cure simply lies in proper prevention before bad things happen. And guess what, tools like our System Development Suite may be central to the answer!

Stuart McClure, CEO and President of Cylance and former CTO of McAfee, opened his keynote with commentary that the safety and security industry may actually be worried about the wrong things. The way the security industry thinks about attacks is in several levels from 0-days (public and vendor don't know), 1/4 days (vendor knows, public doesn't, there is no fix), 1/2 days (vendor and public know but there is no fix) to 3/4 days (a patch is available but it is not installed yet). The real issue, he continued are infinite-days, i.e. when the vendor has decided that the vulnerability is a feature -- which means the vendor knows about it but has chosen not to fix it! With an estimated $10B connected embedded devices today (see the ARM Blog on Embedded World this week), there is lots of room for vulnerabilities!

I am a big fan of the TV series Homeland. In season 2, episode 10, called "Broken Hearts," vice president Walden dies when his pacemaker is hacked into. Well, that's exactly what McClure's team found to be true with insulin pumps and defibrillators- - they were open to vulnerabilities and could get hacked into. The demo video was quite chilling -- one sees the insulin pump and how it spills more than the maximum healthy dose.

We got to witness McClure hacking RSA keys extracted live from the RTOS of networking boxes; the flush of cash from ATMs, either done by USB stick or remotely; the hack into shared Knox boxes holding keys for buildings; pressure pumps overloading when hacked into and subsequently blowing up bottles; and also hacking into car networks demonstrated by the University of Washington and UC San Diego. He also scanned the rooms for Bluetooth devices with standard authentication to be hacked into before describing some of the root causes of some of the hacking techniques. Often existing legacy techniques -- like the existing infrared for the current Samsung SMART TVs like I have at home -- serve as a way in to hack the system.

It was not pretty.

McClure definitely had the audience smile when he showed a picture of Star Wars' R2D2 hacking into the Death Star to stop the trash compactor in which Han, Leia and Luke are trapped, calling R2D2 a "Ninja Hacker" and noting the lack of checking for human beings as a feature to be explained to the emperor as "Hey, we had the guys we are looking for but some robot hacked the Death Star to save them." He summarized security in Embedded Devices today as shown in the photo I took here. There is some weather proofing and resilience, and our devices need to be highly available and tamper proof. But nothing is really secure and of course "denial works pretty well."  McClure got some laughs from the sufficiently concerned audience by showing a picture of a school house on fire, with the fire brigade all over the place because they are also watching a game of American football.

Was there good news? Yes. McClure pointed to the basic cycles of attack described in his book "Hacking Exposed" and showed how they can be essentially prevented by better planning. The classic loop of "Detect - Respond - Deter" needs to be enhanced with preventative measures, i.e. enhanced with the loop of "Design - Build - Assess." He called for better design leading to safer architectures, followed by better building using secure coding and QA and proper assessments.

What does this have to do with EDA and System Design? A lot!

One of the main objectives of the System Development Suite is to provide representations of the hardware prior to its availability, which allows software to be developed and tested early. Virtual Platforms can be stopped and debugged appropriately, and RTL registers can be evaluated together with the software accessing them in simulation, acceleration, emulation and FPGA based prototyping. What this allows us to do during the development phase is to specifically inject errors using the test benches for the hardware/software systems under development. In contrast to the real hardware, which is hard to bring into a specific desired state, the representations of the hardware software systems in the System Development Suite can be put in a targeted fashion into very specific states and can be stimulated with targeted verification sequences to test specific scenarios.

We are actually showing this at the Embedded Show with an Advanced Driver Assist System (ADAS) running on a virtual platform of the Xilinx Zynq-7000 (see below). We can inject very specific errors and trigger very specific scenarios.

Well, so we actually do help to make the world a safer place! See you at Embedded World or DVCon this week. 

Frank Schirrmeister