X-Ware IoT Platform Integrates STM32 Firmware Update

Express Logic has announced that it has integrated the STMicroelectronics’ Secure Boot and Secure Firmware Update v.2.0 services with its X-Ware IoT Platform for its developers using the STMicroelectronics’ STM32-family of ARM Cortex-M microcontrollers.
The X-CUBE-SBSFU Secure Boot and Secure Firmware Update solution enables the update of the STM32 MCU built-in program with new firmware versions based on the X-Ware IoT Platform. The update process is performed in a secure way to prevent unauthorized updates and access to confidential on-device data. In addition, Secure Boot (Root of Trust services) checks and activates STM32 mechanisms, and checks the authenticity and integrity of X-Ware IoT Platform before every execution to ensure that invalid or malicious code cannot be run.

Because X-CUBE-SBSFU is built on top of STM32Cube software technology, the X-Ware IoT Platform integration will be portable across the entire range of STM32 microcontrollers, beginning with the STM32L4 and STM32L4+ series devices.

Express Logic  considers itself a safety leader in the embedded IoT space with its industrial-grade approach, including pre-certification to SIL 4 and ASIL D safety standards. The new secure boot and secure firmware update services from STMicroelectronics enhance security for Express Logic’s X-Ware IoT Platform for the STM32 microcontroller.

Express Logic | www.rtos.com

STMicroelectronics | www.st.com

Protect IoT Designs with PUF Circuitry

Maxim-Chip-DNAAs IoT designs proliferate, security is lagging. Hardware-based security using physically unclonable function (PUF) circuitry strongly protects connected products against invasive attacks. A cryptographic key is generated only when needed and isn’t stored on the secure IC. Even probing the chip impedes the attack.


 

Protect IoT Designs with Physically Unclonable Function Circuitry

By Ben Smith, Principal Member of the Technical Staff, Embedded Security, Maxim Integrated

While DNA connects us to every other human being on the planet, it also makes each of us unique. That uniqueness has proven to be useful as a means of positive identification. For example, DNA-based evidence has exonerated some from erroneous convictions and provided verification of guilt in other cases.

The DNA that we all carry as unique identification contrasts greatly with what happens in the technology world. In technology, it’s an imperative for every instance of a type of device to be identical, right down to the last micron, microvolt, and byte. Every device must look, feel, and act the same. After all, it’s important to deliver a consistent user experience. However, this sameness is not ideal when it comes to security.

Ensuring Authenticity Via Random Chip Properties

When every device is identical, how can we know whether messages that claim to come from a particular device actually do? It is possible that those messages might originate from an impersonator. For example, consider a door secured with an access keypad. The door actuator might receive a message from the keypad that the correct code had been entered, and that the door should be opened. But how can the actuator validate that the message is authentic?

For us humans, engaged in face-to-face communications, these questions are non-issues. We know the person we’re talking to because we know how they look and how they sound. In other words, we know the expressions in their physical characteristics of the DNA that makes each of us unique. Imagine the possibilities if our devices possessed that kind of uniqueness.

Indeed, even with devices, there is a way, and that way can be found in physically unclonable function (PUF) technology. While each device may function in an identical way, devices with PUF technology contain an element that makes each of them unique. Deep inside devices equipped with this technology is a circuit element that measures certain physical characteristics of the chip itself. These physical characteristics are stable over time, but they do vary from device to device. The PUF technology logic uses these device-specific variations to compute a value that remains the same every time it’s computed, but that is unique to the particular instance of the device. This value serves as each device’s unique identifier, in the same way that your DNA uniquely identifies you.

The importance of sender identity and message integrity can be illustrated via this simple scenario. Consider a sensor at a remote location that sends a message that there’s a problem. Is the message truly authentic? You have a few options involving secrets and keys:

Option one: a shared secret

Before deploying the sensor, you could program in a secret, like a password. When the sensor sends a message, it would incorporate this password into the message in some agreed-upon way. Once you’ve received the message, you could check to ensure that the password was sent correctly before accepting the message.

Trouble arises when that same password is used for all such sensors. This scenario would make it easy for a cybercriminal to reverse-engineer the device in order to steal the password. Then, the hacker is free to impersonate messages from any device of that type. An even scarier situation happens when the password is sent without cryptographic protection. Then, a cybercriminal can simply eavesdrop on a conversation in order to steal the password. No need to touch the device at all. They could then impersonate any sensor anywhere they are deployed. Clearly, shared secret schemes are too vulnerable to attack.

Option two: public-key cryptography

By programming a private key into your device, your device can digitally sign messages with the private key that can be verified using a corresponding public key. This approach enables messages to be authenticated with near certainty. It is practically impossible to modify or forge a signed message. In other words, there is no known way to impersonate a signer in any reasonable amount of time without the signer’s private key.

The vulnerability in this approach lies in the fact that the secret, private key has to live somewhere in the memory space of the target device. And if an attacker can slip in malware, it’s easy for the malware to leak the private key. Once the malware is developed, firmware update mechanisms can be used to propagate the malware. Before you know, a large set of the affected devices could be compromised.

Option three: PUF technology

PUF technology represents the most secure option because its private key is never disclosed, not even to its owner. The private key is only generated when needed (when a message is ready to be signed), and it is never stored (it is immediately destroyed when no longer needed).  The computed value never appears in the microcontroller’s memory map.

There are various ways in which you can use PUF technology. For instance, before a device manufacturer deploys an internet of things (IoT) device, it can command the hardware containing PUF technology to compute a public key that corresponds to the PUF technology value – the private key. The actual PUF technology value is never disclosed. The device manufacturer then signs the public key with their own corporate private key to create a certificate that they then write back to the device. That certificate can later prove that the public key that the device presents is the same one that was computed at the factory, because nobody can create a valid certificate without the corporate private key. Once deployed, when the IoT device wants to send a message, it can sign the message by recomputing the PUF technology value, using that value as the private key. If the message receiver has the public key for that device, it can verify, with a high degree of assurance, that the message is authentic, unmodified, and came from that particular device.

Now, we’ve got millions (and growing) of IoT devices in the wild. There really isn’t a single database that tracks the public key belonging to every IoT device. Anyone receiving a message from an IoT device probably doesn’t have that particular device’s public key. However, they can request the device’s public key certificate from the device itself. When the device sends the certificate, the receiver can check the validity of the certificate via a two-step process. First, the receiver can verify the certificate’s signature using the signer’s public key. Second, assuming the certificate has proven valid, the receiver can test the validity of the device’s message by using the public key contained in the certificate. This entire process takes less than a second.

You Can’t Steal a Key that Isn’t There

So, you might be wondering, is PUF technology secure enough? The answer to this question lies in the fact that the private key doesn’t even exist until the physical properties of the chip are measured. Even then, the private key is destroyed when it is no longer needed. The private key can’t be discovered by using rogue firmware because the private key only exists in secured, walled-off hardware, not in the actual memory space of the microcontroller. Probing the chip itself will change the characteristics that are measured to determine the PUF technology value, further impeding this type of attack.

Maxim-ChipDNA-diagram

Figure 1: Block diagram of ChipDNA physically unclonable function (PUF) technology, which provides strong protection against invasive attacks.

Maxim’s PUF circuitry takes advantage of the naturally occurring random analog characteristics of fundamental MOSFET devices to produce cryptographic keys. The solution, called ChipDNA technology (Figure 1), ensures that the unique binary value generated by each PUF circuit is guaranteed to be repeatable over temperature and voltage and as the device ages. ChipDNA technology is available in the DS28E38 DeepCover secure authenticator. To learn more about how ChipDNA works, you can read the white paper, “How Unclonable, Turnkey Embedded Security Protects Designs from the Ground Up;” watch a video; and see use cases by visiting the ChipDNA webpage.

Maxim Integrated | www.maximintegrated.com

Sponsored by: Maxim Integrated

Wearables Drive Demand for Extreme Low Power Solutions

Wearables-Issue-329Wearable devices put extreme demands on the embedded electronics that make them work. Devices spanning across the consumer, fitness and medical markets all need a mix of low-power, low-cost and high-speed processing.


 

 

MCUs & Analog ICs Meet Needs

By Jeff Child, Editor-in-Chief

Designers of new wearable, connected devices are struggling to extend battery life for next-generation products, while at the same time increasing functionality and performance in smaller form factors. These devices include a variety of products such as smartwatches, physical activity monitors, heart rate monitors, smart headphones and more. The microcontrollers embedded in these devices must blend extreme low power with high integration. Meanwhile, analog and power solutions for wearables must likewise be highly integrated while serving up low quiescent currents.

Modern wearable electronic devices all share some common requirements. They have an extremely low budget for power consumption,. They tend not to be suited for replaceable batteries and therefore must be rechargeable. They also usually require some kind of wireless connectivity. To meet those needs chip vendors—primarily from the microcontroller and analog markets—keep advancing solutions that consume extremely low levels of power and manage that power. This technology vendors are tasked to keep up with a wearable device market that IDC forecasts will experience a compound annual growth rate (CAGR) of 18.4% in 2020.

MCU and BLE Combo

Following all those trends at once is Cypress Semiconductor’s PSoC 6 BLE. In September the company made its public release of the PSoC 6 BLE Pioneer Kit and PSoC Creator Integrated Design Environment (IDE) software version 4.2 that enable designers to begin developing with the PSoC 6. The PSoC 6 BLE is has built-in Bluetooth Low Energy (BLE) wireless connectivity and integrated hardware-based security.

According to Cypress, the company had more than 2,500 embedded engineer customers registering for the PSoC 6 BLE early adopter program in just a few months. Early adopters are using the flexible dual-core architecture of PSoC 6, using the ARM Cortex-M4 core as a host processor and the Cortex-M0+ core to manage peripheral functions such as capacitive sensing, BLE connectivity and sensor aggregation. Early adopter applications include wearables, personal medical devices, wireless speakers and more. Designers are also using the built-in security features in PSoC 6 to help guard against unwanted access to data.

The PSoC BLE Pioneer Kit features a PSoC 63 MCU with BLE connectivity (Photo 1). The kit enables development of modern touch and gesture-based interfaces that are robust and reliable with a linear slider, touch buttons and proximity sensors based on the latest generation of Cypress’ CapSense capacitive-sensing technology. Designers can also use the board to add USB Power Delivery (PD) with its Cypress EZ-PD CCG3 USB-C controller. The development kit also includes a 2.7-inch E-ink Display Shield add-on board (CY8CKIT-028-EPD) with thermistor, digital mic and 9-axes motion sensor.

Photo 1 The PSoC BLE Pioneer Kit features a PSoC 63 MCU with BLE connectivity. The kit enables development of modern touch and gesture-based interfaces that are robust and reliable with a linear slider, touch buttons and proximity sensors based using Cypress’ CapSense capacitive-sensing technology.

Photo 1
The PSoC BLE Pioneer Kit features a PSoC 63 MCU with BLE connectivity. The kit enables development of modern touch and gesture-based interfaces that are robust and reliable with a linear slider, touch buttons and proximity sensors based using Cypress’ CapSense capacitive-sensing technology.

Deep Sleep Current Levels

Extreme low power was also the theme behind Microchip Technology’s PIC32MX1/2 XLP family that the company announced in June. The 33-bit PIC32MX1/2 XLP offers current PIC32MX system developers an easy migration path to achieve higher performance at much lower power. It enables both increased functions and longer battery life in portable applications. According to Microchip, the new MCU family increases performance in small pin-count devices with little code rework for existing customers.

Microchip’s XLP technology is designed for wearable technology, wireless sensor networks and other smart connected devices and offers low current operating modes for Run and Sleep, where extreme low-power applications spend 90% to 99% of their time. XLP technology will enable Sleep and Deep Sleep shutdown states on the PIC32MX1/2 XLP devices, enabling Deep Sleep currents down to 673 nA. The devices offer over 40% more performance than the existing PIC32MX1/2 portfolio while reducing average currents by 50%. Figure 1 shows an XLP MCU used in a health/fitness wearable application.

WearablesFigure1

Figure 1 Shown here is a Microchip XLP MCU used in a health and fitness wearable application.

The PIC32MX1/2 XLP family is available in a range of memory configurations with 128/256 kB flash and 32/64 kB of RAM in packages ranging from 28- to 44-pins. They also include a diverse set of peripherals at a low cost including I2S for digital audio, 116 DMIPS performance for executing audio and advanced control applications, a 10-bit, 1 Msps, 13-channel ADC and serial communications peripherals. The PIC32MX2 series also supports USB-device, host and OTG functionality.

In addition to the hardware peripheral features, the series is supported by Microchip’s MPLAB Harmony Software Development Framework, which simplifies development cycles by integrating the license, resale and support of Microchip and third-party middleware, drivers, libraries and RTOSes. Specifically, Microchip’s readily available software packages such as Bluetooth audio development suites, audio equalizer filter libraries, decoders (including AAC, MP3, SBC), sample rate conversion libraries and USB stacks will reduce the development time of wearable device applications.

Transactions with Wearables

Among the new features of some wearable devices is the ability to do contactless transactions. Today’s consumers have become quite comfortable with making secure transactions using their smart devices. As a result, traditional card manufacturers want to extend their offerings into contactless wearable products for uses such as payments, ticketing and access control. These can be difficult to implement within tight size and cost constraints, because conventional separate NFC-radio and security chips demand extra space and complicate design. In addition, wearable form factors tend to need small antennas that can restrict communication performance.

Supporting those capabilities in wearables, ST Microelectronics in October unveiled its technology for easy and secure contactless transactions using electronic wristbands or fashionwear like watches or jewelry. The ST53G System-in-Package solution combines the company’s expertise in Near Field Communication (NFC) and secure-transaction chips. ST’s new ST53G System-in-Package combines a miniaturized and enhanced NFC radio with a secure banking chip in one compact 4 mm x 4 mm module (Figure 2). The company’s proprietary boosted-NFC technology enables wearables with small antennas to deliver a great user experience when interacting with card readers over typical contactless distances.

Figure 2 ST’s ST53G System-in-Package combines a miniaturized and enhanced NFC radio with a secure banking chip in one compact 4 mm x 4 mm module.

Figure 2
ST’s ST53G System-in-Package combines a miniaturized and enhanced NFC radio with a secure banking chip in one compact 4 mm x 4 mm module.

The simplicity of this all-in-one module helps card enables embedded developers to quickly design functional and attractive wearables that can range from fashion items to one-time devices like event wristbands. ST offers an extensive development ecosystem, including radio-tuning tools and pre-defined antenna configurations. The ST53G meets all relevant card-industry standards, including EMVCo compliance, ISO/IEC-14443 NFC card emulation, and MIFARE ticketing specifications. The ST53G can host ready-to-use STPay smartcard operating systems and optional VISA/ Mastercard/JCB-certified banking applications pre-loaded on the secure microcontroller.

Embedded Security for Wearables

The secure banking chip contained in the ST53G System-in-Package leverages ST’s proven ST31G480 secure microcontroller that is based on the ARM SC000 SecurCore processor. It features a secure architecture with a NESCRYPT coprocessor for public-key cryptography and hardware accelerators for algorithms like AES and triple-DES. Extensive anti-tamper protection including an active shield, environmental monitoring, a unique serial number for each die and protection against numerous other attacks are also built-in. These features complement software-based security running on the SC000 core to ensure the strongest possible protection for users’ credentials.

The contactless IC is the STS3922 RF booster, which uses active-load modulation (ALM) to maximize transaction range and omnidirectional radio performance in card-emulation mode. This enables wearable devices to be easy to use—with equal or better device-to-reader positioning tolerance than conventional contactless smartcards—even though a smaller antenna is used. Using ST53G contributes to final device cost optimization because small antennas can be etched onto the PCB at almost zero additional cost. In some cases, a challenging metallic case can itself be used as part of the RF antenna.

Automatic power and gain control, configurable sensitivity, and configurable signal/reader-field phase difference ensure consistent communication over all ranges. These enhance smooth interoperability with different types of readers and terminals including various transportation ticketing systems. The STS3922 has a dedicated secure-MCU wake-up output. That feature enables the ST53G System-in-Package to maximize battery life by powering down when not in use.

Power Regulation for Wearables

Designing today’s wearable devices requires not just low power on the MCU side. They also require sophisticated analog IC solutions that help regulate power and extend battery life as much as possible. Along those lines, Maxim Integrated in March announced its the MAX17222 nanoPower boost regulator with what the company claims is the industry’s highest efficiency and lowest quiescent current (IQ) of only 300 nA (Figure 3). The 0.4V to 5.5V input, 1.8V to 5V output boost regulator with 500 mA input current limit reduces solution size by up to 50% compared to similar products and offers 95% peak efficiency to minimize heat dissipation.

Figure 3 The MAX17222 boost regulator offers a low quiescent current of 300 nA, 0.4V to 5.5V input, 1.8V to 5V output and 500 mA input current limit.

Figure 3
The MAX17222 boost regulator offers a low quiescent current of 300 nA, 0.4V to 5.5V input, 1.8V to 5V output and 500 mA input current limit.

Aside from very low quiescent current, the MAX17222 also minimizes heat dissipation and shutdown current. In True Shutdown mode, the minuscule current draw of 0.5 nA virtually stops battery drain to provide the longest battery life and eliminate the need for external disconnect switches. The MAX17222 is internally compensated and requires only a single configuration resistor and small output filter for a full power solution. For ease of use, the boost regulator comes in tiny, density-optimized 0.88 mm x 1.4 mm 6-bump WLP and 2 mm x 2 mm 6-pin standard µDFN packages. It operates over a -40°C to +85°C temperature range.

Health monitoring wearable devices have their own particular analog design challenges. Targeting such needs, Analog Devices offers a low power, next-generation biopotential analog front end (AFE) which enables smaller, lighter and less obtrusive cardiac monitoring devices with longer battery life. The AD8233 AFE is a fully integrated, single-lead electrocardiogram (ECG) front end designed in one compact, easy-to-use component. Typically, developers need to design ECG front ends from individual components, which can add incremental cost and design time.

Health Monitoring Solution

The highly integrated, out-of-the-box AD8233 AFE eliminates these unnecessary costs and extra time, helping developers get products to market more quickly. Additionally, the device’s 2.0 mm × 1.7 mm size enables the design of wearable health devices that are smaller, lighter and easier to wear. Bulky, heavy and obtrusive monitors can be unpleasant for patients to wear and may even interfere with their everyday lives. Longer battery life is another crucial attribute for cardiac monitors and is vital to ensure continuous monitoring that provides accurate data without the interruption of a recharge or battery replacement. The AD8233 AFE’s low microamp-range power consumption results in greatly extended battery life.

Along with its small size, the single-supply (1.7 V to 3.5 V) AD8233 features extremely low quiescent current of 50 μA (typical); lead on/off detection even while in shutdown mode (less than 1 μA); and 80-dB common-mode rejection ratio (DC to 60 Hz). Electrical noise, a critical specification for cardiac-monitoring devices, is below 10 μV from 0.5 to 40 Hz. The AD8233 also allows for highly flexible filter configurations which are essential to consistent, confident operation in an inherently harsh electrical environment under a range of use cases. These configuarations include a two-pole adjustable high-pass filter, a three-pole adjustable low-pass filter with adjustable gain and an RFI filter. For ease-of-use and flexibility, it also includes an integrated right leg drive (RLD) amplifier with shutdown plus an uncommitted op amp. Analog Devices also offers an evaluation board, reference design, web based filter design tool and Spice model to facilitate design-in and speed time to market.

The AD8233CB-EBZ evaluation board contains an AD8233 heart rate monitor (HRM) front end conveniently mounted with the necessary components for initial evaluation in fitness applications (Photo 2). Inputs, outputs, supplies and leads off detection terminals are routed to test pins to simplify connectivity. Switches and jumpers are available for setting the input bias voltage, shutdown (SDN), right leg drive shutdown (RLD SDN), fast restore (FR) and AC/DC leads off detection mode. The AD8233CB-EBZ evaluation board is a 4-layer board with components mounted on the primary side only. Rubber feet are available on the secondary side for mechanical stability. The layout diagrams are provided as a visual aid and reference design.

Photo 2 The AD8233CB-EBZ evaluation board contains an AD8233 heart rate monitor (HRM) front end conveniently mounted with the necessary components for initial evaluation in fitness applications.

Photo 2
The AD8233CB-EBZ evaluation board contains an AD8233 heart rate monitor (HRM) front end conveniently mounted with the necessary components for initial evaluation in fitness applications.

Wireless Connectivity

Seamless wireless connectivity has pretty much become a given for today’s wearable devices. With that in mind, Cypress Semiconductor in September announced a new combo solution that delivers ultra-low power Wi-Fi and Bluetooth connectivity to extend battery life for wearables and portable audio applications. The new Cypress CYW43012 solution prolongs battery life by leveraging 28 nm process technology to cut power consumption up to 70% in receive mode and up to 80% in sleep mode when compared to current solutions. The solution is IEEE 802.11a/b/g/n-compliant and 802.11ac-friendly, meaning it is interoperable with 802.11ac access points using standard modes. This enables it to offer higher throughput and better energy efficiency, along with the enhanced security and coverage of 802.11ac Wi-Fi networks.

The CYW43012 combo chip’s advanced coexistence engine enables optimal combined performance for dual-band 2.4- and 5-GHz Wi-Fi and dual-mode Bluetooth/BLE 5.0 applications simultaneously. The CYW43012 solution is supported in Cypress’ all-inclusive, turnkey, WICED Studio IoT development platform, which streamlines the integration of wireless technologies for developers. According to Cypress, battery life is a key differentiator for connected devices like wearables. Users demand a great connected experience for longer without having to recharge.

The Cypress WICED Studio IoT development platform features an integrated and interoperable wireless software development kit (SDK). The SDK includes broadly deployed and rigorously tested Wi-Fi and Bluetooth protocol stacks, as well as simplified application programming interfaces that free developers from needing to learn complex wireless technologies. In line with the IoT trend toward dual-mode connectivity, the SDK supports Cypress’ Wi-Fi and Bluetooth combination solutions and its Bluetooth and Bluetooth Low Energy devices. The SDK enables cloud connectivity in minutes with its libraries that integrate popular cloud services such as Amazon Web Services, IBM Bluemix, Alibaba Cloud and Microsoft Azure, along with services from private cloud partners. WICED also supports iCloud remote access for Wi-Fi-based accessories that support Apple HomeKit, which enables hub-independent platforms that connect directly to Siri voice control and the Apple Home app remotely.

Cypress’ WICED Studio connectivity suite actually is MCU-agnostic and provides support for a variety of third-party MCUs to address the needs of complex IoT applications. The platform also enables cost-efficient solutions for simple IoT applications by integrating MCU functionality into the connectivity device. Wi-Fi and Bluetooth protocol stacks can run transparently on a host MCU or in embedded mode, allowing for architectures with common firmware.

As consumers push for more capabilities in their wearable products, they won’t tolerate any reduction in battery life. Along the way, wireless connectivity and embedded security will have to be supported. These conflicting trends will continue to challenge MCU and analog IC vendors to come up with more integrated solutions at ever lower power consumption levels.

RESOURCES
Analog Devices | www.analog.com
Cypress Semiconductor | www.cypress.com
Microchip | www.microchip.com
ST Microelectronics | www.st.com
Maxim Integrated | www.maximintegrated.com

October Circuit Cellar: A Sneak Preview

The October issue of Circuit Cellar magazine is on the launch pad, ready to deliver a selection of excellent embedded electronics articles covering trends, technology and design.

Not a Circuit Cellar subscriber?  Don’t be left out! Sign up today:

 

Here’s a sneak preview of October Circuit Cellar:

TECHNOLOGY FOR DRONES / ROBOTIC HAND

Commercial Drone Design Solutions Take Flight: Chips, Boards and Platforms
The control, camera and comms electronics inside today’s drones have to pack in an ambitious amount of functionality. Circuit Cellar Chief Editor Jeff Child explores the latest Oct 327 Coverand greatest chip and module solutions serving today’s commercial and consumer drone designs.

Building a Robot Hand: With Servos and Electromyography
Learn how three Cornell University students developed a robotic hand. The system captures impulses generated by muscle contractions and then filters and feeds those signals to a microcontroller which controls finger movement.

 

CAN’T STOP THE SIGNAL

Signal Chain Tech Pushes Bandwidth Barriers: ADCs, FPGAs and DACs
FPGAs and D-A converters are key  technologies making up a signal chain. Here, Circuit Cellar Chief Editor Jeff Child steps through the state-of-the-art options available for crafting efficient, highly-integrated signal-centric systems.

Antenna Performance Measurement Made Easy: Covering the Basics
If you’re doing any kind of wireless communications design, chances are you’re including an antenna. Columnist Robert Lacoste shows how the task of measuring an antenna’s performance is less costly and exotic than you’d think.

MONITORING GEAR WITH MICROCONTROLLER BRAINS

Gas Monitoring and Sensing (Part 1): Fun with Fragrant Analysis
Columnist Jeff Bachiochi covers the background issues surrounding gas monitoring and sensing. Then he describes how he uses sensors, A/D conversion and Arduino technologies to do oxygen measurement.

Logger Device Tracks Amp Hours (Part 1): Measuring Home Electricity
Setting out to monitor and log electricity usage in his house, Bill Wachsmann built an amp-hour logger using a microcontroller and a clamp on ammeter.

KEEPING THE LEGACY ALIVE

Emulating Legacy Interfaces: Do it with Microcontrollers
There’s a number of important legacy interface technologies—like ISA and PCI—that are no longer supported by the mainstream computing industry. In his article Wolfgang Matthes examines ways to use microcontrollers  to emulate the bus signals of legacy interconnect schemes.

Building a Retro TV Remote : PIC MCU-Based Design
Dev Gualtieri embarks on building a retro-style TV remote, based on a Microchip PIC microcontroller. He outlines the phototransistor, battery and software designs he made along the way.

AND MORE FROM OUR EXPERT COLUMNISTS:

Get in the Loop on Positive Feedback: New Value in an Old Concept
Positive feedback loops are an important element of modern circuitry such as crystal oscillators, PLLs and other devices. Here, George Novacek goes deep into the math and circuit analysis of positive feedback and how it’s used in electronics.

Build an Embedded Systems Consulting Company (Part 6): Trade-Offs of Fixed-Price Contracts
Continuing his “Building an Embedded Systems Consulting Company” article series, this month Bob Japenga explores the nature of contracts and how fixed price contracts can be an effective, albeit dangerous tool in marketing.

September Circuit Cellar: A Sneak Preview

The September (326) issue of Circuit Cellar magazine serves up a meaty selection of useful technology resources along with inspiring, interesting embedded electronics design articles.

Not a Circuit Cellar subscriber?  Don’t be left out! Sign up today:

cclogo_2013_header

Here’s a sneak preview of September Circuit Cellar:

FOCUS ON MICROCONTROLLERS

Getting Started with PSoC Microcontrollers (Part 3): Data Conversion, Capacitive Sensing and More
In Part 3, Nishant Mittal gets into some if the PSoC’s more complex features like Data Conversion.

Implementing a Time-Oriented Task Manager for 8-bit PIC Microcontrollers
Pedro Bertoleti shows readers how to build a time-oriented task manager using Microchip’s PIC 16F628A 8-bit microcontroller.

SPECIAL SECTION: EMBEDDED SECURITY

Microcontrollers Beef Up Security Features: Defense in a Connected World
Jeff Child explores the various flavors of embedded security features that microcontroller vendors are adding to their devices.

Resources for Embedded Security: Hardware, Software and Services
Circuit Cellar collects four pages worth of info about companies that provide embedded security products, tools and services.

TECHNOLOGY FEATURES

Using Power Audio Amplifiers in Untypical Ways (Part 1): Best Building Blocks
Petre Petrov shows readers how to use PAAs as universal building blocks to create analog signal generators, analog power supplies, voltage splitters and more.

Data Acquisition Advances Focus on Interfacing
Jeff Child discusses the latest data acquisition solutions, with a look at how interface technologies have evolved.

Future of IoT Communications: Will Upgraded Cellular Networks Benefit IoT?
This guest essay by Andrew Girson, CEO of Barr Group, explores how IoT will fare in the 5G network era.

MORE FROM OUR EXPERT COLUMNISTS:

Block Diagram Reduction and Automatic Tuning
George Novacek steps through how to think in terms of block diagrams to help you reduce system complexity early on in a design.

Numeric Precision vs. DDS Calculations
Using the full frequency resolution of a DDS chip outstrips the capabilities of floating point numbers. Ed Nisley looks at high-res frequency calibration and measurements in the DDS realm.

Deadbolt the Uninvited: Locked Out of My Home
In this Part 2 of Jeff Bachiochi’s electronic lock story, he gets into some of the power and remote-control issues of his electronic deadbolt lock project.

Diagnosing Performance Variations in HPC
Ayse K. Coskun delves into how application performance variations can cause inefficiency
in high-performance computing (HPC) systems and how to diagnose these variations.

August Circuit Cellar: A Sneak Preview

The August (325) issue of Circuit Cellar magazine is jammed packed with useful technical information and inspiring, intriguing embedded electronics design stories.

Not a Circuit Cellar subscriber?  Don’t be left out! Sign up today:

 

Here’s a sneak preview of August Circuit Cellar:

FUN WITH GUITAR AMPLIFIERS!

Digital Guitar Amplifier/ Effects Processor—Part 2
Brian Millier details the digital guitar amplifier/effects unit he built using two Teensy Arduino modules.

A Range of Power Supplies for Hollow-State Guitar Amplifiers
Richard Honeycutt compares several different power supplies used for hollow-state guitar amplifiers.

MICROCONTROLLERS & PROCESSORS!

Firmware Upgrade with the PIC32
Nick Sicalides delves into performing firmware upgrades using a bootloader on the Microchip PIC32

Getting Started with PSoC Microcontrollers (Part 2): Putting PSoC to Work
Nishant Mittal goes even deeper on the Cypress PSoC providing some useful design examples.

Moore’s Law and the Chip Industry’s Perfect Storm
In this Interview Q&A Krste Asanovic explains RISC-V and the open sourcing of processor architecture.

SECURITY & RELIABILITY & ENCRYPTION!

Power Analysis of a Software DES Encryption Routine
Columnist Colin O’Flynn examines how to break a software implementation of the DES security routine.

Reliability and Failure Prediction: A New Take
Craig Armenti and Dave Wiens discuss a better way to simulate PCB vibration and acceleration.

Preventing Unwanted Entry
Columnist Jeff Bachiochi takes us inside his exploration of electronic lock systems, getting down to the fine details.

Future of Embedded Security: Wi-Fi to the Danger Zone
This guest essay by Adam Cecchetti, CEO of Deja vu Security, explains how memory leaks in your embedded system could have life or death consequences.

AND MORE FROM OUR EXPERT COLUMNISTS:

Automatic Control (Part 4) The Implementation
George Novacek describes the PID temperature controller he built for a meat smoker.

Fully Differential Amplifiers
Robert Lacoste sings the praises of fully differential amplifiers and presents a few designs using them.

Build an Embedded Systems Consulting Company (Part 5) Axiom Wrap-Up
Bob Japenga shares more insights on running a successful embedded design firm built to last.

Understanding Embedded Security

Protecting products and intellectual property (IP) from attackers is a fairly new concept that many engineers have not yet had to face. It is only a matter of time, though, until products—which are becoming more embedded and integrated with the real world—become targets for attacks leading to theft of service, loss of revenue, or a damaged corporate reputation. Consumer electronics, financial and medical technology, and network products are all at risk.

In this article, I’ll focus on the “why” and the “what” of embedded security, also known as secure hardware. Why does it matter? Why is it important to you, the designer? In what ways can someone attack your product? Because you can’t incorporate secure design methods without understanding what you are protecting and why, this article is a fitting introduction to the complexities of embedded security.

Reading this article won’t turn you into a security expert overnight. Nor will it provide all the answers to your secure hardware design needs. But, it will help you understand the major classes of attack and the mindsets of potential attackers. Actual secure hardware mechanisms come in all shapes and sizes, ranging from tamper-resistant enclosures to embedded IC dies in PCBs (to make them more difficult to probe). I’ll discuss these in a future Circuit Cellar article.

What embedded security typically comes down to is this: Is the cost of a successful attack greater than the value of what’s being protected? I’ll present some guidelines to help you make a determination.

UNDERSTAND YOUR RISK

As with everything in engineering, embedded security is all about trade-offs—risk management, as they say in the business world. Are there components or data in your system that need to be protected? If so, how much is it worth to protect them?

Forget what the glossy marketing material says about security products. There’s never a single answer and a single product to solve everybody’s product security needs. Every product has its own threat risks and is susceptible to certain types of attacks. Before being able to make an educated, informed decision, you need to understand the threat, the value of the contents being protected, and the reason for protecting such contents. Essentially, weaker, more vulnerable devices should contain less valuable secrets.

For example, a priceless family heirloom might be stored in a fireproof and tool-resistant safe. However, it wouldn’t make much financial sense to purchase such a safe to store an easily replaceable, inexpensive piece of jewelry. By the same token, it wouldn’t be feasible to implement an extremely secure, multilayered hardware solution just to protect a single password that is used to access undocumented features in a mobile phone; but, it would be in order to protect a financial institution’s cryptographic keys used for encrypted communications whose theft could result in the loss of millions of dollars.

When defining the security envelope of your product, there are three questions you should ask yourself (or your design team). First, what needs to be protected? Identify the critical components in your circuit that need to be protected before you start construction. It’s extremely difficult to implement proper security mechanisms after the fact. Such components to protect may include specific algorithms, device identifiers, digital media, biometrics, cryptographic keys, or product firmware. In addition to protecting discrete data contents, you may be interested in implementing a secure product boot sequence, secure field programmability, or a secure remote-management interface. Be aware that in some cases, even noncritical portions of your design can unknowingly compromise the security of the system, especially if they fail in an unanticipated way.

Second, why is it being protected? In most situations, critical data is being protected to prevent a specific attack threat. Ignoring or overlooking the possibility of attack can lead to a vulnerable product. In some countries, protecting certain content may be a legislative requirement. For example, a medical device containing confidential patient information must be secured in order to meet the U.S. Health Insurance Portability and Accountability Act (HIPAA) requirements.

Finally, whom are you protecting against? The types of attackers vary, ranging from a curious, harmless hardware hacker to an entire group of researchers backed by a competitor, organized crime, or government. As such, it’s important to attempt to properly identify the skill level and theoretical goals of the primary attackers against your product.

As a designer, you have the challenging task and responsibility of creating and ensuring your system’s security. You must understand every possible aspect of the design and are typically constrained by technical, financial, and political agendas. Attackers have an easier job, which is to exploit insecurities in the system. They need only to discover one vulnerable area of the design, and they typically have few constraints on their methods. They’ll likely choose the attack that yields the best results in the easiest and most repeatable fashion.

CLASSES OF ATTACK

No system will ever be 100% secure. “Secure” simply can be defined as when the time and money required to break the product is greater than the benefits to be derived from the effort. Given enough determination, time, and resources, an attacker can break any system.

At the highest level, four classes of security threat exist, as described by C.P. Pfleeger in Security in Computing. Through interception (or eavesdropping) an attacker can gain access to protected information without opening the product. With embedded systems, this can be achieved by monitoring the external interfaces of the device and by analyzing compromising signals within electromagnetic radiation or current fluctuations. On a computer network, this can be done by illicitly copying data or through promiscuous mode network monitoring. Although a loss may be discovered fairly quickly for certain attacks, like credit card theft or spoofed user authentication, a silent interceptor might not leave any traces.

Interruption (or fault generation) is a threat because an asset of a product becomes unavailable, unusable, or removed. An example is the malicious destruction of a hardware device, the intentional erasure of program or data contents, or a denial-of-service network attack. Fault generation consists of intentionally provoking malfunctions, such as operating the device under abnormal environmental conditions, which may lead to the bypassing of certain security measures.

The third type of threat is modification, which involves tampering with a product’s asset. Modification is typically an invasive technique for both hardware (e.g., circuit modifications or microprobing) and software/firmware (e.g., changing the values of data or altering a program so that it performs a different computation).

Lastly, fabrication creates counterfeit assets in a product or system. Fabrication can come in many forms, including adding data to a device, inserting spurious transactions into a bus or interface, and a man-in-the-middle attack on a network. Sometimes these additions can be detected as forgeries, but if skillfully done, they may be indistinguishable from the real thing.

TYPICAL ATTACK GOALS

When a product is targeted, the attacker usually has a goal in mind. This may be a simple goal, such as reverse engineering the circuitry in order to personalize or customize the device, or a more dedicated one, such as retrieving cryptographic keys or sensitive product trade secrets.

The specific goal of an attack tends to fit into one of four categories. The first is competition (or cloning), which is a scenario in which an attacker (usually a competitor) reverse engineers or copies specific IP in order to gain an advantage in the marketplace. The goal is to improve a product by using the stolen technology or to sell lower-priced knockoffs. Common target areas are circuit board features and product firmware.

Theft-of-service attacks aim to obtain a service for free that usually requires payment. Examples include mobile phone cloning, bypassing copy protection schemes on video game systems, and modifying cable boxes to receive extra channels.

User authentication (or spoofing) attacks are typically focused on products that are used to verify the owner’s identity, such as an authentication token, smartcard, biometric reader, or one-time-password generator. The attacker’s main goal is to gain access to personalized data and systems by spoofing the identity of the legitimate user.

Privilege escalation (or feature unlocking) attacks are aimed at accessing the hidden/undocumented features of a product and increasing the amount of control given to the user without having legitimate credentials. For example, using specialized circuitry to communicate with a mobile phone to gain access to phone diagnostics or acquiring administrator access on a network appliance.

Generally, an attack is achieved in one of three ways. In a focused attack, the adversary brings the target product into a private location to analyze and attack it on his or her own time with little risk of being discovered. A focused attack is probably the most familiar type of attack. Consider a curious student modifying a piece of hardware in his dorm room or a more determined criminal in a laboratory attempting to crack encryption routines.

Lunchtime attacks often take place during a small window of opportunity, such as a lunch or coffee break. Typically, the attack would need to be completed in a short period of time, ranging from a few minutes to a few hours. Lunchtime attacks are risky because they are easily detected if the target product is missing or has visibly been tampered with. For example, if you check your coat at a restaurant, an attacker could remove your PDA, retrieve the desired data, and return the PDA to your coat pocket within a matter of minutes and without being detected. Another example is an attacker copying data from a target’s authentication token or USB thumb drive that they left on their desk while attending a meeting.

Finally, there’s the insider attack, which may come in the form of run-on fraud by a manufacturer (producing additional identical units of a product to be sold on the gray market) or a disgruntled employee willing to sabotage the product or sell critical information such as system firmware or encryption keys. Many, but not all, insider threats can be thwarted with strict compartmentalization of critical data, access control, and chain-of-custody policies.

PRODUCT ACCESS

There are many ways an attacker can gain access to your product, but it often corresponds directly to the attack goal and usually involves one of four methods. In the first instance, the attacker purchases the product through a retail outlet, often with no means of detection (e.g., paying with cash). Multiple products could be purchased, with the first few serving as disposable units to aid in reverse engineering or to discover any existing tamper mechanisms. This scenario may be financially prohibitive for low-budget attackers but is typical for most focused attacks.

In the second instance, the attacker rents or leases the product from a vendor, distributor, or rental company, often on a monthly basis. Most attack types are possible in this instance, but because there is a high risk of detection when the product is returned, attackers will be cautious not to tamper with it.

In some cases, the attacker does not own the target product. The product is in active operation and may belong to a specific person (e.g., a mobile phone or smartcard), but the attacker may have physical access to the product. This is the most difficult type of attack because risk of detection is high.

In the final scenario, the attacker does not have access to the product, so all attacks are performed remotely (e.g., through a wired or wireless network). The attacker does not require special hardware tools and can easily mask his location. The risk of detection is low. Remote access attacks are common against computer networking equipment and appliances, such as routers, firewalls, access points, web servers, and storage area networks.

UNDERSTAND THE ATTACKER

“The only way to stop an attacker is to think like one.” That’s a favorite saying of mine. An FBI profiler tries to put himself in the mind of his subject. You must do the same when figuring out what, if any, security features you need to implement in our design. Today, because of advances in technology, the lower cost of products, and easy access to once-specialized tools, attacks against hardware are becoming more prevalent.

Attackers can be classified into three groups depending on their expected abilities and strengths: class I (clever outsiders), class II (knowledgeable insiders), and class III (funded organizations). This classification is essentially an industry standard for describing attackers in an academic fashion.[1]

Class I attackers are often extremely intelligent but might have insufficient knowledge of the system. They might have access to only moderately sophisticated equipment. They often try to take advantage of an existing weakness in the system rather than try to create one. Sometimes referred to as “script kiddies” in the computer security industry, these attackers run preprogrammed scripts to exploit known security vulnerabilities instead of finding their own.

Class II attackers have a substantial amount of specialized technical education and experience. They have a decent knowledge of the product or system, and often have highly sophisticated tools and instruments for analysis.

Class III attackers are teams of specialists with related and complementary skills backed by great funding. They are capable of performing in-depth system analysis, designing sophisticated attacks, and using the most advanced analysis tools. They may use Class II adversaries as part of the attack team.

Table 1 is comparison of each attacker class against available resources. The table may help to visualize the capabilities of the various attacker groups.

Table 1: Take a look at each attacker class compared to available resources. As you can see, each class has specific capabilities that will play a part in determining your product’s risk of attack.[2]

Table 1: Take a look at each attacker class compared to available resources. As you can see, each class has specific capabilities that will play a part in determining your product’s risk of attack.[2]

ADDING SECURITY

Security is a process, not a product. Security must be designed into your product during the conceptual design phase, and it should be considered for every portion of the design. It must be continually monitored and updated in order to have the maximum effect against attacks. Security can’t be added to a product and forgotten about. The product won’t remain secure forever.

Many times, an engineering change will be made to the product circuitry or firmware without a reevaluation of system security. Without a process in place to analyze changes throughout the design cycle, security that was properly implemented at the beginning of the design may become irrelevant by the time the product goes into production.

The primary concern is to incorporate risk analysis and security considerations into each step of your product’s development life cycle. Five principles, which are based on recommendations from the National Institute of Standards and Technology, serve as a good checklist. For more information, refer to “Engineering Principles for Information Technology Security (A Baseline for Achieving Security)” by G. Stoneburner et al. Let’s take a look at each one.

First, treat security as an integral part of your overall product design. It’s extremely difficult to implement security measures properly and successfully after a system has been developed.

Second, reduce risk to an acceptable level. Elimination of all risk is not cost-effective and likely impossible because nothing is 100% secure. A cost-benefit analysis should be conducted for each proposed secure hardware mechanism to ensure that it is performing its intended task at a desired cost.

Next, implement layered security. (Ensure no single point of failure.) Consider a layered approach of multiple security mechanisms to protect against a specific threat or to reduce overall vulnerability.

Fourth, minimize the system elements you’re relying on. Security measures include people, operations, and technology. The system should be designed so that a minimum number of elements need to be trusted in order to maintain protection. Put all your eggs in one basket by isolating all critical content in one secure area (physical or virtual) instead of having multiple secure areas throughout the design. This way, you can focus on properly securing and testing a single critical area of the product instead of numerous disparate areas.

Finally, don’t implement unnecessary security mechanisms. Every security mechanism should support one or more defined goals. Extra measures should not be implemented if they do not support a goal because they could add unneeded complexity to the system and are potential sources of additional vulnerabilities.

KEYS TO THE KINGDOM

Understanding and evaluating the risks and threats against your product is the first step toward a successful secure hardware design. There are many combinations of potential vulnerabilities, and it’s impossible to prevent against all of them. The good news is that vendors have recognized the need for embedded security, and we’re starting to see ICs and modules that reflect that. The more you can spread the word to your colleagues about making secure products, the safer all of us will be.

I’ve just started to scratch the surface of the embedded security topic. In a future article, I’ll take a no-nonsense look at a wide variety of practical secure hardware design solutions that you can implement in your product.


REFERENCES

[1] D.G. Abraham et al, “Transaction Security System,” IBM Systems Journal, vol. 30, no. 2, 1991, www.research.ibm.com/journal/sj/302/ibmsj3002G.pdf.

[2] P. Kocher, “Crypto Due Diligence,” RSA Conference 2000.

RESOURCES

C.P. Pfleeger, Security in Computing, 2nd ed., Prentice Hall, 2000.

G. Stoneburner et al., “Engineering Principles for Information Technology Security (A Baseline for Achieving Security),” NIST Special Publication 800-27, June 2001, csrc.nist.gov/publications/nistpubs/800-27/sp800-27.pdf.


AUTHOR

Joe Grand specializes in embedded system design, computer security research, and inventing new concepts and technologies. Joe holds a B.S.C.E. from Boston University. This article first appeared in Circuit Cellar 169, 2004.

Infineon Embedded Security Selected for Lenovo ThinkPad

Lenovo will use Infineon Technologies OPTIGA Trusted Platform Module (TPM) chips in the new ThinkPad notebooks in an effort to combat security risks. The OPTIGA TPM SLB 9670 chip is designed to increase the data security of laptops and tablet PCs. Sensitive data (e.g., security keys and passwords) can be stored in the TPM chip separately from the main processor.  Infineon - OPTIGA

According to Infineon, the company also supplies embedded security solutions other companies, including Microsoft, Hewlett Packard, and Samsung. The OPTIGA product family provides different levels of security for products as diverse as multiple-server IT infrastructures and MP3 players.

Source: Infineon

Embedded Security & IP Protection

Infineon Technologies’s new OPTIGA Trust E offers an easy-to-use solution for protecting manufacturers’ valuable IP in industrial automation equipment, medical systems, and more. Since encrypting software isn’t enough to product your systems, the OPTIGA Trust E offers enhanced authentication and secured storage of software codes and product data.Infineon OPTIGA-Trust-E

The OPTIGA Trust E’s features include:

  • Advanced pre-programmed security controller
  • Complete system integration support
  • Extended temperature range of -40° to +85 C
  • Standardized I²C interface
  • Small USON-10 footprint
  • Supports authentication of products that rely on the USB Type-C standard
  • The OPTIGA Trust E is already available in volume quantities.

Source: Infineon 

USB-to-FPGA Communications: A Case Study of the ChipWhisperer-Lite

Sending data from a computer to an FPGA is often required. This might be FPGA configuration data, register settings, or streaming data. An easy solution is to use a USB-connected microcontroller instead of a dedicated interface chip, which allows you to offload certain tasks into the microcontroller.

In Circuit Cellar 299 (June 2015), Colin O’Flynn writes:

Often your FPGA-based project will require computer communication and some housekeeping tasks. A popular solution is the use of a dedicated USB interface chip, and a soft-core processor in the FPGA for housekeeping tasks.

For an open-source hardware project I recently launched, I decided to use an external USB microcontroller instead of a dedicated interface chip. I suspect you’ll find a lot of useful design tidbits you can use for yourself—and, because it’s open source, getting details of my designs doesn’t involve industrial espionage!

The design is called the ChipWhisperer-Lite (see Photo 1). This device is a training aid for learning about side-channel power analysis of cryptographic implementations. Side-channel power analysis uses measurements of small power variations during execution of the cryptographic algorithms to break the implementation of the algorithm.

Photo 1: This shows the ChipWhisperer-Lite, which contains a Xilinx Spartan 6 LX9 FPGA and Atmel SAM3U2C microcontroller. The remaining circuitry involves the power supplies, ADC, analog processing, and a development device which the user programs with some cryptographic algorithm they are analyzing.

Photo 1: This shows the ChipWhisperer-Lite, which contains a Xilinx Spartan 6 LX9 FPGA and Atmel SAM3U2C microcontroller. The remaining circuitry involves the power supplies, ADC, analog processing, and a development device which the user programs with some cryptographic algorithm they are analyzing.

In a previous article, “Build a SoC Over Lunch” (Circuit Cellar 289, 2014), I made the case for using a soft-core processing in an FPGA. In this article I’ll play the devil’s advocate by arguing that using an external microcontroller is a better choice. Of course the truth lies somewhere in between: in this example, the requirement of having a high-speed USB interface makes an external microcontroller more cost-effective, but this won’t always be the case.

This article assumes you require computer communication as part of your design. There are many options for this. The easiest from a hardware perspective is to use a USB-Serial converter, and many projects use such a system. The downside is a fairly slow interface, and the requirement of designing a serial protocol.

A more advanced option is to use a USB adapter with a parallel interface, such as the FTDI FT2232H. These can achieve very high-speed data rates—basically up to the limit of the USB 2.0 interface. The downside of these options is that it still requires some protocol implemented on your FPGA for many applications, and it has limited extra features (such as if you need housekeeping tasks).

The solution I came to is the use of a USB microcontroller. They are widely available from most vendors with USB 2.0 high-speed (full 480 Mbps data rate) interfaces, and allow you to perform not only the USB interface, but the various housekeeping tasks that your system will require. The USB microcontroller will also likely be around the same price (or possibly cheaper) than the equivalent specialized interface chip.

When selecting a microcontroller, I recommend finding one with an external memory bus interface. This external memory bus is normally designed to allow you to map devices such as SRAM or DRAM into the memory space of the microcontroller. In our case we’ll actually be mapping FPGA registers into the microcontroller memory space, which means we don’t need any protocol for communication with the FPGA.

OflynnFig1fpga

Figure 1: This figure shows the basic connections used for memory-mapping the FPGA into the microcontroller memory space. Depending on your requirements, you can add some additional custom lines, such as a flag to indicate different FPGA register banks to use, as only a 9-bit address bus is used in this example.

I selected an Atmel SAM3U2C microcontroller, which has a USB 2.0 high-speed interface. This microcontroller is low-cost and available in TQFP package, which is convenient if you plan on hand assembling prototype boards. The connections between the FPGA and microcontroller are shown in Figure 1.

On the FPGA, it is easy to map this data bus into registers. This means that to configure some feature in the FPGA, you can just directly write into a register. Or if you are transferring data, you can read from or write to a block-RAM (BRAM) implemented in the FPGA.

Check out Colin’s ChipWhisperer-Lite KickStarter Video:

Editors’ Pick: A Review of Current Embedded Security Risks

In recent years, security in embedded systems design has become a major concern. Patrick Schaumont’s CC25 article looks at the current state of affairs through several examples. The included tips and suggestions will help you evaluate the security needs of your next embedded design.

When you’re secure, you’re protected from loss or danger. Electronic security—the state of security for electronic systems—is essential for us because we rely so much on electronic embedded systems in everyday life. Embedded control units, RFID payment systems, wireless keys, cell phones, and intellectual-property firmware are just a few examples where embedded security matters to us. System malfunctions or the malicious uses of such devices are guaranteed to harm us. Security requires stronger guarantees than reliability. When we implement a secure system, we’re assuming an adversary with bad intentions. We’re dealing with someone who’s intentionally trying to cause harm. This article emphasizes attacks rather than solutions. The objective is to give you a sense of the issues.schaumont

Defining Embedded Security

As design engineers, we want to know how to create secure designs. Unfortunately, it’s hard to define the properties that make a design secure. Indeed, being “secure” often means being able to guarantee what is not going to happen. For example: “The wireless door opener on my house cannot be duplicated without my explicit authorization” or “The remote update of this wireless modem will not brick it.” Designing a secure system means being able to tell what will be prevented rather than enabled. This makes the design problem unique.

There is, of course, a good amount of science to help us. Cryptologists have long analyzed the desirable features of secure systems, and they have defined security objectives such as confidentiality, privacy, authentication, signatures, and availability. They have defined cryptographic algorithms such as encryption and decryption, public-key and symmetric-key operations, one-way functions, and random-number generation. They have also created cryptographic protocols, which show how to use those cryptographic algorithms in order to meet the intended security objectives.

Cryptography is a good starting point for secure embedded design. But it is not enough. Secure embedded designs face two specific challenges that are unique to embedded implementation. The first is that, by definition, embedded systems are resource-constrained. For example, they may use an 8-bit microcontroller and 32 KB of flash memory. Or they may even have no microcontroller at all and simply consist of a passively powered RFID device. Such severe resource constraints imply that there are hardly any compute cycles available for security functions. The second challenge is that embedded systems have simple, accessible form factors. Once deployed in the field, they become easy to tamper with, and they are subject to attacks that cryptologists never thought of. Indeed, classic cryptography assumes a “black-box” principle: it assumes that crypto-devices are free from tampering. Clearly, when an attacker can desolder components or probe microcontroller pins, the black-box principle breaks down.

Embedded Security Attacks

Embedded security attacks come in all forms and types. Here I’ll detail a few examples of recent, successful cases. In each of them, the attackers used a different approach. Refer to the documents listed in the Resources section at the end of this essay for pointers to in-depth discussions.

Let’s begin with a classic case of cryptanalysis. Keeloq was a proprietary encryption algorithm used in remote keyless entry systems. The algorithm is used by many car manufacturers, including Chrysler, General Motors, and Toyota, to name a few. It has a 64-bit key, which means that randomly trying keys will lead to a key search space of 264 possibilities. That is at the edge of what is practical for an attacker. Even when trying 10 million keys per second, you’d still need thousands of years to try all the keys of a 64-bit cipher. However, in 2008, researchers in Leuven, Belgium, found a way to reduce the search space to 44 bits. Essentially, they found a mathematical weakness in the algorithm and a way to exploit it. A 44-bit search space is much smaller. At 10 million keys per second, it only takes 20 days to cover the search space—a lot more practical. Clearly, deciding the key length of a secure embedded system is a critical design decision! Too short, and any progress in cryptanalysis may compromise your system. Too long, and the design may be too slow, and too big for embedded implementation.

Attackers go further, as well, and tamper with the security protocol. In 2010, researchers from Cambridge, UK, demonstrated a hack on the “Chip and PIN” system, an embedded system for electronic payments. Chip and PIN is a system for electronic purchases. It is similar to a debit card, but it is based on a chip-card (a credit card with a built-in microprocessor). To make a purchase, the user inserts the chip-card in a merchant terminal and enters a PIN code. A correct PIN code will authorize purchases. The researchers found a flaw in the communication protocol between the merchant terminal and the chip-card. The terminal will authorize purchases if two conditions are met: when it has identified the chip-card and when it receives a “PIN-is-correct” message from this card. The researchers intercepted the messages between the terminal and the chip-card. They were then able to generate a “PIN-is-correct” message without an actual PIN verification taking place. The terminal—having identified the chip-card, and received a “PIN-is-correct” message—will now authorize purchases to the chip-card issuer (a bank). This type of attack, called a man-in-the-middle attack, was done with a hacked chip-card, an FPGA board, and a laptop. Equally important, it was demonstrated on a deployed, commercial system. In the Resources section of this article I list a nice demonstration video that appeared on the BBC’s Newsnight program.

One step beyond the man-in-the-middle attack, the attacker will actively analyze the implementation, typically starting with the cryptographic components of the design. A recent and important threat in this category is side-channel analysis (SCA). In SCA, an attacker observes the characteristics of a cryptographic implementation: its execution time, its power dissipation, and its electromagnetic patterns. By sampling these characteristics at high speed, the attacker is able to observe data-dependent variations. These variations are called side-channel leakage. SCA is the systematic analysis of side-channel leakage. Given sufficient measurements—say, a few hundred to a few thousands of measurements—SCA is able to extract cryptographic keys from a device. SCA is practical and efficient. For example, in the past two years, SCA has been used successfully to break FPGA bitstream encryption and Atmel CryptoMemory. Links to detailed information are in the Resources section of this essay.

If there’s one thing obvious from these examples, it is that perfect embedded security cannot exist. Attackers have a wide variety of techniques at their disposal, ranging from analysis to reverse engineering. When attackers get their hands on your embedded system, it is only a matter of time and sufficient eyeballs before someone finds a flaw and exploits it.

What Can You Do?

The examples above are just the tip of the iceberg, and may leave the impression of a cumbersome situation. As design engineers, we should understand what can and what cannot be done. If we understand the risks, we can create designs that give the best possible protection at a given level of complexity. Think about the following four observations before you start designing an embedded security implementation.

First, you have to understand the threats that you are facing. If you don’t have a threat model, it makes no sense to design a protection—there’s no threat! A threat model for an embedded system will specify what can attacker can and cannot do. Can she probe components? Control the power supply? Control the inputs of the design? The more precisely you specify the threats, the more robust your defenses will be. Realize that perfect security does not exist, so it doesn’t make sense to try to achieve it. Instead, focus on the threats you are willing to deal with.

Second, make a distinction between what you trust and what you cannot trust. In terms of building protections, you only need to worry about what you don’t trust. The boundary between what you trust and what you don’t trust is suitably called the trust boundary. While trust boundaries were originally logical boundaries in software systems, they also have a physical meaning in embedded context. For example, let’s say that you define the trust boundary to be at the chip-package level of a microcontroller. This implies that you’re assuming an attacker will get as close to the chip as the package pins, but not closer. With such a trust boundary, your defenses should focus on off-chip communication. If there’s nothing or no one to trust, then you’re in trouble. It’s not possible to build a secure solution without trust.

Third, security has a cost. You cannot get it for free. Security has a cost in resources and energy. In a resource-limited embedded system, this means that security will always be in competition with other system features in terms of resources. And because security is typically designed to prevent bad things from happening rather than to enable good things, it may be a difficult trade-off. In feature-rich consumer devices, security may not be a feature for which a customer is willing to pay extra.

The fourth observation, and maybe the most important one, is to realize is that you’re not alone. There are many things to learn from conferences, books, and magazines. Don’t invent your own security. Adapt standards and proven techniques. Learn about the experiences of other designers. The following examples are good starting points for learning about current concerns and issues in embedded security.

Three Books for Your Desk

Security is a complex field with many different dimensions. I find it very helpful to have several reference works close by to help me navigate the steps of building any type of security service. The following three books describe the basics of information security and systems security. While not specifically targeted at the embedded context alone, the concepts they explain are equally valid for it as well.

Christof Paar and Jan Pelzl’s Understanding Cryptography: A Textbook for Students and Practitioners gives an overview of basic cryptographic algorithms. The authors explain the different types of encryption algorithms (stream and block ciphers, as well as various standards). They describe the use of public-key cryptography, covering RSA and elliptic curve cryptography (ECC), and their use for digital signatures. And they discuss hash algorithms and message authentication codes. The book does not cover cryptographic protocols, apart from key agreement. A nice thing about the book is that you can find online lectures for each chapter.

Niels Ferguson, Bruce Schneier, and Tadayoshi Kohno’s Cryptography Engineering: Design Principles and Practical Applications covers basic cryptography as well, but with a slightly different emphasis as the first. It takes a more practical approach and frequently refers to existing practice in cryptography. It has sections on (software-oriented) implementation issues and practical implementation of key agreement protocols. This book would give immediate value to the practicing engineer—although it does not connect to the embedded context as well as the previous book. For example, it does not mention ECC.

Ross Anderson’s Security Engineering is a bible on secure systems design. It’s very broad. It builds up from basic cryptography over protocols up to secure systems design for telecoms, networking, copyright control, and more. It’s an excellent book on the systems perspective of secure design. The first edition of this book can be downloaded for free from the author’s website, though it’s well worth the investment to have the latest edition on your desk.

Four Sites

Many websites cover product teardowns and the specific security features of these implementations. Flylogic’s Analytics Blog (www.flylogic.net/blog/) describes the analysis of various chipcards. It contains chip micrographs and discusses various techniques to reverse-engineer chip security features. The website is an excellent showcase of what’s possible for a knowledgeable individual; it also clearly illustrates the point that perfect security cannot exist.

If you would like to venture in analysis of secure embedded designs yourself, then the Embedded Analysis wiki by Nathan Fain and Vadik is a must read (http://events.ccc.de/congress/2010/wiki/Embedded_Analysis). They discuss various reverse-engineering tools to help you monitor a serial line, extract the image of a flash memory, and analyze the JTAG interface of an unknown component. They also cover reverse-engineering practice in an online talk, which I’ll mention below.

Earlier I noted that cost is an important element in the security design. If you’re using cryptography, then this will cost you compute cycles, digital gates, and memory footprint. There are a few websites that give an excellent overview of these implementation costs for various algorithms.

The EBACS website contains a benchmark for cryptographic software, covering hash functions, various block and stream ciphers, and public-key implementations (http://bench.cr.yp.to/supercop.html). Originally designed for benchmarking on personal computers, it now also includes benchmarks for ARM-based embedded platforms. You can also download the benchmarks for a wealth of reference implementations of cryptographic algorithms. The Athena website at GMU presents a similar benchmark, but it’s aimed at cryptographic hardware (http://cryptography.gmu.edu/athena/). It currently concentrates on hash algorithms (in part due to its development for the SHA-3 competition). You can apply the toolkit to other types of cryptographic benchmarking as well. The website provides a host of hardware reference implementations for hash algorithms. It also distributes the benchmarking software, which is fully automated on top of existing FPGA design flows from Altera and Xilinx.

Three Newsletters

Security is a fast-evolving field. You can remain up to date on the latest developments by subscribing to a few newsletters. Here are three newsletters that have never failed to make a few interesting points to me. They do not exclusively focus on secure embedded implementations, but frequently mention the use of embedded technology in the context of a larger security issue.

The ACM RISKS list (http://catless.ncl.ac.uk/Risks) enumerates cases of typical security failures, many of them related to embedded systems. Some of the stories point out what can happen if we trust our embedded computers too blindly, such as GPS systems that lead people astray and stranded. Other stories discuss security implications of embedded computers, such as the recent news that 24% of medical device recalls are related to software failures.

Bruce Schneier’s “Schneier on Security” blog and Crypto-Gram newsletter (www.schneier.com/crypto-gram.html) focus on recent ongoing security issues. He covers everything from the issues with using airport scanners to the latest hack on BMW’s remote keyless entry system.

The Technicolor Security Newsletter (www.technicolor.com/en/hi/technology/research-publications/security-newsletters/security-newsletter-20) discusses contemporary security issues related to computer graphics, content protection, rights management, and more. The newsletter gives succinct, clear descriptions of content protection (and attacks on it) for mobile platforms, game machines, set-top boxes, and more.

Three Web Presentations

You can also learn from watching presentations by security professionals. Here are three interesting ones that specifically address security in embedded devices.

In a talk titled “Lessons Learned from Four Years of Implementation Attacks Against Real-World Targets,” Christof Paar covers the use of side-channel analysis (SCA) to break the security of various embedded devices, including wireless keys, encrypted FPGA bitstreams, and RFID smartcards. The talk is an excellent illustration of what can be achieved with SCA.

Nathan Fain gave a talk called “JTAG/Serial/Flash/PCB Embedded Reverse Engineering Tools and Technique” at a recent conference. The author discusses various tools for analyzing embedded systems. It’s the live version of the wiki page listed earlier. Go to his website (www.deadhacker.com) to download the tools he discusses.

Finally, in a talk titled “Comprehensive Experimental Analyses of Automotive Attack Surfaces,” Stephen Checkoway discusses the embedded security analysis of cars. The author demonstrates how an attacker is able to access a car’s internal network, a concept called “the attack surface.” He points out several known issues, such as the risks posed by the on-board diagnostics (ODB) port. But he also demonstrates a wide variety of additional access points, from CD to long-range wireless links. Each of these access points comes with specific risks, such as remote unlocking of doors and unauthorized tracking. It’s a fascinating discussion that demonstrates how the ubiquitous microcontroller has brought safety as well as risk to our cars.

Looking Forward

Security in embedded systems design requires a designer to think about ways in which bad things are prevented from happening. We have seen a great deal of progress in our understanding of the threats to embedded systems. However, it’s clear that there is no silver bullet. The threats are extremely diverse, and eventually it’s up to the designer to decide what to protect. In this article, I provided a collection of pointers that should help you learn more about these threats.—By Patrick Schaumont (Patrick is an associate professor at Virginia Tech, where he works with students on research projects relating to embedded security. Patrick has covered a variety of embedded security-related topics for Circuit Cellar: one-time passwords, electronic signatures for firmware updates, and hardware-accelerated encryption.)

RESOURCES

R. Anderson, Security Engineering, Second Edition, Wiley Publishing, Indianapolis, IN, 2008.

J. Balasch, B. Gierlichs, R. Verdult, L. Batina, and I. Verbauwhede, “Power Analysis of Atmel CryptoMemory — Recovering Keys from Secure EEPROMs.” In O. Dunkelman (ed.), Topics in Cryptology — CT-RSA 2012, The Cryptographer’s Track at the RSA Conference, Lecture Notes in Computer Science 7178, O. Dunkelman (ed.), Springer-Verlag, 2012.

BBC Newsnight, “Chip and PIN is Broken,” www.youtube.com/watch?v=1pMuV2o4Lrw.

D. Bernstein and T. Lange, “EBACS: ECRYPT Benchmarking of Cryptographic Systems,”

http://bench.cr.yp.to/supercop.html.

E. Biham, O. Dunkelman, S. Indesteege, N. Keller, and B. Preneel, “How to Steal Cars—A Practical Attack on Keeloq,” COSIC, www.cosic.esat.kuleuven.be/keeloq/.

S. Checkoway, “Comprehensive Experimental Analyses of Automotive Attack Surfaces,” www.youtube.com/watch?v=bHfOziIwXic.

E. Diels, “Technicolor Security Newsletter,” www.technicolor.com/en/hi/technology/research-publications/security-newsletters/security-newsletter-20.

N. Fain and Vadik, “Embedded Analysis,”

http://events.ccc.de/congress/2010/wiki/Embedded_Analysis.

———, “JTAG/Serial/Flash/PCB Embedded Reverse Engineering Tools and Technique,” www.youtube.comwatch?v=8Unisnu-cNo.

N. Ferguson, B. Schneier, and T. Kohno, Cryptography Engineering, Wiley Publishing, Indianapolis, IN, 2010.

Flylogic’s Analytics Blog, www.flylogic.net/blog/.

K. Gaj and J. Kaps, “ATHENa: Automated Tool for Hardware Evaluation,” Cryptographic Engineering Research Group, George Mason University, Fairfax, VA, http://cryptography.gmu.edu/athena/.

A. Moradi, A. Barenghi, T. Kasper, and C. Paar, “On the Vulnerability of FPGA Bitstream Encryption Against Power Analysis Attacks,” IACR ePrint Archive, 2011, http://eprint.iacr.org/2011/390.

S. Murdoch, S. Drimer, R. Anderson, and M. Bond, “Chip and PIN is Broken,” 2010 IEEE Symposium on Security and Privacy, www.cl.cam.ac.uk/~sjm217/papers/oakland10chipbroken.pdf.

P. Neumann (moderator), “The Risks Digest: Forum on Risks to the Public in Computers and Related Systesm,” ACM Committee on Computers and Public Policy, http://catless.ncl.ac.uk/Risks.

C. Paar, “Lessons Learned from Four Years of Implementation Attacks Against Real-World Targets,” Seminar at the Isaac Newton Institute for Mathematical Sciences, 2012.

C. Paar and J. Pelzl, Understanding Cryptography, Springer-Verlag, 2010, www.crypto-textbook.com.

B. Schneier, “Crypto-gram Newsletter,” www.schneier.com/crypto-gram.html.

This article first appeared in CC25.

 

 

Security Agents for Embedded Intrusion Detection

Knowingly or unknowingly, we interact with hundreds of networked-embedded devices in our day-to-day lives such as mobile devices, electronic households, medical equipment, automobiles, media players, and many more. This increased dependence of our lives on the networked-embedded devices, nevertheless, has raised serious security concerns. In the past, security of embedded systems was not a major concern as these systems were a stand-alone network that contained only trusted devices with little or no communication to the external world. One could execute an attack only with a direct physical or local access to the internal embedded network or to the device. Today, however, almost every embedded device is connected to other devices or the external world (e.g., the Cloud) for advanced monitoring and management capabilities. On one hand, enabling networking capabilities paves the way for a smarter world that we currently live in, while on the other hand, the same capability raises severe security concerns in embedded devices. Recent attacks on embedded device product portfolios in the Black Hat and Defcon conferences has identified remote exploit vulnerabilities (e.g., an adversary who exploits the remote connectivity of embedded devices to launch attacks such as privacy leakage, malware insertion, and denial of service) as one of the major attack vectors. A handful of research efforts along the lines of traditional security defenses have been proposed to enhance the security posture of these networked devices. These solutions, however, do not entirely solve the problem and we therefore argue the need for a light weight intrusion-defense capability within the embedded device.

In particular, we observe that the networking capability of embedded devices can indeed be leveraged to provide an in-home secure proxy server that monitors all the network traffic to and from the devices. The proxy server will act as a gateway performing policy based operations on all the traffic to and from the interconnected embedded devices inside the household. In order to do so, the proxy server will implement an agent based computing model where each embedded device is required to run a light weight checker agent that periodically reports the device status back to the server; the server verifies the operation integrity and signals back the device to perform its normal functionality. A similar approach is proposed Ang Cui and Salvatore J. Stolfo’s 2011 paper, “Defending Embedded Systems with Software Symbiotes,” where a piece of software called Symbiote is injected into the device’s firmware that uses a secure checksum-based approach to detect any malicious intrusions into the device.

In contrast to Symbiote, we exploit lightweight checker agents at devices that merely forward device status to the server and all the related heavy computations are offloaded to the proxy server, which in turn proves our approach computationally efficient. Alternatively, the proposed model incurs a very small computational overhead in gathering and reporting critical device status messages to the server. Also, the communication overhead can be amortized under most circumstances as the sensor data from the checker agents can be piggybacked to the original data messages being transferred between the device and the server. Our model, as what’s described in the aforementioned Cui and Stolfo paper, can be easily integrated with legacy embedded devices as the only modification required to the legacy devices is a “firmware upgrade that includes checker agents.”

To complete the picture, we propose an additional layer of security for modern embedded devices by designing an AuditBox, as in the article, “Pillarbox,” by K. Bowers, C. Hart, A. Juels, and N. Triandopoulos. It keeps an obfuscated log of malicious events taking place at the device which are reported back to the server at predefined time intervals. This enables our server to act accordingly by either revoking the device from the network or by restoring it to a safe state. AuditBox will enforce integrity by being able to verify whether the logs at the device have been tampered with by an adversary who is in control of the device and covertness by hiding from an attacker with access to the device whether the log reports detection of malicious behavior. To realize these requirements, AuditBox will exploit the concept of forward secure key generation.

Embedded systems security is of crucial importance and the need of the hour. Along with the advancement in embedded systems technology, we need to put an equal emphasis on its security in order for our world to be truly a smarter place.

RESOURCES
K. Bowers, C. Hart, A. Juels, & N. Triandopoulos, “Pillarbox: Combating Next-Generation Malware with Fast Forward-Secure Logging,” in Research in Attacks, Intrusions and Defenses, ser. Lecture Notes in Computer Science, A. Stavrou, H. Bos, and G. Portokalidis (Eds.), Springer, 2014, http://dx.doi.org/10.1007/978-3-319-11379-1_3.

A. Cui & S. J. Stolfo, “Defending embedded systems with software symbiotes,” in Proceedings of the 14th international conference on Recent Advances in Intrusion Detection (RAID’11), R. Sommer, D. Balzarotti, and G. Maier (Eds.), Springer-Verlag, 2011, http://dx.doi.org/10.1007/978-3-642-23644-0_19.

DevuDr. Devu Manikantan Shila is the Principal Investigator for Cyber Security area within the Embedded Systems and Networks Group at the United Technologies Research Center (UTRC).

 

Marten van DijkMarten van Dijk is an Associate Professor of Electrical and Computing Engineering at the University of Connecticut, with over 10 years research experience in system security both in academia and industry.

 

Syed Kamran HaiderSyed Kamran Haider is pursuing a PhD in Computer Engineering supervised by Marten van Dijk at the University of Connecticut.

 

This essay appears in Circuit Cellar 297 (April 2015).

Embedded Security (EE Tip #139)

Embedded security is one of the most important topics in our industry. You could build an amazing microcontroller-based design, but if it is vulnerable to attack, it could become useless or even a liability.  EmbeddSecurity

Virginia Tech professor Patrick Schaumont explains, “perfect embedded security cannot exist. Attackers have a wide variety of techniques at their disposal, ranging from analysis to reverse engineering. When attackers get their hands on your embedded system, it is only a matter of time and sufficient eyeballs before someone finds a flaw and exploits it.”

So, what can you do? In CC25, Patrick Schaumont provided some tips:

As design engineers, we should understand what can and what cannot be done. If we understand the risks, we can create designs that give the best possible protection at a given level of complexity. Think about the following four observations before you start designing an embedded security implementation.

First, you have to understand the threats that you are facing. If you don’t have a threat model, it makes no sense to design a protection—there’s no threat! A threat model for an embedded system will specify what can attacker can and cannot do. Can she probe components? Control the power supply? Control the inputs of the design? The more precisely you specify the threats, the more robust your defenses will be. Realize that perfect security does not exist, so it doesn’t make sense to try to achieve it. Instead, focus on the threats you are willing to deal with.

Second, make a distinction between what you trust and what you cannot trust. In terms of building protections, you only need to worry about what you don’t trust. The boundary between what you trust and what you don’t trust is suitably called the trust boundary. While trust boundaries were originally logical boundaries in software systems, they also have a physical meaning in embedded context. For example, let’s say that you define the trust boundary to be at the chip package level of a microcontroller.

This implies that you’re assuming an attacker will get as close to the chip as the package pins, but not closer. With such a trust boundary, your defenses should focus on off-chip communication. If there’s nothing or no one to trust, then you’re in trouble. It’s not possible to build a secure solution without trust.

Third, security has a cost. You cannot get it for free. Security has a cost in resources and energy. In a resource-limited embedded system, this means that security will always be in competition with other system features in terms of resources. And because security is typically designed to prevent bad things from happening rather than to enable good things, it may be a difficult trade-off. In feature-rich consumer devices, security may not be a feature for which a customer is willing to pay extra. The fourth observation, and maybe the most important one, is to realize is that you’re not alone. There are many things to learn from conferences, books, and magazines. Don’t invent your own security. Adapt standards and proven techniques. Learn about the experiences of other designers. The following examples are good starting points for learning about current concerns and issues in embedded security.

Security is a complex field with many different dimensions. I find it very helpful to have several reference works close by to help me navigate the steps of building any type of security service.

Schaumont suggested the following useful resources:

Embedded Security Tips (CC 25th Anniversary Preview)

Every few days we you a sneak peek at some of the exciting content that will run in Circuit Cellar‘s Anniversary issue, which is scheduled to be available in early 2013. You’ve read about Ed Nisley’s essay on his most memorable designs—from a hand-held scanner project to an Arduino-based NiMH cell tester—and Robert Lacoste’s tips for preventing embedded design errors. Now it’s time for another preview.

Many engineers know they are building electronic systems for use in dangerous times. They must plan for both hardware and software attacks, which makes embedded security a hot topic for 2013.  In an essay on embedded security risks, Virginia Tech professor Patrick Schaumont looks at the current state of affairs through several examples. His tips and suggestions will help you evaluate the security needs of your next embedded design.

Schaumont writes:

As design engineers, we should understand what can and what cannot be done. If we understand the risks, we can create designs that give the best possible protection at a given level of complexity. Think about the following four observations before you start designing an embedded security implementation.

First, you have to understand the threats that you are facing. If you don’t have a threat model, it makes no sense to design a protection—there’s no threat! A threat model for an embedded system will specify what can attacker can and cannot do. Can she probe components? Control the power supply? Control the inputs of the design? The more precisely you specify the threats, the more robust your defenses will be. Realize that perfect security does not exist, so it doesn’t make sense to try to achieve it. Instead, focus on the threats you are willing to deal with.

Second, make a distinction between what you trust and what you cannot trust. In terms of building protections, you only need to worry about what you don’t trust. The boundary between what you trust and what you don’t trust is suitably called the trust boundary. While trust boundaries where originally logical boundaries in software systems, they also have a physical meaning in embedded context. For example, let’s say that you define the trust boundary to be at the chip-package level of a microcontroller. This implies that you’re assuming an attacker will get as close to the chip as the package pins, but not closer. With such a trust boundary, your defenses should focus on off-chip communication. If there’s nothing or no one to trust, then you’re in trouble. It’s not possible to build a secure solution without trust.

Third, security has a cost. You cannot get it for free. Security has a cost in resources and energy. In a resource-limited embedded system, this means that security will always be in competition with other system features in terms of resources. And because security is typically designed to prevent bad things from happening rather than to enable good things, it may be a difficult trade-off. In feature-rich consumer devices, security may not be a feature for which a customer is willing to pay extra.

The fourth observation, and maybe the most important one, is to realize is that you’re not alone. There are many things to learn from conferences, books, and magazines. Don’t invent your own security. Adapt standards and proven Circuit Cellar’s Circuit Cellar 25th Anniversary Issue will be available in early 2013. Stay tuned for more updates on the issue’s content.techniques. Learn about the experiences of other designers.

Schaumont then provides lists of helpful embedded security-related resources, such as Flylogic’s Analytics Blog and the Athena website at GMU.