Help with your IoT Security

IoT security vulnerabilities can put users at risk and damage companies’ reputations, and these risks increase as more devices are connected to the internet. Download
“How to Choose the Right Coding Standard for Embedded Software Security” to learn how to choose and enforce the best coding standard for your IoT application to reduce these risks.

Coding standards are proven to improve code quality, but without automation they are difficult to enforce and may be ignored by developers. Download this white paper to learn how to create a coding standard from existing resources and use a static analyzer to ensure it is followed by your developers.
Automating Coding Standards

Security vulnerabilities can put users at risk and damage companies’ reputations, and these risks increase as more devices are connected to the internet. Download this white paper to learn how to choose and enforce the best coding standard for your application to reduce these risks.
How to Choose the Right Coding Standard for Embedded Software Security 


Free white papers: How to Choose the Right Coding Standard for Embedded Software Security and Automating Coding Standards sponsored by PRQA

To get your white papers fill in the form below.

Automating_coding_standards_thumb             How_to_choose_codingstandard_thumb




Coding Standards and Security

Coding standards are proven to improve code quality, but without automation they are difficult to enforce and may be ignored by developers. Download this white paper to learn how to create a coding standard from existing resources and use a static analyzer to ensure it is followed by your developers.
Automating Coding Standards

Security vulnerabilities can put users at risk and damage companies’ reputations, and these risks increase as more devices are connected to the internet. Download this white paper to learn how to choose and enforce the best coding standard for your application to reduce these risks.
How to Choose the Right Coding Standard for Embedded Software Security 


Free white papers: How to Choose the Right Coding Standard for Embedded Software Security and Automating Coding Standards sponsored by PRQA

To get your white papers fill in the form below.

Automating_coding_standards_thumb             How_to_choose_codingstandard_thumb




The Future of IoT Security

By Haydn Povey

Unlimited opportunity. That’s what comes to mind when I think about the future of the Internet of Things (IoT). And, that is both a blessing and a curse.

As the IoT proliferates, billions of cloud-connected devices are expected to be designed, manufactured, and deployed over the next decade. Our increasingly connected world will become hyper-connected, transforming our lives in ways we likely never thought possible. We will see smarter cities where the commuter is automatically guided, smarter farming where livestock health is individually monitored with on-call veterinary services, smarter healthcare to reduce the spiraling costs, integration between smart white goods and utilities to manage grid loading, and the integration of smart retail and personal assistant AI to provide a “curated” shopping experience. That future is limitless and exciting. But it is also frightening. We have already seen the headlines of how attacks have impacted businesses and people with valuable data being stolen or ransomed. It is widely believed the attacks are just starting.

Devices—not often seen as likely hacking targets—now have the potential to be weaponized. No one wants a device or application that is prone to hacking or theft. Hacks, malware, and IP theft have a significant dollar cost and can destroy corporate brands and reputations. And these devices may have extended lifecycles of decades. And a “secure” connected device does not guarantee a secure system. All too often, security has been an after-thought in the development of systems.

Hardware, software, communications, and communications protocol, device commissioning, applications layers, and other systems considerations all could impact security of a device and its data. The future of IoT must see security become an integral part of the design and deployment process, not merely an after-thought or add-on.

Delivering security-orientated embedded systems is a major challenge today. It will take a strong ecosystem and the development of a “supply chain of trust” to deliver truly secure product creation, deployment, and lifecycle management for the rapidly evolving IoT marketplace.

Security needs to be architected into devices from the moment of inception. In addition, it needs to be extended across the supply chain, from security-orientated chips through to manufacturing and management for the lifecycle of the product.

To deliver secure manufacturing and ensure no malware can be injected, cold and hard cryptography principles must be relied upon to ensure solutions are secured. Security principles should be embedded in every aspect of the system from the delivery of secure foundations in the silicon device, through to the secure mastering and encryption of the OEM codebase to ensure it is protected. The programming and manufacturing stages may then freely handle the encrypted code base, but the utilization of secure appliances, which integrate high-integrity and high-availability hardware security modules, enables secure enclaves to be integrated into the process to manage and orchestrate all key material. Furthermore, the ability to encrypt applications within the development process and subsequently decrypt the images in place within the device is a critical to securing the intellectual property.

While simple in theory, there are multiple aspects of a system that must be secured, encompassing the device, the mastering of the application, the handling and sharing of the keys, and the loading of the application on to the device. The only real solution is to develop a “zero trust” approach across the supply chain to minimize vulnerabilities and continually authenticate and individualize deliverables as far as possible.

While this integrated approach cannot resolve all aspects of counterfeiting, it does mark a key rallying point for the industry, and finally enables the industry to start to draw a line under the mass counterfeiting and over-production of devices. And all stakeholders in the process—including device platform providers, OEMs, programming centers, contract manufacturers, end users, security experts, and standards bodies—must do their parts to make cyber-secure programming and manufacturing ubiquitous, easy to use, and easily adoptable.

As I said, the future of IoT holds limitless opportunity, and that will drive new solutions. There will be new business models and new ecosystems. The threats are real, and the cost of failure could be astronomical. So, for the future of IoT to be bright, it must start with security.

This article appears in Circuit Cellar 324.

Haydn Povey [Headshot - Colour]Haydn Povey is the Founder/CEO of Secure Thingz, a company focused on developing and delivering next-generation security technology into the Internet of Things (IoT) and other connected systems. He also currently sits on the Executive Steering Board of the IoT Security Foundation. Haydn has been in senior management at leading global technology companies for more than 20 years, including 10 years in senior marketing and business development roles at ARM.

vSound Violin Digital Processor

Saelig Company recently introduced the Cambrionix ThunderSync16, which provides 16 USB2.0 ports and a Thunderbolt host connection capable of transfer speeds of up to 20 Gbps to allow large data transfer in the shortest possible time. For data syncing requirements, the Thunderbolt’s data transfer speed delivers a greatly increased data transfer rate between a host Thunderbolt connection and 16 attached devices than a USB2.0 connection.

vSound Violin Digital Processor
The ThunderSync 16’s features, specs, and benefits:

  • Speeds up situations needing large data transfer (e.g., video file uploading or operating system updates) when the data is required to be loaded in the fastest possible time.
  • Supports universal, intelligent charging of USB ports at up to 2.4 A simultaneously.
  • It can be daisy-chained via the dual Thunderbolt ports.
  • Allows for the charging of multiple device types simultaneously (e.g., mobile phones, MP3 players, e-readers, etc.)
  • Preprogrammed Very Intelligent Charging protocol ensures the correct charging profile is used for the specific product, maintaining battery performance and extending battery life
  • Operates with the complementary Cambrionix LiveView app
  • Supplied software displays the charging status in detail.
  • An API is also provided for software automation scripting, essential for software QA and mobile phone remarketing companies.

The ThunderSync 16 is well suited for industrial, defense, security, software QA, and wearable camera applications requiring large-scale charging and data transfer. It is powered by an internal universal power supply, and is Intel Certified, CE Marked, UL Listed, and EMC FCC tested

Saelig Company | www.saelig.com

Renesas New R9J02G012 Controller Enables Device-to-Device Authentication in Support of Safer USB Power Delivery Ecosystem

Renesas Electronics announced its new R9J02G012 USB Power Delivery (USB PD) controller intended for use in a wide range of USB Power Delivery products employing direct current (DC) power including AC adapters, PCs, smartphones, other consumer and office equipment, and toys. The new R9J02G012 supports both USB Power Delivery Rev. 3.0 (USB PD 3.0) and USB Type-C Authentication Rev 1.0, which enables device-to-device authentication.

The demand for fast charging mobile devices is growing, driving increased demand for high DC power delivery (e.g. 100W). Previously, system manufacturers frequently implemented proprietary fast-charging methods using USB Micro-B connectors. However, with recent smartphone charging/battery incidents, it is critical to offer a safe ecosystem of USB PD compatible products. The USB Implementers Forum (USB-IF), an industry-leading technology consortium, has standardized the following specifications to provide open, unified and interoperable technologies to fulfill these market needs:

1) USB Type-C Rev 1.2 Specification: For simpler, easier physical connection of cables, chargers and devices

2) USB Power Delivery Rev 3.0 Specification: For higher power delivery protocols with additional performance, safety and upgradability features like PD firmware update

3) USB Type-C Authentication Rev 1.0 Specification: For device-to-device authentication allowing system manufacturers to implement additional charging policies for trusted high-power charging over USB Type-C

As a long-time supporting member and a board member for USB Implementers Forum, Renesas has adopted all three standards. The new R9J02G012, introduced during Computex Taipei 2017, is a flexible, small-package USB PD controller for USB Type-C port control on any USB PD devices. All connecting ports to these USB PD devices with the R9J02G012 will be able to electronically verify and trust its authenticity based on the certificates and public key infrastructure (PKI) defined in the USB Type-C Authentication specification. This mechanism allows system manufacturers to implement policies to examine the genuine origin of the connected PD devices such as cables and chargers before a high-power charging of (e.g., 20V at 3A) is executed.

The R9J02G012 integrates support for the USB PD 3.0 and USB Type-C Authentication standards in a single package, where previously each required a separate chip. It is available in an easy-to-mount QFN package as well as the more compact BGA package, reducing the mounting area in cables or electronic devices. The board mounting area is less than 50 percent the area required when using the existing Renesas R9A02G011.

The R9J02G012 also supports the Power Delivery Firmware Update (PDFU) Specification, Revision 1.0. This optional PD feature is an open standard enabling firmware updates of the device via a USB Type-C cable.

Samples of the R9A02G011 are available from June 2017. Mass production is scheduled to begin in the beginning of January 2018. Renesas plans to expand its range of reference designs for applications such as USB Type-C power banks and mobile batteries by combining the R9J02G012 with power products from Renesas and Intersil Corporation, which was acquired by Renesas in February 2017. With the introduction of the R9J02G012, system manufacturers can easily construct a trusted power charging ecosystem of USB PD products based on the USB PD and USB Type-C Authentication standards.
renesas.com

Embedded Software: Tips & Insights (Sponsor: PRQA)

When it comes to embedded software, security matters. Read the following whitepapers to learn about: securing your embedded systems, MISRA coding standard, and using static analysis to overcome the challenges of reusing code.

  • Developing Secure Embedded Software
  • Guide to MISRA Coding
  • Using Static Analysis to Overcome the Challenges of Reusing Code for Embedded Software

VISIT THE DOWNLOAD PAGE

Programming Research Ltd (PRQA) helps its customers to develop high-quality embedded source code—software which is impervious to attack and executes as intended.

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.

Industrial IoT Reference Design for Fast Development

Intended to address security concerns in Industrial Internet of Things (IIoT) systems, Maxim Integrated Products’s MAXREFDES143# embedded security reference design enables you to protect your designs against counterfeit sensor data. Intended to simplify the development of secure, authenticated sensor-to-web data, the design is well suited for analog sensor node and data authentication in a variety of applications, including factory automation and industrial processing.Maxim MAXREFDES143

The reference design features a two-stage hierarchical architecture, an Arduino-compatible hardware interface, and ARM mbed libraries. The architecture consists of a shield that communicates to a web server and a protected sensor node for data acquisition and authentication. The shield comprises the following:

  • Wi-Fi module
  • Maxim Integrated Products DS2465 secure coprocessor for offloading SHA-256 cryptographic computation
  • 1-Wire and I2C interfaces
  • User-interface LCD, LEDs, and pushbuttons
  • Alarm and logging functions.

The sensor node comprises:

  • Maxim Integrated Products DS28E15 secure authenticator
  • DS7505 temperature sensor
  • MAX44009 light sensor.

The MAXREFDES143# IoT embedded security reference design is available for $75. Free hardware and firmware design files are posted online.

Source: Maxim Integrated Products

Live Webinar on Security for the Connected Car

Recent automobile hacks (e.g., the Chrysler Jeep hack) have many engineers focusing on security in the connected car. Mentor Graphics will focus on this topic in a live webinar on August 10.

The webinar will be led by Alan Grau, President and co-founder of Icon Labs, and Andrew Patterson, Business Development Director for Mentor Graphics’s embedded division. The webinar will address:

  • Automotive cybersecurity requirements
  • Secure architectures for automotive
  • Security throughout the car and beyond (IVI, ADAS, and Gateway ECUs to small constrained ECUs)
  • Secure software updates
  • Emerging automotive cybersecurity standards
  • And more

The webinar will take place on August 10 from 10:00 AM – 11:00 AM (US/pacific). Register Now

Source: Mentor Graphics

The Future of IoT Security: One Size Doesn’t Fit All

Security is one of the hot topics today in the Internet of Things (IoT). There have been well-publicized security breaches of consumer devices that include hijacked video from wireless baby monitors being posted on the Internet and home automation systems that reveal whether a home is occupied or not. A number of systems have been breached just to demonstrate their vulnerabilities. Less well publicized are security breaches of industrial equipment with much more severe consequences. These are rarely made public for obvious reasons.

At first glance, it would seem that the existing security mechanism for the Internet and corporate networks would be an easy solution for IoT security. There are several problems with this. First, IoT applications only require security that is “good enough” for the specific application. Just like you don’t need razor wire and guard towers to keep your dog in the yard and don’t want to rely on a four foot yard fence to keep the prisoners in a maximum security prison, the level of security for an IoT product needs to be based on the needs of the application (often basic privacy rather than real security).

Consider data encryption for network transfers as an example of why existing security mechanisms generally do not work well for the IoT. Encryption standards typically target applications that require extremely high levels of security such as financial transactions and military or national security communications. These encryption standards are severe overkill for most IoT applications and present significant problems for small, battery-powered IoT devices. An encryption algorithm may require upwards of 4 KB of code space, which is as much or more than many otherwise suitable microcontrollers might have. Many encryption standards rely on multiple rounds of encryption. The time it takes to perform the encryption could be several times longer on a small micro than the time it takes the micro to perform its main tasks. Most common encryption standards rely on 16- to 32-byte keys to help ensure data security. For many IoT devices, these key lengths could increase the length of their network messages by a factor of 4× to 8× or more. The execution time and added network traffic can quickly chew-up precious battery capacity, increasing the size and cost of a product. The extremely high level of security provided by these encryption algorithms is what drives the large code size, long execution times, and high message overhead that makes them inappropriate for most IoT applications. Hardware encryption addresses the code size and execution time issues but still suffers from high message overhead.

 

The other major problem with using existing security mechanisms is IoT developers typically don’t have network security experience. There is a certain mindset and expertise required to develop IoT products and a completely different mindset and expertise required to be a security expert. The time required to develop these security mechanisms in-house could take several times longer than the basic product development. Several companies have recognized this problem and have recently introduced security framework products to be incorporated into IoT devices. True end-to-end security requires much more than just passwords and data encryption, and these framework products address other needs like key management and protection against common network attacks. These security frameworks may well be the future of IoT security, but to be widely adopted, they have to be right-sized for IoT devices.

When selecting the wireless technology to use in an IoT product, things like distance, bandwidth, cost, and physical size have to be considered. Words and phrases like “streamlined” and “light weight” need to be kept in mind when assessing security solutions for IoT products. A feature-rich security framework product might be appealing, but many IoT devices provide simple functions and don’t need a plethora of features. They also can’t afford the memory space and execution time overhead (and power consumption) imposed by these unneeded features. Whether future IoT products are based on a security framework or in-house developed security, there will not be a one-size-fits-all solution. Security for successful IoT products will be right-sized for the hardware resources available and the needs of the application.

Mike Lease is a hardware/firmware engineer with more than 30 years of product development experience, mostly in embedded products. He developed a number of battery-powered, wirelessly connected devices before “IoT” became a common buzzword, and several more since then. Mike enjoys taking on tough challenges and has recently developed a fascination with generating random numbers. In 2013 he founded CMicrotek (www.cmicrotek.com) to develop a family of ultra-low current measurement products primarily for developers of battery-powered products. Mike recently launched LSE Technologies, a provider of lightweight stream encryption software for M2M and IoT applications.

Produced in Spain: Startup for Hardware Security Solutions

When you talk about a startup, you likely envision bearded hipsters drinking fancy coffee at their expensive Macs. But not all startups are cut from the same cloth. Consider the following case. We recently met with a small team of talented long-time engineers in Madrid that is swimming against the tide. After working for many years in the electronics design industry, the engineers now innovating secure hardware products at a startup with big ideas and lofty goals.

The Future of IoT Security

With the onset of Internet of Things (IoT) technology, an enormous number of devices are now accessible via the Internet and are therefore vulnerable to cyberattack. Society is still adjusting to the fact that devices that people used to trust can now betray them in unexpected ways. Your television may expose your conversations, your printer may divulge your documents, and your fitness monitor may reveal your health information. All of these attacks become possible in the presence of IoT devices which are not designed with security in mind. System designers are trained to evaluate system design options in terms of their impact on system characteristics such as power, performance, and time-to-market, but security is a property which is less well understood. Designers of IoT devices need to have the ability to consider, both qualitatively and quantitatively, how design alternatives affect the security of the system. To do that, designers must understand the essential aspects of common cyberattacks.

The nature of cyberattacks is broad and ever-changing as attackers alter their techniques over time. However, there are a number of attack themes which are fundamental to many cyberattacks and change only infrequently. Designers need to understand these important attack themes and how to defend against them. A good example is a vulnerability to a buffer overflow attack which is usually a result of weak coding practices, such as neglecting to verify that the amount of data written into a buffer is not greater than the size of the buffer. Defense against buffer overflow can likely be achieved through static code analysis and proper testing techniques, without the need to include any security components in the IoT device.

Another attack against IoT devices is a battery draining attack which consumes power by exploiting features of the network communication protocol being used by the device. Different protocols, and their interface controllers, have different degrees of vulnerability to such attacks, and the system designer needs to be aware of this when selecting a communication protocol.

This essay appears in Circuit Cellar 309, April 2016. Subscribe to Circuit Cellar to read project articles, essays, interviews, and tutorials every month!

 
Defending against some attacks will require the use of software and hardware components which are dedicated to security-related tasks. Such components incur overheads which must be considered by the designer. A common example is whether or not to use encryption, what type of encryption, and whether that encryption should be implemented in hardware or software. Besides the power and cost trade-offs involved, the designer will need to be able to estimate how well each type of encryption protects the system from, for example, a man-in-the-middle attack which intercepts communications with other devices.

IoT security is clearly an important design property which must be considered by designers who understand the complexities of cybersecurity. A problem for the field of IoT is that there is a shortage of IoT designers who understand cybersecurity. There is a range of possible solutions to address the shortage problem which vary based on who takes responsibility to find a solution. One alternative is education or training to ensure that designers are aware of the complexities of the security problem and can address them during the design process. Individual IoT designers may take responsibility for their own training, which means that the designer will individually seek out learning materials and possibly courses. As a professor I feel that individuals should always take responsibility for their own education, but in practice this is difficult and may not consistently result in the best outcome for all concerned. An individual who is not familiar with security will have a hard time determining what is important to learn and what is not, so they may waste time and money on education with no real value. In my role as Vice Chair of Undergraduate Studies, I am frequently asked about what a student needs to learn to be productive in industry, but if an individual cannot find an appropriate mentor to provide them with some direction, then their attempts at education may not be fruitful.

Another alternative is to place the responsibility for the development of secure IoT devices on the companies which employ the designers and sell the IoT devices. For this to happen, company managers must first accept that security costs money and that security is worth some expenditure. As long as security is seen as an overhead with no direct financial benefit, industry is not be motivated to make the necessary changes to build secure systems. Too often, security is largely ignored until a successful cyberattack against a company is publicized and the company suffers in terms of reputation and possible lawsuits. Industry needs to accept the importance of security upfront to avoid the more significant costs of dealing with successful attacks.

Companies can take several different approaches to ensuring security including guaranteeing that their designers are appropriately knowledgeable about IoT security. A salary premium for security experts could motivate employees to take responsibility for their own security education. In-house corporate training can be provided to employees whose job responsibilities necessitate an understanding of security. Employers can outsource and pay for education at local or online schools. When a project is particularly security-sensitive requiring more expertise than is available internally, a contractor with the appropriate security expertise can be brought in. All of these options incur different costs which would need to be justified by the need for security in the market where the IoT devices will be used.

Eventually, a mixture of these approaches should be employed to achieve the best, and most secure, results. Individual designers need to make every effort to learn about security issues, and employers need to motivate them with appropriate salaries and facilitate their efforts by providing opportunities for education. The lack of security of current IoT devices has been used as an argument against their adoption, but there seems to be no stopping the growing use of the IoT. At the same time, cyberattacks are also growing in number, sophistication, and financial impact. Security needs to be a first-class design consideration for IoT systems, on par with cost, power, and the other constraints that embedded designers have always dealt with.

Associate Professor Ian G. Harris earned a BS in Computer Science at MIT and MS and PhD degrees in Computer Science from the University of California San Diego. He is currently Vice Chair of Undergraduate Education in the Computer Science Department at the University of California Irvine. His research group focuses on the security and verification of Internet of Things systems. He also teaches an IoT specialization entitled “An Introduction to Programming the Internet of Things.”

OPTIGA Trusted Platform Modules Enhance Security for Connected Devices

Microsoft currently uses Infineon Technologies OPTIGA Trusted Platform Modules (TPMs) in its newest personal computing devices, including the Surface Pro 4 tablet and the Surface Book. The dedicated security chips store sensitive data, including keys, certificates, and passwords and keeps them separated from the main processor, which further secures the system from unauthorized access, manipulation, and data theft. For example, the Microsoft BitLocker Drive Encryption application’s key and password are stored in the TPM.Infineon-OPTIGA

Microsoft’s personal computing devices rely on the OPTIGA TPM SLB 9665, which is the first certified security controller based on TPM 2.0. This standard was defined by the Trusted Computing Group (TCG).

Source: Infineon Technologies

Bare Metal Security Extends On-Chip Analytics for SoCs

UltraSoC recently announced Bare Metal Security capabilities to extend its on-chip monitoring and analytics to deliver security functionality required in a broad range of embedded products (e.g., IoT appliances and enterprise systems). Bare Metal Security features are implemented as hardware running below the operating system, so they’re nonintrusive even if the system’s conventional security measures are compromised. This adds an entirely new level of protection for the system-on-chip (SoC).

Bare Metal Security functionality uses the UltraSoC monitors to watch for unexpected behaviors such as suspicious memory accesses or processor activity, at hardware speed and nonintrusively, with minimal silicon overhead. Because it is an orthogonal on-chip hardware infrastructure independent of the main system functionality and software, there is no negative impact on system performance and it is very difficult for an attacker to subvert or tamper with. Although it functions below and outside of the operating system, the technology also provides a means of communicating with software on the device as part of a holistic security system, if this is necessary. Bare-Metal Security features also provide visibility of the whole system, making it extremely difficult to camouflage or hide an attack.

By offering resource-efficient and highly effective protection against malicious attack and malfunction, the UltraSoC on-chip analytics and monitoring system provides both development support and functionality enhancement from the same on-chip blocks. Teams already using UltraSoC to accelerate the debug, silicon validation, and bring-up process can use the same infrastructure for security processing. Designers who need Bare Metal Security features get the development benefits of a vendor-independent on-chip debug infrastructure at zero additional cost.

Although originally developed for debug and silicon validation, UltraSoC’s IP also enables a broad range of value-added functionality in-service, of which security is just one example. Other applications include in-field monitoring, performance optimization, reducing power utilization and SLA enforcement.

Source: UltraSoC Technologies

New Arria 10 Boards Target Cyber/Security, SigInt, & Acceleration

BittWare recently announced two new boards in its Altera Arria 10 FPGA product roadmap to complement their existing Arria 10 3U VPX and PCIe offerings: A10PED and A10XM4.

The A10PED Dual Arria 10 PCIe full-length Gen3 x16 Card supporting either the 660 or 1150 KLE size FPGAs (GX), with one supporting an optional SoC (SX) with dual ARM. Primarily targeting signal and network packet processing applications the board provides 28 lanes of serial I/O up to 10.325 Gbps each, with support for high-accuracy time stamping. Featuring 4x 260-pin DDR4 SODIMMs and a Hybrid Memory Cube (HMC), the A10PED will support up to 68 GB of memory with a peak aggregate memory bandwidth of over 175 GB/sec (not including I/O or PCIe). For latency-sensitive applications, some or all of the DDR4 SODIMMs can be replaced with proprietary QDR-II/IV SRAM SODIMMs. These memory options, coupled with full support for Altera’s OpenCL tools, also make this board compelling for acceleration & co-processing applications.

The A10XM4 Arria 10 XMC (VITA 42) Module provides network interface (NIC) and cyber/security capabilities in addition to host/carrier acceleration for applications in radar, EW, networking, and SigInt. In addition, it will support full conduction cooling. Compatible with any standard XMC carrier, the A10XM4 features an Arria 10 GX FPGA with two lanes of 10 GigE, along with up to 16 GB of memory and PCIe Gen3 x8 PCIe to the host. BittWare’s NIC application example and OpenCL BSP will greatly simplify the integration and development of cyber/security additions to and off-loading of standard host applications.

The A10PED full length PCIe board will be available Q4 2015 and the A10XM4 XMC board will be available Q1 2016.  Contact BittWare for configurations, pricing, and details.

Source: BittWare