Embedded Computing Design September 2016

SEPTEMBER 2016 VOLUME 14 | 6 EMBEDDED-COMPUTING.COM

IOT INSIDER PG 7 What’s new with the mbed OS? EMBEDDED LENS PG 9

The Internet of Wild Things

Development Kit Selector

www.embedded-computing.com/designs/iot_dev_kits

IoT Trust Issues Begins on PG 26

Graph analytics, machine learning continuously monitor open source vulnerabilities PG 22

Securing the edge with ARM TrustZone for v8-M PG 10

RUGGED, RELIABLE, RESILIENT!

PPM-C407 Fanless E3800 PC/104 SBC Computer

SCADA

Single Board Computers COM Express Solutions Power Supplies SCADA SCADA SCADA SCADA

I/O Modules Panel PCs

SBC35-C398DL-2-0 Dual-Core Freescale I.MX 6DL Cortex A9 Industrial ARM®

ENERGY

IOT

TRANSPORTATION

IO60-GNSS with Global GPS Receiver Module with Bus Expanison

AUTOMATION

Across a broad range of industry applications—from energy and IoT, to industrial automation and transportation—WinSystems’ embedded single board computers enable the collection, processing and transmission of real-time data requirements at the heart of your overall system.

Our full line of rugged, reliable and resilient embedded computers, I/O cards, cables and accessories help customers design smarter projects that deliver new efficiencies, TRANSPORTATION TRANSPORTATION TRANSPORTATION TRANSPORTATION IOT IOTIOT IOT AUTOMATION AUTOMATION AUTOMATION AUTOMATION ENERGY ENERGY ENERGY ENERGY greater access to information and improved reliability. Whether it’s one of our standard products or full custom design, WinSystems brand products are delivered with uncompromising engineering, quality and technical support.

When your reputation and customer satisfaction is on the line, look to The Embedded Systems Authority!

715 Stadium Drive I Arlington, Texas 76 011 Call 817-274-7553 or visit www.winsystems.com.

Ask about our product evaluation!

September 2016 | Volume 14 | Number 6

CONTENTS

opsy.st/ECDLinkedIn

FEATURES

@embedded_comp

COVER

10 Securing the edge with ARM TrustZone for v8-M

By Abhijeet Rane, Sequitur Labs Inc. 14

Trust issues are on the rise as embedded devices become connected to the Internet of Things (IoT). The September issue of Embedded Computing Design considers end-to-end system security, beginning with technologies such as ARM TrustZone and extending to machine learning in the cloud.

WEB EXTRAS  The Industrial IoT and the performance-based or outcome economy

By Dan Yarmoluk, ATEK Access Technologies http://bit.ly/IIoT_OutcomeEconomy

 Can an embedded web server solve the IoT?

14 Security for industrial control systems protects the national infrastructure

By Sergey Lyubka, Cesanta http://bit.ly/IoT_WebServer

By Jim McElroy and Jay Thomas, LDRA

18 Security for IIoT embedded devices: A platform-based approach

 Software forensics lay MS-DOS, CP/M controversy to rest

By Carlos Pazos, National Instruments

18

22 Using graph analytics and machine learning to continuously monitor open

source code for critical vulnerabilities

DOWNLOAD THE APP

By Brad Gaynor and Phil Neray, Lexumo

26 31 flavors of trust?

Download the Embedded Computing Design app

By Steve Hanna, Trusted Computing Group (TCG)

28 Issues of trust in silicon

By Dr. Jason Oberg, Tortuga Logic, Inc.

28

COLUMNS 7

IOT INSIDER

What’s new with the mbed OS?

By Brandon Lewis, Technology Editor

8

TRACKING TRENDS Retrofitting Industrie 4.0

By Brandon Lewis, Technology Editor http://bit.ly/DOS_CPM_SWForensics

iTunes: itun.es/iS67MQ Magzter: opsy.st/ecd-magzter

Published by:

9

EMBEDDED LENS The Internet of Wild Things

By Curt Schwaderer, Editorial Director

34 EDITOR’S CHOICE

By Curt Schwaderer, Editorial Director

By Rory Dear, Technical Contributor

2016 OpenSystems Media® © 2016 Embedded Computing DesigAll registered brands and trademarks within Embedded Computing Design magazine are the property of their respective owners. iPad is a trademark of Apple Inc., registered in the U.S. and other countries. App Store is a service mark of Apple Inc. ISSN: Print 1542-6408 Online: 1542-6459 enviroink.indd 1

4

Embedded Computing Design | September 2016

10/1/08 10:44:38 AM

www.embedded-computing.com

Video Surveillance with High Capacity Storage & Max I/O

City Surveillance

Banking and Finance Critical Infrastructure

Hospitals

Retail & Commercial

X10DRX Motherboard 11x PCI-E Slots (10 x8 & 1 x4)

SSG-6048R-E1CR60N 4U 60x3.5”Drive Bays

Transportation

SC846XE2C 4U 24x 3.5”Drive Bays w/BBP

SSG-6038R-E1CR16N 3U 16x3.5”Drive Bays

SYS-6048R-TXR 4U 5x 3.5”Drive Bays

SSG-6028R-E1CR24N 2U 24x3.5”Drive Bays

SYS-6038-TXR 3U 8x 3.5”Drive Bays

SYS-5029S-TN2 Mini Tower 4x3.5”Drive Bays

SYS-2028R-TXR 2U 16x 2.5”Drive Bays

SYS-E200-9B Compact Box System

Low Power Intel® Quark™, Intel® Atom™ Intel®, Core™ processor families, and High Performance Intel® Xeon® processors Performance Data Analytics

Video Surveillance with Max I/O

Media Transcoding Storage Expansion

Intel Inside®.

Powerful Productivity Outside.

Digital Video Solutions Remote Management OOB

Learn more at www.supermicro.com/embedded Intel, the Intel logo, Xeon, and Xeon Inside are trademarks or registered trademarks of Intel Corporation in the U.S. and/or other countries.

Analog Video Solutions 03_Q3_SM_USP_082316_MasterFile

Security Fast Data Encryption

AD LIST PAGE

ADVERTISER

36

Advantech Embedded Group – Design-in embedded solutions

2

EMBEDDED COMPUTING BRAND DIRECTOR Rich Nass rnass@opensystemsmedia.com EMBEDDED COMPUTING EDITORIAL DIRECTOR Curt Schwaderer cschwaderer@opensystemsmedia.com

ARM Ltd – DS-MDKL Development solution for heterogeneous systems

21

COMMELL Systems Corporation – Leading provider of SBCs

1

Digikey – Development Kit Selector

35

Electronica – Embedded solutions of tomorrow. Today.

31

TECHNOLOGY EDITOR Brandon Lewis blewis@opensystemsmedia.com TECHNICAL CONTRIBUTOR Rory Dear rdear@opensystemsmedia.com CONTENT ASSISTANT Jamie Leland jleland@opensystemsmedia.com DIRECTOR OF E-CAST LEAD GENERATION AND AUDIENCE ENGAGEMENT Joy Gilmore jgilmore@opensystemsmedia.com CREATIVE DIRECTOR Steph Sweet ssweet@opensystemsmedia.com SENIOR WEB DEVELOPER Konrad Witte kwitte@opensystemsmedia.com WEB DEVELOPER Paul Nelson pnelson@opensystemsmedia.com

Green Hills Software, Inc. – Green Hills Software helps build an IoT we trust

DIGITAL MEDIA MANAGER Rachel Wallace rwallace@opensystemsmedia.com CONTRIBUTING DESIGNER Joann Toth jtoth@opensystemsmedia.com

20

Green Hills Software, Inc. – Securing the Internet of Things

11

Interface Concept – Rugged HPEC boards for your OpenVPX systems

32

Maxim Integrated – Avoid the crisis: Embedded security integrated from the start

STRATEGIC ACCOUNT MANAGER Rebecca Barker rbarker@opensystemsmedia.com (281) 724-8021

5

Supermicro – Video surveillance with high capacity storage and max I/O

STRATEGIC ACCOUNT MANAGER Bill Barron bbarron@opensystemsmedia.com (516) 376-9838

25

Technologic Systems – Don’t let a natural disaster become a total disaster

STRATEGIC ACCOUNT MANAGER Eric Henry ehenry@opensystemsmedia.com (541) 760-5361

17

Trenton Systems Inc. – Let Trenton expand your embedded computing universe

3

WinSystems, Inc. – Rugged, reliable, resilient!

SOCIAL

SALES SALES MANAGER Tom Varcie tvarcie@opensystemsmedia.com (586) 415-6500

STRATEGIC ACCOUNT MANAGER Kathleen Wackowski kwackowski@opensystemsmedia.com (978) 888-7367 SOUTHERN CALIFORNIA REGIONAL SALES MANAGER Len Pettek lpettek@opensystemsmedia.com (805) 231-9582 SOUTHWEST REGIONAL SALES MANAGER Barbara Quinlan bquinlan@opensystemsmedia.com (480) 236-8818 NORTHERN CALIFORNIA REGIONAL SALES MANAGER Twyla Sulesky tsulesky@opensystemsmedia.com (408) 779-0005 ASIA-PACIFIC SALES ACCOUNT MANAGER Elvi Lee elvi@aceforum.com.tw EUROPE SALES ACCOUNT MANAGER James Rhoades-Brown james.rhoadesbrown@husonmedia.com

Facebook.com/ Embedded.Computing.Design

WWW.OPENSYSTEMSMEDIA.COM PUBLISHER Patrick Hopper phopper@opensystemsmedia.com PRESIDENT Rosemary Kristoff rkristoff@opensystemsmedia.com EXECUTIVE VICE PRESIDENT John McHale jmchale@opensystemsmedia.com

@Embedded_comp

EXECUTIVE VICE PRESIDENT Rich Nass rnass@opensystemsmedia.com CHIEF TECHNICAL OFFICER Wayne Kristoff GROUP EDITORIAL DIRECTOR John McHale jmchale@opensystemsmedia.com VITA EDITORIAL DIRECTOR Jerry Gipper jgipper@opensystemsmedia.com

LinkedIn.com/in/ EmbeddedComputing

PICMG EDITORIAL DIRECTOR Joe Pavlat jpavlat@opensystemsmedia.com MANAGING EDITOR Jennifer Hesse jhesse@opensystemsmedia.com ASSISTANT MANAGING EDITOR Lisa Daigle ldaigle@opensystemsmedia.com SENIOR EDITOR Sally Cole scole@opensystemsmedia.com ASSOCIATE EDITOR Mariana Iriarte miriarte@opensystemsmedia.com

Pinterest.com/Embedded_Design/

CREATIVE PROJECTS Chris Rassiccia crassiccia@opensystemsmedia.com FINANCIAL ASSISTANT Emily Verhoeks everhoeks@opensystemsmedia.com SUBSCRIPTION MANAGER subscriptions@opensystemsmedia.com

Instagram.com/ Embedded_Computing

CORPORATE OFFICE 16626 E. Avenue of the Fountains, Ste. 201 • Fountain Hills, AZ 85268 • Tel: (480) 967-5581 SALES AND MARKETING OFFICE 30233 Jefferson • St. Clair Shores, MI 48082

youtube.com/user/ VideoOpenSystems

6

REPRINTS WRIGHT’S MEDIA REPRINT COORDINATOR Wyndell Hamilton whamilton@wrightsmedia.com (281) 419-5725

Embedded Computing Design | September 2016

www.embedded-computing.com

IOT INSIDER

blewis@opensystemsmedia.com

What’s new with the mbed OS?

By Brandon Lewis, Technology Editor ARM originally launched mbed in 2009 as an online community and integrated development environment (IDE) for engineers working with Cortex-M microcontrollers (MCUs). This suite of tools evolved into what most developers know today as mbed 2.0 or mbed “Classic.”

However, with the IoT in full swing by 2014, the mbed platform was reimagined as the mbed OS (or mbed 3.0), an end-to-end system stack that linked a client-side operating system (OS) with a server-side management platform.

In theory, this was the right move. The goals of mbed 3.0 were to abstract the idiosyncrasies of embedded development on Cortex-M devices from multiple silicon vendors, while also providing higher level application developers with little to no expertise programming embedded devices access to the vast ecosystem of ARM-based hardware platforms.

In practice, though, it was not so simple. The introduction of a full-fledged OS, hypervisor, networking stacks, security, a web server, etc. in mbed 3.0 resulted in compatibility issues with mbed Classic as new tools and drivers were needed, and eventually the two versions split into separate codebases. Further, the OS developed in mbed 3.0 was an “event-driven OS,” meaning that instead of the multi-threaded operation and resource allocation indicative of traditional real-time operating system (RTOSs), the OS relied exclusively on peripheral interrupts. As any embedded programmer will tell you, the lack of RTOS functionality can present significant challenges when designing more complex or safety-critical systems, particularly in devices that require certain stacks or file systems but not others. The result was a schism that more or less alienated that portion of the developer community.

Unifying IoT with mbed OS 5 Over the past year ARM’s mbed team has been working to merge mbed 2.0 and 3.0 into one cohesive ecosystem

that bridges the gap between embedded developers and programmers working at the service layer. The result is mbed 5 (mbed 2 + 3 = 5), a new rendition of the IoT platform that incorporates key features of its predecessors while also introducing capabilities that streamline development (Figure 1): 1. First and foremost, mbed OS 5 now includes a realtime kernel based on Keil’s RTX implementation of the CMSIS-RTOS. The RTOS core lies beneath the OS delivering native thread support to drivers and applications, and also integrates with networking stacks and mbed’s uVisor security kernel. The “eventing OS” model has also been reinvented as a library, so users of the feature don’t lose any functionality.

2. In terms of tools, mbed OS 5 equips a command line interface (CLI) for Windows, Mac OS X, and Linux environments that can be used for scripting, as well as support for the ARM Compiler 5, ARM GCC Embedded, and IAR compilers. The mbed Online Compiler is also now supported.

3. Finally, the introduction of the RTOS and new tools has enabled compatibility between mbed OS 5 and mbed Classic, resulting in a single, unified platform that serves the needs of both embedded and service-level application developers.

The highlighted improvements are just a few of the updates included in mbed OS 5, which also incorporates new connectivity stacks and crypto libraries. The latest release, mbed OS 5.1, has currently been ported to 40 target platforms. According to sources close to ARM, the mbed platform is now seeing 300,000 – 350,000 compiles per week.

The trials of mbed are indicative of the IoT as a whole, with IT/OT integration revealing nuanced challenges in the marriage of two distinct technology segments.

Additional announcements surrounding mbed are scheduled for November, which, hopefully, will help advance that unification.

mbed OS 2 (”Classic”)

mbed Drivers

mbed Online IDE

Project Export

mbed RTOS

Hardware Components

mbed OS 5

Community Libraries

Merged

mbed OS 3

Fork

mbed Drivers

mbed TLS

www.embedded-computing.com

mbed uVisor

mbed Thread & 6LoWPAN

MINAR

mbed Cloud Client

Reworked

FIGURE 1

mbed OS 5 integrates the two codelines of mbed 2.0 (“Classic”) and mbed 3.0 (“Eventing OS”) into one unified platform.

Embedded Computing Design | September 2016

7

TRACKING TRENDS

rdear@opensystemsmedia.com

Retrofitting Industrie 4.0

By Rory Dear, Technical Contributor The new generation of factory machinery across every manufacturing industry has an unprecedented level of integrated intelligence. Historically, this intelligence was used just for local machine control, and later, for very basic local monitoring, often as simple as the Boolean on/off state.

Today, these machines invariably connect instantly to the factory IT infrastructure via Ethernet. And tomorrow, we’ll see them connect directly to the cloud, particularly as Narrowband IoT (NB-IoT) gains traction. How powerful the Industrial IoT (IIoT) and Industrie 4.0 revolution will be to manufacturing is undeniable, but is it accessible to all?

I can’t help but draw a parallel with the advances in electric vehicles, analogising that whilst we’re all well sold on the benefits, for the majority of drivers, it’s currently unviable. Whether that’s the restrictive cost of the vehicles themselves or the immediate lack of adequate infrastructure, certainly in the UK few are able to take that leap, yet. The affluent are accessing the latest vehicles with vast ranges and thankfully, they have government support improving the infrastructure. In Industrie 4.0, only manufacturing behemoths can afford to ride this first wave; small and medium enterprises (SMEs) simply can’t afford it.

With the cost of replacing factory machinery ranging from hundreds of thousands to millions, smaller manufacturing operations can’t justify upgrading purely to access this control and monitoring revolution. Industrie 4.0 is often sold on efficiency improvements, and unless that’s by an unprecedented factor, it’ll never cover (in any

reasonable time frame) the replacement of a machine.

What these operations need is a retrofit.

For decades, production monitoring in SMEs has been exclusively anecdotal from employees, though many a production manager doesn’t realise even decades-old machinery often has some basic monitoring functionality built in. Even basic Boolean statuses can become powerful when unlocked with the right tools. For example, digital outputs from aged machinery will normally provide at least an on/off status and a “cycle complete.”

The monitoring system pictured is an example of how a small manufacturing business can move from the anecdotal “it was down for “about a half hour last night” to a downtime percentage with many decimal places, with a graph produced purely from monitoring on/off signals. Here we can see that the factory owner could justify removing machine 3 if he can achieve better productivity on machines 1 and 2. This would reduce maintenance, energy, and staff costs and would immediately recover the investment to gather this data.

Retrofitting this capability requires a basic industrial I/O converter, microcontroller- or programmable logic controller-derived (MCU- or PLC-derived) digital/analog and serial signals, and converting to Ethernet. This sounds easier than it actually is; whilst these output lines are surprisingly available in ancient technology, they’re certainly not labelled and the bulk of this retrofit is reverse engineering the signals. Once you establish what data streams are available, the magic is in the server-side software, and once pointed at the correct data, it’s “fit and forget.”

Deploying this monitoring software onto the local server in these factories isn’t always a smooth process.

Creaking server hardware combined with local access issues or a lack of knowledge is the second biggest challenge facing those retrofitting monitoring solutions.

System integrators typically want to use a large industrial human-machine-interface (HMI) that shows live data and in the background takes on the role of the server, removing reliance on existing IT infrastructure.

With cloud accessibility, this HMI can be configured as a web server enabling real-time monitoring from any device, anywhere in the world. It doesn’t exactly deserve the label of Industrie 4.0, but maybe Industrie 3.5. For big manufacturers, this is half-baked, but it’s still a revolution for many manufacturing SMEs.

8

Embedded Computing Design | September 2016

www.embedded-computing.com

EMBEDDED LENS

cschwaderer@opensystemsmedia.com

The Internet of Wild Things

By Curt Schwaderer, Editorial Director Internet of Things (IoT) applications are proliferating and their adoption continues to accelerate at a dramatic pace. However, there are small bastions where IoT has not made an impact, and, in fact, technological advancements hinder the very fabric of the human experience.

I traveled to South Africa to experience the culture and ask the people who would be affected if IoT represents a threat or an opportunity.

Today’s safari experience We arrived at the Karongwe Camp, southwest of Kruger National Park, South Africa area and were greeted with drinks and orientation prior to a game drive. Deane de Swardt, Duty Manger at the Karongwe Portfolio of safaris even touched on the technological. “There is no cell phone coverage at the camp. We do have Wi-Fi at the main lodge only if you so desire to use it, but it’s absolutely optional.”

What an odd statement to an American technologist!

Wi-Fi optional? In who’s world? Of course, the point of a safari vacation for many is to disconnect – get away from the phones and the emails – and experience an environment and culture without electronic interruptions I performed an Internet speed test at the main lodge and expected bandwidth to be monitored in hundreds of bits per second, but was surprised at the results – over 4.5 Mbps download speeds with about 1 Mbps upstream. Talking with Deane I found out that certain companies specialize in Wi-Fi connectivity for remote African encampments for guests and credit card transactions, and that there isn’t any real technical reason Wi-Fi couldn’t be throughout the camp with repeaters; They choose to limit the connectivity to one specific area to give people the ability to be away from it elsewhere.

The case for IoT As we went on the game drives, several things were mentioned that applying IoT could solve. The applications ranged from life saving to convenient.

1. As we came upon rhinos, elephants, or lions, stories came up about poachers. Rhino horns are extremely valuable; the ivory tusks of the elephants are also valuable. Threats to these animals are very real and killings happen too often because of the wide-open ranges they inhabit and no means to track them well enough to identify when they may be in danger from poaching. www.embedded-computing.com

2. Tracking animals to monitor effects on habitat changes and learn more about their travel range and patterns could help us better understand these endangered animals.

3. On the commercial side, guides that are able to show clients exotic animals the most frequently can benefit from word-of-mouth advertising, and the same IoT application that tracks animals could also be used by guides to reliably discover African fauna for clients on safari.

Deane Swardt was born and raised in South Africa, graduated high school at the age of 14, loves animals of all kinds, and has the goal of creating animal rehabilitation centers that specialize in release back into the wild.

I asked her about the presence of Internet communications out in the bush.

“If health and tracking systems could be installed that are targeted toward identifying potential dangers from poaching, that’s a good thing. Even monitoring animals that have been released from rehabilitation to determine how they are adapting back in the wild would be helpful,” she explained.

Can IoT be a bad idea?

Wian van Zyl is the owner of Fuduka Safaris and Freelance Guiding in the Johannesburg area of South Africa. Wian is a licensed guide for birding skills, CyberTracker Track and Sign Level 2, and dangerous game tracker. I posed the question to Wian of whether he would “leave IoT completely out” or “leverage IoT everywhere” in the form of guides simply turning on a “wildlife app” to go right to an animal of choice.

“Part of the adventure is the tracker at the front of the vehicle looking for tracks and signs of animals, then spotting them,” he continues. Making this technology available to the guide takes away the essence of the safari experience. I know that people want a guarantee to see the leopards and the big five animals, but one of the key elements of safari is the unexpected surprise of a spotting. But leaving it to mystery – and tracking the animal – if you use IoT you lose that whole part of the experience.”

There are also security risks. The ability to use connected tracking devices on wild animals can, if hacked, serve the very poachers that is was deployed to defeat.

IoT is real and being considered everywhere for everything, but its consequences need to be considered before it is deployed.

Embedded Computing Design | September 2016

9

SILICON: ARM CORTEX-M SERIES

Securing the edge with ARM TrustZone for v8-M

By Abhijeet Rane

I

ARM’s new 32-bit ARMv8-M architecture was introduced in 2015, adding TrustZone security extensions for Cortex-M microcontrollers (MCUs), among other features. As v8-M-based silicon comes to market, it’s essential that developers understand the architecture, the new capabilities it offers, and how to implement it in the design of connected edge devices that form the foundation of secure end-to-end systems.

nternet of Things (IoT) security issues often result from inadequate protection for devices at the edge of a connected system. These tend to be low power, cheap MCU-based devices that perform a single function, like temperature monitoring. Lack of processing power, memory, and, of course, cost, are often cited as reasons for not being able to properly secure these assets, which are increasingly being exploited by hackers as trampolines to higher value assets connected to the same network.

In order to protect intellectual property, customer data, user safety, and brand reputation against such threats, device makers have investigated a variety of techniques to secure vulnerable endpoints, including the use of multiple MCUs

10

with one or more dedicated solely to performing security functions such as encryption and authentication. This of course raises complexity, cost, and adds another line item to a bill of materials (BOM).

Fortunately, however, that is set to change for MCU-based devices. In 2015 ARM announced that its hardware-based security technology, TrustZone, would be available on Cortex-M MCUs by virtue of the new v8-M architecture. With security capabilities akin to what has been widely deployed across Cortex-A application procesors, ARMv8-M brings foundational security to Cortex-M devices and enables the creation of IoT systems that are secure from end to end.

TrustZone extensions for ARMv8-M: Enhanced security architecture The ARMv8-M architecture is a 32-bit architecture that maintains compatibility with ARMv6-M and ARMv7-M to ease software migration within the Cortex-M family, while also incorporating a host of enhancements and new capabilities, most notably in the way of security. The security enhancements include improvements to the Protected Memory System Architecture and the aforementioned inclusion of TrustZone security extensions, the latter of which allows secure and non-secure states to be established so that multiple security domains can exist within a single Cortex-M device.

Embedded Computing Design | September 2016

www.embedded-computing.com

Sequitur Labs Inc.

TWITTER

www.sequiturlabs.com

LINKEDIN

@SequiturLabs

www.linkedin.com/company/3567007

FACEBOOK

www.facebook.com/sequiturlabs

SILICON: ARM CORTEX-M SERIES

TrustZone for ARMv8-A NON-SECURE STATES

Rich OS, e.g. Linux

TrustZone for ARMv8-M

SECURE STATES

NON-SECURE STATES

SECURE STATES

Secure App/Libs

Nonsecure App

Secure App/Libs

Secure OS

Nonsecure OS

Secure OS

Secure Monitor

System on chips (SoCs) often include multiple microprocessors (MPUs), each assigned to offload system management or other tasks (I/O for example).

In this architecture, one processor typically operates in a privileged state and the other in non-privileged state. While MCU-based systems have also had the ability to establish privileged and unprivileged states via the use of memory protection units (MPUs) or memory management units (MMUs) for some time, the v8-M TrustZone extensions provide an additional level of security and more efficient resource utilization, which reduces system design complexity and thereby cost.

How it works Conceptually, TrustZone for v8-M works similar to TrustZone for Cortex-A processors. Unlike TrustZone technology for Cortex-A-class processors, however, there is no Secure Monitor to manage transitions between the two states.

Instead, the secure and non-secure states are memory map based, which eliminates switching overhead and effectively fulfills the energy efficiency requirements of edge devices (Figure 1).

With TrustZone extensions for v8-M, the definition of secure and non-secure regions in an MCU is at the discretion of the chip designer. This is done using a new capability called the Secure Attribution www.embedded-computing.com

FIGURE 1 TrustZone extensions for ARMv8-M removes the Secure Monitor for more efficient switching between secure and non-secure states in resource-constrained Cortex-M processors.

TrustZone for ARMv8-M

Unit (SAU), a software technology that is used to define secure and non-secure memory regions. Alternatively, device- or system-specific controller logic tied to a special Implementation Defined Attribution Unit (IDAU) interface to the processor can be used accomplish the same. They key difference between the two is that the SAU is programmable in secure states, whereas the IDAU creates a fixed memory map.

Rugged HPEC boards for your OpenVPX Systems Digital Signal Processing DSP boards

10/40 GigaEthernet managed Switches

• Intel® Xeon Broadwell DE • Dual processor (8 cores per processor) • PCIe / 10/40 Gigabit dataplaneFMC site • Up to 48*10GBase-KR or 16 * 40Gbase-KR4 on data plane • Up to 12* Gigabit ports and 6*10G/40G ports

Front End processing boards

• Virtex®-7 & QorIQ 6U VPX processing board

Signal processing and communication FMCs

• Vita ita 57.1/4

lications • Harsh environment app of Development set l Ful a h wit • Supplied ware) tools (firmware and switch t • High-technical suppor • High-performance boards

+33 (0)2 98 57 30 30 • info@interfaceconcept.com • www.interfaceconcept.com

Embedded Computing Design | September 2016

11

SILICON: ARM CORTEX-M SERIES

The processor state depends on which memory region (secure or non-secure) is accessed. The processor state is secure if code is running in the secure memory region, and, similar to traditional TrustZone technology, code executing in the secure memory region has access to the non-secure region but not the other way around. However, TrustZone for v8-M introduces an additional memory type within the secure region called a Non-secure Callable (NSC) that acts as an entry point for code running in the non-secure memory region to access services, functions, or data in the secure region.

Thus, the NSC portion of memory adds a degree of separation between secure and nonsecure memory regions while facilitating access to secure functions. Application developers who need to use NSC memory must do so using a new instruction introduced in the v8 architecture called the Secure Gateway (SG). The SG instruction must reside in NSC memory and must be the first instruction in the API to access secure functions. Any attempt to access secure memory without a valid SG instruction leads to a hard fault.

“ULTIMATELY, THE CHOICE TO LEVERAGE THE CAPABILITIES OF ARMV8-M LIES WITH DEVICE MAKERS, AS TRUSTZONE FOR V8-M WILL REQUIRE THAT DEVELOPERS CHANGE

In addition, ARM has also enhanced AHB-Lite that was defined as part of the AMBA 3.0 interconnect specification. Now AMBA 5 AHB5, the updated specification adds a special instruction to flag secure and non-secure bus transactions, permitting systems with TrustZone for ARM v8-M to interoperate with TrustZone on Cortex-A devices. This feature is essential for enablement design scalability and end-to-end, system-wide security.

APPLICATION DEVELOPMENT

Edge protection scenarios There are a number of security applications are enabled by the new TrustZone extensions for ARMv8-M, including:

ENFORCES DISCIPLINED

› IP protection: Intellectual property, such as proprietary algorithms, relate directly to a company’s intrinsic value. Device makers can use TrustZone for ARMv8-M to store intellectual property in secure memory while still allowing non-secure applications to access it via APIs.

PRACTICES. USING TRUSTZONE FOR ARMV8-M THINKING ABOUT WHAT INFORMATION NEEDS TO BE PROTECTED ...”

OpenSystems Media E-cast Ingredients for baked-in IoT security, from edge to cloud We’ve all seen the headlines: IoT security can’t be an afterthought. We also know that good security starts with a root of trust. Tune in as this assemblage of technology veterans illustrates best practices for baking security into the layer cake of IoT.

September 26, 2016 Sponsored by Avnet, GrammaTech, Lexumo, Xively

ecast.opensystemsmedia.com/671 12

Embedded Computing Design | September 2016

www.embedded-computing.com

FIGURE 2 TrustZone extensions for ARMv8-M enables the creation of secure IoT systems with integrity validated at each level of the design.

› Secure storage of critical information: Keeping user data, identity information, and security keys separate from the rest of the system ensures confidentiality. › Root of trust implementation: A root of trust implementation provides a secure foundation for many different applications, such as secure over-the-air (OTA) firmware updates. Such a basis of trust is also critical to enabling mutual authentication between devices in a system. › Sandboxing of certified software: Software certification is an expensive process. Using certified software for cryptography, for example, allows device makers to enter new markets where such requirements are mandated. TrustZone for ARMv8-M allows keeping such code in secure memory regions while allowing access to applications via APIs in NSC memory regions. › Reducing cost via processor consolidation: In complex SoCs where one processor may be dedicated to performing security functions, TrustZone for ARMv8-M makes it possible to implement the same security capabilities as would be performed by the dedicated processor, thereby reducing cost and complexity. www.embedded-computing.com

End-to-end security example Let’s take a simple door lock example to demonstrate the usefulness of TrustZone for ARM v8-M in achieving end-to-end security. There are four parts to this system – a door lock, a Cortex-M MCU-based camera unit with TrustZone extensions for ARMv8-M that controls the lock, a Cortex-A MPU-based gateway with TrustZone technology, and a smartphone. When someone comes to the door, the camera takes an image and sends it to the gateway, which relays the image to a smartphone app. Upon viewing the image, the user clicks a button in the app to open the door.

In this example, the edge node gains its root of trust from TrustZone for ARMv8-M, which becomes the basis for authenticating itself to the gateway. The gateway also authenticates itself to the mobile phone via TrustZone on the Cortex-A MPU. When the user selects the “open door” command on their phone, the phone relays it to the gateway, which in turn relays it to the edge node to open the door. Commands relayed between devices are validated at each step as part of the process, ensuring system-wide integrity (Figure 2).

TrustZone for ARMv8-M supports energy-conscious devices like wearables or batteryoperated edge nodes in markets such as smart utilities and smart cities. Not only do the TrustZone extensions make it possible to secure the edge, but they change security economics by reducing complexity and eliminating additional parts dedicated to performing security functions. While TrustZone for ARMv8-M-capable silicon has yet to hit the market, several software companies – including Express Logic, Green Hills Software, IAR Systems, IBM, Mentor Graphics, Micrium, Real-Time Engineers, Symantec, and Trustonic – have announced their intentions to support it.

Ultimately, the choice to leverage the capabilities of ARMv8-M lies with device makers, as TrustZone for v8-M will require that developers change application development practices. Using TrustZone for ARMv8-M enforces disciplined thinking about what information needs to be protected, and will likely result in short-term learning curves that could impact the development process. But weighed against the cost of releasing insecure products, the decision is a simple one – TrustZone for ARMv8-M fills an immediate gap in the path towards system-wide security for the IoT. Abhijeet Rane is Vice President of Marketing at Sequitur Labs Inc. Embedded Computing Design | September 2016

13

SOFTWARE: CYBER SECURITY

Security for industrial control systems protects the national infrastructure

By Jim McElroy and Jay Thomas

Industrial control systems – from power plants to factories to water supplies – are moving from proprietary and closed networks to become part of the Internet of Things (IoT). Secure development processes can reduce software vulnerabilities within these critical infrastructures.

I

n a scenario that likely astounds most software developers, a computer worm has become a movie star. In the new action thriller Zero Days, the villain blows up chemical plants, shuts down nuclear power cooling systems, wrecks trains, switches off the national power grid, and more. The star of this fast-moving action flick is the notorious Stuxnet worm that was reportedly developed by US and Israeli intelligence to cripple Iran’s nuclear program. Stuxnet attacked the programmable logic controllers (PLCs) that control centrifuges within nuclear power plants, but the worm and its variants can be tailored to attack systems in a range of manufacturing, transportation, and utility operations.

data acquisition (SCADA) systems for human interface and access. The IEC 61508 standard, along with its derivatives, is implemented to assure functional safety of the software that runs these systems in a broad range of industries. But these SCADA systems, typically Windows- or Linux-based, are in turn connected to corporate management, which needs access for inventory control, marketing, accounting, and a host of other purposes. These are, of course, linked to the external Internet and thus offer a perfect avenue for attack from outside. So while earlier closed systems required hapless or malicious individuals to manually install the worm, today’s Internet-connected industrial systems offer a new attack surface. Due to this high level of connectivity and risk of attack, no system can be considered safe if it is not also secure.

The movie-going public has been largely unaware of the dangers that lurk within our connected infrastructure – dangers that have haunted engineers and developers. Typically, factory automation systems are run using supervisory control and

The heart of developing secure code is to devise a strategy, which can be based on cyber security guidelines such as those published by the National Institute of Standards and Technology (NIST), along with an organization’s own methods, and build them into the requirements document of the system under development. In addition, the project should adopt a coding standard such as MISRA C to guard against questionable methods and careless mistakes that can jeopardize security without being

14

IEC 61508 and its derivatives do not specifically address security. The developer needs to address issues of cyber security from the product development stage to post-market management. To comply with the various guidelines and requirements, developers must use adequate tools in order to deal with the high complexity. As these systems become increasingly subject to certification requirements, correctness in coding must be proven and documented along with the required functionality.

Embedded Computing Design | September 2016

www.embedded-computing.com

LDRA

www.ldra.com

TWITTER

@ldra_technology

LINKEDIN

YOU TUBE

www.linkedin.com/company/ldra-limited

www.youtube.com/user/ldraltd

SOFTWARE: CYBER SECURITY

immediately apparent or even causing functional errors. The next big step, of course, is to make sure that this strategy and coding standard have actually been carried out effectively.

Due to the size and complexity of today’s software, this process can no longer be done manually and must make use of a comprehensive set of tools that can thoroughly analyze the code both before and after compilation.

Use traceability and analysis to verify security While defining requirements is the essential first step, there must be a well-defined method to trace and verify that the requirements have been met. Requirements traceability and management increases code quality and the overall safety, security, and effectiveness of the application. Bidirectional traceability based on a requirements document ensures that every high-level requirement is covered by one or more lowlevel requirements and that every low-level requirement links down into the code, verification activities, and the artifacts produced during the process. Likewise, those links must trace back upstream from the artifacts and code to the requirements, ensuring that any change at any stage in the process can be easily detected, understood, and managed appropriately (Figure 1).

A requirements traceability tool lets teams work on individual activities and link code and verification artifacts back to higher level objectives. Three major capabilities under the supervision of two-way requirements traceability are applied early on and at successive stages of the development process. These are static analysis, dynamic analysis for functional test and structural coverage analysis, and unit/integration testing. The latter applies to both static and dynamic analysis early in the development process and is applied to the later-integrated code as well.

Static and dynamic analysis partner for security In assuring security the two main concerns are data and control. Questions that must be considered include: Who has access to what data? Who can read from it and who can write to it? What is the flow of data to and from what entities? How does access affect control? Here the “who� can refer to persons like developers, operators, and

hackers, and it can also refer to software components either within the application or dwelling somewhere in a networked architecture. To address these issues, static and dynamic analysis must go hand in hand.

On the static analysis side, the tools work with the un-compiled source code to check the code for various quality metrics such as complexity, clarity, and maintainability. Static analysis can also be used to check the code against selected coding rules, which can be any combination of the supported coding standards such as MISRA C or CERT C, as well as any custom rules and requirements that the developer or a company may specify. The tools look for software constructs that can compromise security and also check memory protection to determine who has access to which memory and trace pointers that may traverse a memory location. Results should ideally be presented in graphical screen displays for easy assessment of the results to assure clean, consistent, and maintainable code, as well as coding standards compliance.

This is a process that can be done automatically by running the analysis tool with the coding standard definition

FIGURE 1 A requirements traceability tool provides process transparency and is essential for determining impact analysis at all stages of the development process.

www.embedded-computing.com

Embedded Computing Design | September 2016

15

SOFTWARE: CYBER SECURITY

against the application’s source code. Such code will almost certainly need to be modified to conform to the latest security requirements that have been added to MISRA C (Figure 2).

On the other hand, dynamic analysis tests the compiled code, which is linked back to the source code using symbolic data generated by the compiler. Dynamic analysis, especially code coverage analysis, can provide tremendous insight into the effectiveness of the testing process. However, developers often attempt to manually generate and manage their own test cases, typically by working from the requirements document. These test cases stimulate and monitor sections of the application with varying degrees of effectiveness, but given the size and complexity of today’s code they are not enough to obtain any certifications or approvals that may be required, or even achieve confidence that the code is correct.

Automatic test case generation can greatly enhance the testing process by saving time and money. However, effective test case generation is based on quality static analysis of the code. The information provided by static analysis helps the automatic test case generator create the proper stimuli to the software components in the application during dynamic analysis, and functional tests generated from a requirements document can be created manually to augment the automatically generated test cases for better code coverage and a more effective and efficient testing process. These tests should include any functional security tests such as simulated attempts to take control of a device or feed it with incorrect data that would change its mission, and the created functional tests should also test the results of unallowed inputs and anomalous conditions. Furthermore, dynamic analysis provides not only code coverage but also data flow/control analysis, which in turn can be checked for completeness using two-way requirements traceability.

In addition to testing for compliance to standards and requirements, it is also necessary to examine any segments of what may be “software of unknown pedigree,” or SOUP code. For example, there is danger associated with areas of “dead” code that could be activated by a hacker or obscure event in the system for malicious purposes. Although it is ideal to start implementing security from the ground up, most projects include preexisting code that may have what looks like just the needed functionality. Developers need to resist automatically pulling in such code (even code from the same organization) without subjecting it to exactly the same rigorous analysis used on their own code. Used together, static and dynamic analysis can reveal areas of dead code that

can be a source of danger or may just take up space. As units are developed, tested, modified, and retested by teams of developers (possibly in entirely different locations), the test records generated from a comprehensive tool suite can be stored, shared, and used while units are integrated into the larger project.

In order for systems to be reliable and safe, they must also be secure. For that, they must be coded to comply not only with language rules, but also to adhere to well-defined strategies that assure safety and security. Applying a comprehensive suite of test and analysis tools to an organization’s development process can greatly improve the thoroughness and accuracy of security measures to protect vital systems. It also smooths what can often be a painful effort for teams working towards common goals that need to have confidence in their final product. That product stands a much better chance for customer approval and, if needed, certification by authorities when developed with the safety and security assurances provided by test and analysis tools – and it is far less likely to become the star of the next blockbuster movie.

Jim McElroy is Vice President of Marketing at LDRA Technology.

Jay Thomas is Director of Field Engineering at LDRA Technology.

FIGURE 2 Coding standards compliance is displayed in-line with file/function name to show what aspects of the system do not comply with the standard. A programming standards call graph shows a high-level, color-coded view of the compliance of the system.

16

Embedded Computing Design | September 2016

www.embedded-computing.com

SOFTWARE: CYBER SECURITY

Security for IIoT embedded devices: A platformbased approach

By Carlos Pazos

T

The way the industrial world approaches process management and control is changing. The concept of interconnectedness of intelligent devices in the consumer world is permeating the industrial realm. The resulting interconnected industrial environment is delivering a whole set of benefits – efficiency, safety, and profitability among them. However, while Internet of Things (IoT) concepts can be applied to industrial devices, assets, and infrastructure, the Industrial IoT (IIoT) has much stricter requirements in terms of quality, security, reliability, synchronization, and so on. As such, these systems are more complex and challenging.

he need to move intelligence closer to critical processes has driven the adoption of IoT concepts in the industry, allowing for timely reaction to critical events, effective data reduction, and secure dissemination of information. The increasing availability of low-cost intelligent systems featuring heterogeneous computing architectures for control and data aggregation operations has made this achievable. Such systems do not operate in silos, but rather are part of a system of systems that generate data used to predict situations and make smarter, more informed decisions (Figure 1).

18

From the architectural point of view, IIoT embedded devices must have compelling processing capabilities to deliver significant results. Heterogeneous computing architectures that encompass a mix of general-purpose processors and massive parallel elements are suitable for advanced IIoT applications (Figure 2). General-purpose processors provide powerful, standalone execution of floating-point operations, data logging, and connectivity. And massive parallel elements such as FPGAs and graphics processing units are used to reduce data, customize algorithms, and quickly respond to critical events.

From the security point of view, because IIoT embedded devices operate at the edge, they also represent the last line of defense against attackers. This is often overlooked during the design cycle of such devices because more immediate issues such as lack of domain expertise, implementation costs, and time-to-market constraints relegate security to a secondary plane of importance. Consequently, the 2010 Stuxnet attack exposed the true vulnerability of these systems, demonstrated how much damage an industrial breach can cause, and publicly positioned industrial applications as potential targets.

Embedded Computing Design | September 2016

www.embedded-computing.com

National Instruments www.ni.com

TWITTER

LINKEDIN

@NIglobal

www.linkedin.com/company/3433

YOU TUBE

www.youtube.com/user/nationalinstruments

SOFTWARE: CYBER SECURITY

“THE US DEPARTMENT OF HOMELAND SECURITY INDUSTRIAL CONTROL SYSTEMS CYBER EMERGENCY RESPONSE TEAM ESTIMATES THAT ATTACKS ON US INDUSTRIAL TARGETS CLIMBED FROM

FIGURE 1

IoT architectures are an aggregation of systems that capture analog data before transporting it across various stages of the analytics lifecycle.

FIGURE 2

Outlined is an example of a heterogeneous computing architecture.

41 IN 2010 TO 198 IN 2011 AND 245 IN 2014.”

Wind turbines, nuclear plants, oil and gas pipelines, and similar industrial assets are now the target of government and hacktivist groups that exploit vulnerabilities in industrial devices. The US Department of Homeland Security Industrial Control Systems Cyber Emergency Response Team (ICS-CERT) estimates that attacks on US industrial targets climbed from 41 in 2010 to 198 in 2011 and 245 in 2014.

As this trend continues, it is paramount to consider a different approach that would introduce cyber security concepts from the early stages of embedded device design to prevent, mitigate, and predict attacks that target highly sensitive industrial operations.

The problem described urges both a change in the way embedded devices are developed and a re-evaluation of security standards applicable to such devices. Integrated development platforms and standardization are required to guarantee seamless implementation of security requirements while maintaining interoperability with other IIoT entities. Initiatives such as the IIoT and Industry 4.0 provide best practices and recommendations to address these challenges. However, the integration of www.embedded-computing.com

Embedded Computing Design | September 2016

19

SECURING THE

AUTOMOTIVE

SMART GRID

INDUSTRIAL

INTERNET OF THINGS SAFE, RELIABLE, SECURE. For more than 30 years the world’s leading companies have trusted Green Hills Software’s secure and reliable high performance software for safety-critical applications.

MEDICAL

CONSUMER

For the connected car, consumer and medical devices, industrial telemetry, smart grid, telecom hubs and more, our software and services deliver proven secure, scalable, and reliable embedded technology for the Internet of Things.

TELECOM

DEFENSE

To develop devices for the Internet of Things with the highest levels of security and safety, visit www.ghs.com/secureIoT Copyright © 2016 Green Hills Software. Green Hills Software and the Green Hills logo are registered trademarks of Green Hills Software. All other product names are trademarks of their respective holders.

SOFTWARE: CYBER SECURITY

TABLE 1

A proposed core set of security requirements for IIoT embedded devices.

FIGURE 3

Depicted here is an example Linux-based IIoT embedded platform

these recommendations into an open development platform is still a big challenge the industry must overcome.

A flexible platform with support for standardized, open security technologies would greatly reduce the expertise needed to develop IIoT applications while increasing security in industrial systems. The key to making this platform useful for the IIoT is integrating the right security features so applications can automatically benefit from them.

Unfortunately, a widely applicable security standard for the IIoT is still incomplete and immature (Table 1). Until this standard is ready, designers must look for commonality among existing related standards and fill in any gaps for an integrated solution. A set of widely agreed-upon security features is possible today through open technology such as Linux.

The realization of the IIoT as a feasible approach for making industrial processes more efficient requires using platforms and standards. A platform-based approach is essential to provide embedded designers with development frameworks flexible enough to meet the requirements of multiple application areas. The security aspect of these applications should not be treated differently. A platform that can enable a core set of security requirements common across multiple application areas is a first step toward security best practices standardization for the IIoT. Security features must be fully integrated into development frameworks to be useful to domain experts and embedded engineers unfamiliar with security concepts. Commercially available heterogeneous computing architectures paired with an open, flexible operating system such as Linux can provide the elements for a development platform that meets the IIoT’s security needs (Figure 3).

Carlos Pazos is the Senior Product Marketing Manager at National Instruments. www.embedded-computing.com

Embedded Computing Design | September 2016

21

SOFTWARE: CYBER SECURITY

Using graph analytics and machine learning to continuously monitor open source code for critical vulnerabilities

By Brad Gaynor and Phil Neray

A

Recent advances in graph analytics and machine learning, developed for the Defense Advanced Research Projects Agency (DARPA) and powered by cloud-scale infrastructures, now make it possible to precisely identify all public open source vulnerabilities affecting embedded code at a very granular level – including exactly which functions are vulnerable and why – even if you customize the open source code.

ll businesses are increasingly driven by their ability to innovate with software. Digital business is transforming entire industries, creating new competitive advantages and business models. This is especially true in the world of Internet of Things (IoT) and embedded devices, which blur the physical and digital domains to provide new services by integrating modern devices with cloud, mobile, and big data technologies.

22

Open source is eating the world If software is eating the world, then open source software (OSS) is making it possible.

In fact, a recent study found that 91 percent of IoT developers incorporate reusable open source in their software stack .

Why the shift to open source? It’s simply faster and more efficient for developers to grab existing open source components from the web, add some glue code to stitch it all together, and add their “special sauce” – such as proprietary algorithms, user interfaces, and their brand identity – than to write everything from scratch.

As a result, open source enables more innovation, more collaboration, and quicker time-to-market than ever before. And it’s all enabled by free and reusable OSS.

Embedded Computing Design | September 2016

www.embedded-computing.com

Lexumo

www.lexumo.com

TWITTER

@LexumoKnows

LINKEDIN

www.linkedin.com/company/lexumo

YOU TUBE

www.youtube.com/channel/ UCsRZo252ZdfnTLLmSIPQ28g

SOFTWARE: CYBER SECURITY

Cyber attackers look for the path of least resistance According to Deloitte, security is now the second leading risk to a company’s brand, behind ethical issues and ahead of risks related to safety, health, and the environment. Whether you build products for a consumer or Industrial IoT (IIoT) company, you simply can’t afford to have your brand’s reputation tarnished by a cyber attack affecting your customers’ security and privacy.

With thousands of new open source vulnerabilities discovered every year, the easiest targets for cyber attackers are systems and devices with vulnerable open source components such as OpenSSL, glibc, and bash (Figure 1).

Vulnerabilities are extensively described in public forums, community databases, and even YouTube videos, providing cyberattackers with a clear roadmap – and a global attack surface – to attack critical systems and devices.

In fact, according to the Verizon Data Breach Investigations Report (DBIR), “Most attacks exploit known vulnerabilities – where a patch has often been available for months, if not years.”

A powerful example is the Community Health Systems breach, which was caused by a nation-state exploiting the Heartbleed OpenSSL vulnerability in a network device, resulting in the theft of 4.5 million sensitive consumer records.

As cyber security expert Bruce Schneier has noted, “Heartbleed would have been much worse in a world of Internetenabled thermostats, refrigerators, cars, and everything else, and that’s the world we’re headed toward.”

Who owns responsibility for the security of your open source components?

Unlike commercial products such as Microsoft Windows and Apple iOS, the billions of lines of code in the world’s open source repositories are managed by an informal, decentralized community. www.embedded-computing.com

FIGURE 1

Security vulnerabilities appear frequently and without warning (Source: NIST Common Vulnerabilities and Exposures (CVE) database as of August 2015).

There is no standard, vendor-supported patching mechanism and no single clearinghouse for tracking new vulnerabilities.

So when you incorporate open source libraries such as OpenSSL or Python into your product or cloud service, you also assume responsibility for tracking all their known vulnerabilities and patching them over time. And this responsibility goes across all versions and instances of your product or service.

The challenge is even more pronounced in IoT and embedded systems. Open source packages are often modified to support custom requirements and resource constraints. And simply upgrading a component to the latest “safe” version – the traditionally recommended approach – will often break the rest of your code.

So how do embedded systems developers track the latest vulnerabilities and determine exactly which vulnerabilities affect their particular code – and how do they fix them?

Limitations of current solutions Current OSS governance solutions were primarily architected for license compliance rather than code security. For example, a number of electronics manufacturers were hit with lawsuits a few years ago because they included BusyBox (a popular set of Unix utilities) in their products without complying with the restrictive General Public License (GPL) provisions associated with many open source packages.

Although identifying open source licenses continues to be a key requirement for IoT developers (to reduce legal risk), a fundamentally different architecture is required for identifying vulnerabilities (to reduce security risk). License compliance requires only coarse detection of packages and can be accomplished by simply searching source code for package ID strings and source code fingerprints. It doesn’t require looking more deeply at the actual functionality of your program in order to understand exactly which functions have been patched and which are still vulnerable.

The big challenge is figuring out whether a new vulnerability affects your code, regardless of package ID or version. In particular, you don’t want to be alerted if you’re using a version of a vulnerable library you’ve already patched. That’s called a false Embedded Computing Design | September 2016

23

SOFTWARE: CYBER SECURITY

positive, and it can quickly lead to developer frustration.

Another risk is false negatives, which happens when your security testing doesn’t recognize a vulnerable library because you’ve made superficial changes to it, such as changing file names or adding comments. This is dangerous because you think you’re OK, but in fact your product is quite vulnerable and exposed.

Cloud-scale analytics enable radical new approaches In order to precisely identify all public vulnerabilities affecting your organization’s code, the code must be examined at a granular level rather than simply capturing metadata such as package IDs. Here’s how it works: 1. Ingest the world’s OSS: The first step is creating a massive graph database of the world’s OSS. The Lexumo platform is such a database that continuously crawls the Internet, ingesting every version of every package and library developed by the open source community (Figure 2).

The information is then stored and indexed using a proprietary, abstracted representation that captures the semantics (essentially the “DNA” of each package) rather than its high-level source code or low-level binary representations.

The result is a searchable graph of the world’s OSS, stored in a highly scalable AWS-based cloud stack.

FIGURE 2

The risk dashboard provides a quick snapshot of all open source packages and versions in your code.

2. Curate and annotate vulnerability intelligence: A team of security analysts employs machine learning algorithms to continuously curate detailed intelligence about each known vulnerability and precisely how it was fixed by the open source community. This intelligence is culled from a range of sources that go far beyond the information contained in the MITRE Common Vulnerabilities and Exposures (CVE) database, including from product advisories, mailing lists, and commit logs of open source repositories such as GitHub. The intelligence is then used to annotate the graph of the world’s OSS and run analytics over every branch of every package to identify vulnerable code.

3. Search the annotated graph for vulnerabilities in your embedded code: Next, the platform ingests an abstracted representation of an organization’s code, capturing its essential DNA (the actual source code never leaves the corporate network). This enables the platform to search its annotated graph for all vulnerable open source packages compiled into a product, down to the sub-function level (Figure 3). In addition, the platform continuously monitors code going forward using a Google-like indexed search so that whenever a new public vulnerability such as Heartbleed is announced, immediate alerts are produced.

4. Remediate vulnerable code: The platform provides detailed code-level patch instructions so developers can quickly fix their code without requiring a full version upgrade that can break other dependencies (Figure 4). The platform also provides information about the minimum version required to eliminate the vulnerability, so you can upgrade at a later date.

FIGURE 3 Drill-down information provides vulnerability details, including exactly which functions were found in an organization’s code that exhibit the vulnerability.

24

Embedded Computing Design | September 2016

www.embedded-computing.com

In order to ensure code security across the entire product lifecycle, it’s important to integrate with existing automated workflows. For example, the platform integrates with popular build systems (such as Jenkins and make) and ticketing systems (such as JIRA), constantly running in the background.

Conclusion The world is now asymptotically comprised of OSS due to the transformational ability of open source to accelerate innovation and collaboration while lowering costs and speeding time-to-market. Yet OSS introduces critical vulnerabilities that can damage products and brands – and it’s the developer’s responsibility to ensure the code is safe in their products and applications. Thanks to recent advances in graph analytics and

machine learning powered by scalable cloud-based architectures, advanced levels of automation can be incorporated to simplify this process and reduce organizational risk.

Brad Gaynor is the Founder and CTO of Lexumo.

Phil Neray is the VP of Security Strategy for Lexumo.

FIGURE 4 Detailed patching instructions enable developers to quickly fix vulnerable code based on exactly how the code was patched by the open source community.

DON’T LET A NATURAL DISASTER BECOME A TOTAL DISASTER Single Board Computer

Weather happens. When it does, you can take comfort knowing your critical embedded system is taking care of itself when a power outage strikes. a minute of operation after total power loss, time which system integrity.

Starting at

$159 Qty 100

Contact Technologic Systems at 480-837-5200 or www.embeddedARM.com We’ve never discontinued a product in 30 years

www.embedded-computing.com

Embedded systems that are built to endure

TS-7680 Support every step of the way with open source vision

Unique embedded solutions add value for our customers

Embedded Computing Design | September 2016

25

STRATEGIES: TRUSTED COMPUTING

31 flavors of trust?

By Steve Hanna

W

hen billions of things are connected together in the IoT, how can the trustworthiness of each thing be verified? How can connections be validated? Are the devices connecting to one another healthy and free of malware, viruses, or other exploits?

The TCG has been addressing the trust issue – and related security benefits – for PCs, servers and networking gear for more than a decade. The concept of trust for these products has been built on an international standard (ISO 11889), the Trusted Platform Module (TPM), which defines a standard hardware root of trust.

Originally designed for securing laptop and desktop computers and servers, the old TPM 1.2 specification was significantly updated over the years. However, as the world changed, TCG and its

26

With its TPM 2.0 specification the Trusted Computing Group (TCG) addresses security for embedded applications in the Internet of Things (IoT).

members changed their approach to how the specification was written and implemented. For more flexibility of application and to enable more widespread use of the specification, TCG created TPM 2.0 with a “library” approach. This allows users to choose applicable aspects of TPM functionality for different implementation levels and levels of security. Also, new features and functions were added such as algorithm agility, the ability to implement new cryptographic algorithms as needed.

A TPM for embedded applications With TPM 2.0, TCG created a library specification that describes all the commands/ features that could be implemented and might be needed in platforms from servers to laptops to embedded systems. Each platform can choose the features needed and the level of security or assurance required. In this way, TPM 2.0 is much more flexible than the original TPM specification. That flexibility allows the newest TPMs to be applied to many embedded applications, including automotive, industrial, smart home, and many more.

Five types of TPM are popular today, offering different tradeoffs between cost, features, and security.

1. The discrete TPM provides the highest level of security, as might be needed for a TPM used to secure the brake controller in a car. The intent of this level is to ensure that the device it’s protecting does not get hacked via even sophisticated methods.

Embedded Computing Design | September 2016

www.embedded-computing.com

Trusted Computing Group (TCG) www.trustedcomputinggroup.org

TWITTER

LINKEDIN

@TrustedComputing

YOU TUBE

www.linkedin.com/groups/4555624/profile

www.youtube.com/user/TCGadmin

STRATEGIES: TRUSTED COMPUTING

To accomplish this, a discrete chip is designed, built and evaluated for the highest level of security that can resist tampering with the chip, including probing it and freezing it with all sorts of sophisticated attacks.

2. An integrated TPM is the next level down in terms of security. This level still has a hardware TPM but it is integrated into a chip that provides functions other than security. The hardware implementation makes it resistant to software bugs, however, this level is not designed to be tamper-resistant.

3. The next level is often called a firmware TPM. In this case, the TPM is implemented in protected software. The code runs on the main CPU, so a separate chip is not required. While running like any other program, the code is in a protected execution environment called a trusted execution environ­ ment (TEE) that is separated from the rest of the programs that are running on the CPU. By doing this, secrets like private keys that might be needed by the TPM but should not be accessed by others can be kept in the TEE, creating a more difficult path for hackers.

In addition to the lack of tamper resistance, the downside to the TEE or firmware TPM is that now the TPM is dependent on many additional aspects to keep it secure, including the TEE operating system (OS), bugs in the application code running in the TEE, etc.

4. Another type of TPM is the softwareTPM. It can be imple­ mented as a software emulator of the TPM. However, a software TPM is open to many vulnerabilities, not only tampering but also the bugs in any OS running it. It does have key applications: it is very good for www.embedded-computing.com

Relative Cost

Trust Element

Security Level

Security Features

Discrete TPM

Highest

Tamper resistant hardware

$$$

Critical systems (e.g., steering/ braking systems)

Integrated TPM

Higher

Hardware

$$

Gateways

Firmware TPM

High

TEE

$

Entertainment systems

Software TPM

NA

NA

¢¢

Testing & prototyping

Virtual TPM

High

Hypervisor

¢¢¢

Cloud environment

TABLE 1

Typical Application

A rough security, cost, and application comparison of discrete, integrated, firmware, software, and virtual TPMs.

testing or building a system prototype with a TPM in it. For testing purposes, a software TPM could provide the right solution/approach.

In addition, the software TPM can be adapted for other form factors. For example, an embedded design engineer can take the software TPM and port it to run in a TEE, thus becoming a firmware TPM. The software TPM can provide the basis for creating more secure implementations, so it can be a valuable development tool for experimentation and increased security understanding.

5. Many IoT systems include sensors and cloud processing, which means virtualization. In a cloud environment, one clever way to implement a TPM is through a virtual TPM. The virtual TPM is part of the cloud-based environment and it provides the same commands that a physical TPM would but it provides those commands separately to each virtual machine (VM). When code is executed in the cloud, a virtual TPM may already be offered by the cloud provider. If not, a software TPM can be run in a separate VM to provide the virtual TPM. That virtual TPM can be as secure as the firmware TPM. The virtual TPM is widely available but designers are frequently unaware of it when they are building a cloud.

Securing embedded things These five flavors of TPM, discussed roughly in order of security level and decreasing cost, are shown in Table 1. To get a better handle on the cost and security level impact, the TPM supplier needs to be consulted.

Once a computer, controller, or ASIC has some level of TPM, the document TCG Guidance for Securing IoT informs designers how they can take advantage of the TPM for more security[1]. In addition to cars, smart homes and industrial, information communications technology (ICT) in cloud servers, and networks can all benefit from the increased security that one of the TPMs provides.

Steve Hanna is a member of the Technical Committee in the Trusted Computing Group and a member of the Security Area Directorate in the Internet Engineering Task Force (IETF).

References: 1. “Securing IoT Using TCG Technology Reference Document | TCG.” Trusted Computing Group. 2015. Accessed August 24, 2016. http://www.trustedcomputinggroup.org/ tcg-guidance-securing-iot/.

Embedded Computing Design | September 2016

27

STRATEGIES: TRUSTED COMPUTING

Issues of trust in silicon

By Dr. Jason Oberg

M

any techniques are used to build security features into silicon, including: › Adding security extensions, such as ARM’s TrustZone, to processors to allow them to run in secure and non-secure modes › Implementing Trusted Platform Modules (TPMs) designed to secure hardware by integrating cryptographic keys › Incorporating a physically unclonable function (PUF) that provides a unique challengeresponse mechanism dependent on the complex and variable nature of the silicon material used to manufacture the system on chip (SoC) All of these design principles and primitives are necessary to ensure that the resulting silicon has the tools in place for

28

Trust in modern silicon is something most of us take for granted.

software to build a trusted computing environment. Many have been implemented, and the Department of Defense (DoD) requires all systems to include a TPM[1].

These security primitives and platforms are a great start. However, simply including a security intellectual property (IP) block or primitive is not enough to make the system or silicon secure. Security vulnerabilities can still exist within an SoC design due to several design and verification issues that often arise due to varying levels of trust and expertise.

Modern SoCs are composed of hundreds of IP blocks and many come from a myriad of different vendors. Should a design team trust all of them? Probably not. Were these blocks designed to avoid all known security pitfalls? Definitely not.

Most problems stem from either IP vendors who have different levels of trust or those who are concerned with functionality above all else.

Issue 1: Vastly different levels of trust Some IP blocks are commonplace, such as a standard USB controller. If it appears to behave like a USB controller, then there shouldn’t be any concerns. However, when they are purchased from an IP vendor with a relatively low trust level, how can a design team expect it to behave well with the rest of the system?

Other IP blocks serve extremely crucial roles, such as an in-house developed crypto key manager, for example. Including both of these blocks of IP in an SoC can introduce

Embedded Computing Design | September 2016

www.embedded-computing.com

Tortuga Logic, Inc. tortugalogic.com

STRATEGIES: TRUSTED COMPUTING

Silicon security needs to be done by design and security verification needs to be done at every stage of the development, especially as the various IP blocks are integrated together.

Issue 2: Vendors concerned with functionality only Blindly trusting test vectors provided by a third-party IP vendor is a poor approach to building a secure system. When IP vendors develop their test suites, their only concern is functionality. They solely strive to ensure that the logic and accuracy of their IP blocks matches the functional specification.

For instance, IP vendors check whether their AES-256 core can correctly perform encryption in the right number of cycles. However, correctly performing encryption is completely orthogonal to ensuring the AES-256 core is devoid of security flaws such as leaking the secret key to any unintended outputs.

In other words, IP vendors do not strive to meet a security specification. It is naive to trust that the test vectors provided by the IP vendor will exercise all critical security aspects. Therefore, it is incumbent upon the SoC design team to perform security verification on all IP blocks to ensure silicon security.

elusive security issues not considered during the architectural design. One example is whether the USB controller has access to the crypto key manager over the SoC interconnect. One would hope not, but many SoC vendors do not know because they do not perform the appropriate security verification at each stage of the design cycle.

The way an IP block is integrated into an SoC can easily exercise aspects of the block that will violate the security of the system. Assume a cryptokey manager provides an interface for storing the key. A debug state of the key manager could potentially let someone read out the key. What if this security vulnerability was not covered in the test vectors provided by the IP vendor? Again, the burden is on the SoC design team to perform security verification on all IP blocks to ensure silicon security.

The design for security solution These types of vulnerabilities can be avoided if SoC design teams implement a Design For Security (DFS) methodology by identifying and verifying silicon security properties throughout the hardware design lifecycle, from architecture discussions to tapeout[2].

FIGURE 1 An SoC design team built several Trusted Computing elements into this design (figure courtesy of Microsemi).

www.embedded-computing.com

Embedded Computing Design | September 2016

29

STRATEGIES: TRUSTED COMPUTING

This entails adequately defining the desired security properties during the SoC’s architectural design. Next, these security properties must be verified at both the individual IP block level, as well as the integration of all IP blocks in the design with appropriate security verification software.

Tortuga Logic offers a security property language called Sentinel and Prospect security verification software to hardware designers who plan to employ the DFS methodology.

Summary Every block, whether simple or complex, must be verified for security to ensure a secure system. When not utilizing DFS, security vulnerabilities such as the ones cited may still exist, regardless if the design team uses security primitives such as PUFs, TPMs, and crypto processors.

As SoC design teams implement DFS methods within their register-transfer

level (RTL) design flows, security vulnerabilities can be addressed and eradicated from architecture to tapeout, ensuring a fully secure system. We can go back to trusting modern silicon.

Dr. Jason Oberg is the chief executive officer of Tortuga Logic.

References: 1. “U.S. Army requires trusted computing.” http://bit.ly/2afJ4SG. 2. Khattri, et al., “HSDL: A security development lifecycle for hardware technologies.” 2012 IEEE International Symposium on Hardware-Oriented Security and Trust.

Hardware Security Development Lifecycle* Security Requirements Assessment

Architecture Review

Design Review

Pre-Silicon Testing

Post-Silicon Testing

Design-for-Security Properties

Security Verification

OS Kernel Firmware

FTL

FIGURE 2

Netlist

RTL/Netlist

Firmware Netlist

A DFS methodology encompasses verifying security at every stage of the hardware design lifecycle.

OpenSystems Media works with industry leaders to develop and publish content that educates our readers.

A ten point guide for managing requirements for the Internet of Things

By IBM The Internet of Things (IoT) offers many exciting opportunities for product innovation, new business models, and expanding revenue streams.

Companies looking to take advantage of these opportunities should start with a strategic approach to requirements management that will transform products into connected systems. To help companies think through the various impacts of IoT on requirements, IBM offers these ten tips.

embedded-computing.com/white-papers/white-requirements-the-internet-things-iot

30

Embedded Computing Design | September 2016

Check out our white papers at www.embedded-computing.com/ white-papers www.embedded-computing.com

EXECUTIVE SPEAKOUT

ADVERTORIAL

Green Hills Software Helps Build an IoT We Trust

By Gregory Rudy, Director of Business Development, INTEGRITY Security Services On any given day, an Internet of Things (IoT) device wakes us up in the morning, powers our homes, and drives us to work.

Along the commute we pass networks of sensors collecting real-time data to determine the optimal route while transmitting the information to a growing chain of systems designed to improve our efficiency, accuracy, and economic benefit. But what happens when one of these devices fails?

Consequences for security failure range anywhere from missed meetings to exposure of private information – or even personal injury. As the IoT grows layer-by-layer, so too does our dependence on valid data and reliable operation. How much benefit can the IoT really provide if it can’t be trusted?

WWW.GHS.COM

High Assurance Operating System – Green Hills INTEGRITY real-time operating system and INTEGRITY Multivisor virtualization technology are designed to provide absolute separation between processes and partitions. Using hardware memory protection to isolate and protect applications, INTEGRITY guarantees each address space has the resources to run while being protected from errant and malicious code.

Secure Coding Environment – Tools for building secure devices are critical too. From the MULTI integrated development environment (IDE), C/C++ compilers, and static code analysis to the TimeMachine debugging suite and trace debug probes, code production, and bug elimination is highly optimized.

Green Hills Software and subsidiary INTEGRITY Security Services (ISS) are championing IoT security by supporting product companies with their expert knowledge and solutions to develop safe and secure devices. Customers continue to rely on Green Hills Software’s 30 years of proven experience delivering layered secure operating environments to defend against cyber security vulnerabilities.

Green Hills understands that safe and secure operation must be designed and not retrofitted. The only way to build a highreliability system is to plan it from the start, yet all industries and products differ. True product security requires an experienced team to design a security architecture that aligns with your technology and business. Green Hills and ISS offer the most comprehensive solutions by integrating the following products and services to secure IoT devices across all lifecycle phases: Security Architecture Studies and Certification Services – Developing an end-to-end security design, whether a company just starting to understand security architectures or those needing independent validation or certification and implementation support, requires expert security and certification services specific to your products, process, and supply chain.

Secure Boot Toolkits – The ISS Secure Boot Toolkit uses best practice cryptography to verify software is authentic and unmodified during each startup or periodically during operation. ISS toolkits integrate with several leading hardware vendors, including Texas Instruments, NXP, STMicroelectronics, Infineon Technologies, and Intel.

Embedded Cryptographic Toolkit (ECT) – The core of all secure IoT devices is the security platform providing cryptographic services for the confidentiality, authentication, and integrity of software and data during network transit and storage. ECT is a FIPS 140-2-compliant cryptographic library including the latest algorithms such as AES, RSA, and ECC. As a standalone module, ECT integrates to hardware security cores, providing missing algorithm support, including x.509 certificates, asymmetric algorithms, and encrypted storage of keys and data.

Enterprise Security Infrastructures – The secrecy of all cryptographic devices depends on keys and digital trust assets injected during manufacturing. As more devices incorporate cryptography, it will become easier to attack the supply chain to uncover keys and digital trust anchors. The Device Lifecycle Management system equips organizations with PKI services to securely generate and distribute keys, certificates, and digital signatures across complex supply chains worldwide.

As our daily routines grow to depend on more and more IoT devices, the need for vigorous product security increases exponentially. With an end-to-end security design, devices can be trusted at a high level – much the same as airplanes and defense systems. We know this because we secure those too.

Visit Green Hills Software at www.ghs.com and INTEGRITY Security Services www.ghsiss.com to learn more.

EXECUTIVE SPEAKOUT

ADVERTORIAL

Avoid the Crisis: Embedded Security Integrated From the Start

WWW.MAXIMINTEGRATED.COM

By Scott Jones, Executive Director, Embedded Security, Maxim Integrated Security is often an afterthought or a reaction to a crisis after a system has been hacked or valuable products have been counterfeited. These types of events inevitably have a negative impact through loss of data, money, or reputation. The solution is to anticipate and act on the need for security from the start. With this mindset, developing a robust and effective security solution should follow a structured four-part process that should be applied continuously to deal with unavoidable threat advancement. See Figure 1 below.

FIGURE 1

Risk Analysis Evaluation

Requirements

Implementation RISK ANALYSIS • Which system assets require protection?

It is fundamental to first clearly identify which assets in the embedded system require protection. What is it that an adversary will work to exploit, damage, or bring down? The motivation could be financial or malicious. Examples of assets at risk include sensors or tools used with medical devices, application firmware stored in FLASH, the communication link to an industrial process, and industrial control sensors and modules.

System Requirement Authenticity Integrity Confidentiality

FIGURE 2

Cryptographic Solution Digital Signature Encryption

• What are the threats to these assets?

Once it is understood which assets require protection, identifying the possible threats the security solution will thwart is the next step in the analysis. Additionally, how vulnerable are the assets? Examples of threats include counterfeit products, reuse of medical tools, snooping of sensitive data, and injecting unauthorized code or operating data.

REQUIREMENTS With the risk analysis defined, the process transitions to mapping the appropriate security solution(s) to address the needs. There is a common misconception that security is all about encryption, therefore it is important to define the three solution categories that will be applied either individually or in combination: • Authenticity: Ensuring that information or a system component is genuine. Examples include counterfeit prevention or authenticating industrial sensor measurement results.

• Integrity: Ensuring that information has not been modified. An example would be verifying that firmware or calibration data used to control an industrial process is virus free.

• Confidentiality: Used to ensure that communication or information is only accessed by or is visible to authorized entities. Examples include communication over public or private networks, transmission of sensitive medical measurements, or financial records.

Figure 2 provides a mapping of these three system requirements to proven cryptographic solutions that are applicable to embedded systems: IMPLEMENTATION Selection of cryptographic algorithm(s), key type, and key size for a solution can be daunting. For the scope of this article, the vast subject of implementation is simplified to the widely adopted algorithms used to solve the needs of digital signature and encryption in embedded applications. Best practice for any solution is to employ proven standards-based algorithms that are managed by NIST and defined through associated FIPS standards1.

Algorithm Type Characteristics

Crypto Solution Typical Algorithms

Symmetric (Secret-key)

• Computationally efficient – fast compute times Digital Signature

SHA-MAC/HMAC, AES

• Relatively small key size

Encryption

AES, 3DES

Asymmetric (Public-key)

• Computationally complex – longer compute times

Digital Signature

ECDSA, RSA-DSA

Encryption

ECC, RSA

• Robust key management and distribution

TABLE

• Large key size with RSA The table above provides a high level summary comparing the two algorithmic key types – symmetric and asymmetric – along with the typical standards-based algorithms. Depending on system requirements there may be a need to combine crypto solutions and algorithms. For example, an ECC-based public-key may be needed to exchange a shared secret between two sub-systems for a subsequent session of AES encrypted data exchange.

As summarized in the ‘Characteristics’ column of the table, computational complexity of algorithm types will vary. This becomes critical in embedded applications based on a micro with relatively low processing power, for example 8-bit or 16-bit without math acceleration or a coprocessor. Particularly for the case of asymmetric algorithms, it may be impractical to use a low-power micro due to excessively long compute times and/or working memory constraints.

‘How’ and ‘where’ the implementation exists are critical elements to the solution. One option would be security implemented through firmware running on a standard non-secure microcontroller. The other option is through optimized and robust ICs that are specifically designed for and dedicated to embedded security tasks.

Cryptography running on standard micros presents a class of vulnerability that should be considered in the risk analysis. It is relatively straightforward to extract firmware from a standard micro and reverse or defeat the solution. Maxim Integrated offers the DeepCover® family of IC-based embedded security products2 which implement the cryptography and protection against direct threats in dedicated hardware. This approach embodies the philosophy that security starts at the core of the system and should exist at the physical layer to prevent an attacker from circumventing protection mechanisms.

EVALUATION (AND MONITORING) The requirements for cryptographic security would not exist if system threats were not present. Threats are continuously evolving as are the skills, methods, and tools available to the adversaries. This in turn drives advancements in algorithms, countermeasures, and implementations. Similarly, embedded security solutions should be regularly monitored against advancements in threats, or a possible compromise, that would warrant modification and/or an increase in the security protection level necessary.

When possible, an independent evaluation of the security implementation should be obtained. Some end products or markets require formal certification, for example Payment Card Industry3 (PCI) equipment that performs electronic financial transactions. More common, however, are assessments performed by reputable labs or by suppliers of hardware and software security components, who have implementation expertise and a vested interest to ensure that the solution is robust.

References: 1) NIST FIPS Publications, http://csrc.nist.gov/publications/PubsFIPS.html 2) Embedded Security by Maxim Integrated, https://www.maximintegrated.com/en/products/digital/ embedded-security.html 3) PCI Security Standards Council, https://www.pcisecuritystandards.org/

MAXREFDES143# DEEPCOVER EMBEDDED SECURITY REFERENCE DESIGN: IoT AUTHENTICATED SENSING AND NOTIFICATION

LEARN MORE: WWW.MAXIMINTEGRATED.COM/MAXREFDES143 For more information, visit us on:

www.facebook.com/MaximIntegrated/ https://twitter.com/Maxim_IC https://www.linkedin.com/company/maxim-integrated

Editor’s Choice

EDITOR’S CHOICE

www.embedded-computing.com/editors-choice

Self-encrypting SSDs support AES-256 encryption for IIoT systems Virtium recently released its StorFly self-encrypting drives (SEDs), a family of industrial-grade solid-state drives (SSDs) with integrated AES-256 encryption engines and random number generators that allow crypto keys to be stored on the devices themselves. Available in all major form factors including 1.8", 2.5", CFast, M.2, mSATA, and Slim SATA, the Opal 2.0-compatible StorFly SEDs eliminate the overhead of softwarebased encryption while also supporting crypto- and block-erase functions. Built for the embedded and Industrial Internet of Things markets, the SEDs are designed to industrial temperature ranges (-40 °C to +85 °C) and come in MLC, industrial-grade MLC, and SLC variants. The SSDs also include Virtium’s vtGuard Power Fail Protection to defend against corruption resulting from power loss, resulting robust storage solutions that guarantee the security and integrity of data at rest.

Virtium

www.virtium.com | www.embedded-computing.com/p373762

Long lifecycle, high-performance COM Express modules DFI Tech’s SU968 COM Express Compact module features the Intel 6th generation Core i7 processor with 3.4 GHz dual-core performance, dual DDR3L 16 GB memory, and support for up to eight x1 PCIe expansion. The COM express module is compliance with R2.1, Type 6 and includes display interface options for 1 VGA/DDI, 1 LVDS/eDP, and 1 DDI. A 1.04 GHz quad-core Atom processor X5-E8000 and high-definition graphics is also available, sporting three independent displays and 4K resolution.

DFI Technologies

www.dfitech.com | www.embedded-computing.com/p373763

Innovative low-power sound detector for always-listening applications Sensory has announced deployment of its Low Power Sound Detector (LPSD) for use with “always listening” speech recognition applications. LPSD is being implemented as hardware in DSP designs, digital microphones, and sensor fusion hubs, and as firmware in DSP and MCU designs. Sensory’s LPSD is designed to only wake the audio chain to detect a keyword trigger when potential speech is sensed. The solution conserves power usage by allowing the remaining speech recognition audio chain of a device to be switched off until needed for speech processing. LPSD is another component in Sensory’s TrulyHandsFree always-on, always-listening speech recognition technology that offers accurate, robust embedded speech recognition with a minimal battery/power draw. LPSD reduces the average power consumption of an always-listening implementation to less than 1 mA, which is the target for use in wearables and other battery-operated consumer electronics.

Sensory

www.sensory.com | www.embedded-computing.com/p373764

ZigBee chip targets smart home & IoT applications Qorvo’s ZigBee chips will be incorporated into Levarys’ Luna Smart Home System, including thermostats, radiator valves, doors, windows, and smart plugs wirelessly connected to a home gateway. The ZigBee chips have been designed as highly integrated RF solutions and SoCs with long range and high interference rejection. Qorvo’s ZigBee Green Power chips’ very low current draw significantly extends battery life, making the system very low maintenance. Levarys offers starter kits that can be extended with extra devices to fit the requirements of any house. With an included easy-to-use app on a smartphone or tablet, users can turn devices on and off and control the thermostat while at home or on the road, providing comfort and significant energy savings. The Luna system also makes intelligent decisions based on input from sensors.

Qorvo

www.qorvo.com | www.embedded-computing.com/p373765

34

Embedded Computing Design | September 2016

www.embedded-computing.com

Connecting Global Competence

Planet e: Where the future begins.

Embedded solutions of tomorrow. Today.

Embedded exhibition sector: November 8–11, 2016 electronica Embedded Forum: November 8–11, 2016 Embedded Platforms Conference: November 9–10, 2016 All about electronica Embedded: electronica.de/en/embedded

Tickets & Registration: electronica.de/en/tickets

World’s Leading Trade Fair for Electronic Components, Systems and Applications Messe München I November 8–11, 2016 I electronica.de

DESIGN-IN EMBEDDED SOLUTIONS Simplify your IoT deployment with the Advantech Gateway Starter Kit

This powerful and complete IoT gateway starter kit empowers your IoT project with a reliable platform and open gateway technologies. The package includes a ready-to-run fanless automation system (Intel® Celeron® J1900 platform and Windows® 7 Embedded), IoT platform software, development kit and technical support service. Also included is Microsoft® Azure® service integration.

Get your IoT Gateway Starter Kit: Buy.Advantech.com/go/IoTGateway

Building Blocks for Embedded Applications

Industrial Digital Signage Solutions

• 2.5” Pico-ITX - 5.25” embedded SBC form factors • Rich I/O & wide temp options (-40~85°C)

• Ranging from 6.5”-32” LCD displays • Available in high bright, resistive & PCAP options

1-888-576-9668 | Buy.Advantech.com | We Manufacture it > You Click It > We Ship It

Our partners: