India - Flag India

Please confirm your currency selection:

Indian Rupee
Incoterms:FCA (Shipping Point)
Duty, customs fees and taxes are collected at time of delivery.
Payment accepted in Credit cards only

US Dollars
Incoterms:FCA (Shipping Point)
Duty, customs fees and taxes are collected at time of delivery.
All payment options available

Bench Talk for Design Engineers

Bench Talk

rss

Bench Talk for Design Engineers | The Official Blog of Mouser Electronics


When Design Engineers Meet Security Concerns Clive  Maxfield

(Source: Cq photo juy/Shutterstock.com)

In the late 1960s and early 1970s, when the seeds of what we now know as the internet were first planted in the form of the Advanced Research Projects Agency Network (ARPANET), little if any thought was given to security. It was initially assumed that all nodes and access terminals would be located on military bases and would therefore be secure. It seems no one considered the possibility of spies also being located on the bases or of nefarious players worming their way into the systems through remote terminals.

Gaping holes in this philosophy became apparent as an increasing number of educational institutions and scientific establishments plugged into the network, but few people in authority appeared to be aware of the problem. In 1989, Clifford Stoll published The Cuckoo’s Egg: Tracking a Spy Through the Maze of Computer Espionage, which was the author’s first-person account of the hunt for a computer hacker who broke into a computer at the Lawrence Berkeley National Laboratory (LBNL) in Berkeley, Calif.

As part of his investigation, Clifford discovered that the hacker was also penetrating military and government systems, but he found it difficult to persuade anyone in authority that there was anything to worry about, including the Federal Bureau of Investigation (FBI), the Central Intelligence Agency (CIA), the National Security Agency (NSA), and the United States Air Force Office of Special Investigations (AFOSI).

Today, we have a similar situation in which people seem indifferent about ever-increasing security concerns that present challenges for design engineers, who must design sophisticated systems that keep security at the forefront. Here, we will explore some of the challenges and solutions, as well as the impact that the Internet of Things (IoT) has on the development of these designs.

Challenges of Designing Advanced Secure Systems

Design engineers already have so much to do in capturing the magic that differentiates their products from their competitors’ offerings that they have little time to think about security. Security is complicated, and engineers, being human, can be tempted to take the path of least resistance.

All of this is starting to change as security breaches are becoming common and widely reported. People in charge of factories, medical, educational, and financial institutions are becoming more concerned about the possible outcomes resulting from a security breach. Also, the general public is becoming increasingly aware of how security, or the lack thereof, can affect them—like someone gaining remote access to a smart video camera—such as a baby monitor or security camera—or a smart assistant—such as Amazon Echo or Google Home—or a smart thermostat or any number of IoT devices. These issues also put pressure on the people who develop today’s sophisticated systems—such as system architects, hardware design engineers, embedded software engineers, and application software developers. These people are tasked with creating systems with security in mind.

Security has so many layers and ramifications that it can make one’s head spin. Let’s start with people who are designing silicon chips such as System-on-Chip (SoC) devices. In addition to the home-grown portions of the device, these designs almost invariably include large numbers of intellectual property (IP) blocks from third-party vendors. Each of these IP blocks can be more complex than an entire computer of yesteryear. So how can designers and system architects possibly be assured the blocks don’t contain hidden or shadow functionality?

Issue of Counterfeit Chips

Next, there is the problem of counterfeit chips, which come in various flavors:

  • Compatible Chips: Someone builds a component that mimics the function of the authentic chip
     
  • Reconditioned Chips: Someone harvests components from electronic waste using crude and poorly controlled processes
     
  • Gray Market Chips: Can originate from overbuilds, reworked failures, or reclaims from retired systems
     
  • Reverse-Engineered Chips (a.k.a. “Rogue Chips”): An adversary deconstructs a chip and re-creates a new version of the device, which can include additional functionality to corrupt data, cause a malfunction, or—most sinister of all—exfiltrate data

Foundation of a Secure System

When it comes to creating the system itself, four fundamental elements form the foundation of a secure system:

  1. Hardware-based isolation: In the not-so-distant past, embedded systems were architected in a way that any software module could see and access the entire memory map. This is no longer considered to be a good idea. Hardware-based isolation has multiple flavors, including the microcontroller supporting secure and non-secure environments coupled with the use of memory protection units (MPUs), but the core concept is to split applications across multiple security domains that restrict access on a need-to-know basis.
     
  2. A Root-of-Trust (RoT): A RoT involves the combination of base-level hardware and minimal associated software that is able to successfully authenticate itself and facilitate secure operations in the rest of the system.
     
  3. A secure boot solution: The next step is to employ a secure boot solution, which refers to the process of using a RoT to validate the authenticity and validity of any code as it is loaded into the system.
     
  4. A secure bootloader: Next up is the secure bootloader, which extends the scope of the RoT and secure boot solution by preventing reverse engineering on the firmware, preventing unauthorized modification of the firmware, preventing the loading of unauthorized firmware on an authorized device, and preventing the loading of authorized firmware on an unauthorized device.

Suppose the system includes a module or a motherboard from another supplier. How do you know that there aren’t hidden devices included on the board, perhaps mounted underneath authentic parts?

Conclusion

Any security concerns one might have are exacerbated when it comes to the Internet of Things, in which billions of devices are connected to each other and to the cloud via a mindboggling array of wired and wireless solutions. This requires software developers to work with their hardware designer and cloud solution counterparts to perform encryption and decryption on-the-fly, and to generate certificates, and to authenticate everything so that the devices know they are communicating with trusted hosts and the host systems know they are communicating with trusted devices. Yes, setting up the security for these systems can get complicated very fast and what engineers need is the assurance that the hardware they are working with contains authentic OEM silicon.



« Back


Clive "Max" Maxfield

Clive "Max" Maxfield is a freelance technical consultant and writer. Max received his BSc in Control Engineering in 1980 from Sheffield Hallam University, England and began his career as a designer of central processing units (CPUs) for mainframe computers. Over the years, Max has designed everything from silicon chips to circuit boards and from brainwave amplifiers to Steampunk Prognostication Engines (don't ask). He has also been at the forefront of Electronic Design Automation (EDA) for more than 35 years.

Well-known throughout the embedded, electronics, semiconductor, and EDA industries, Max has presented papers at numerous technical conferences around the world, including North and South America, Europe, India, China, Korea, and Taiwan. He has given keynote presentations at the PCB West conference in the USA and the FPGA Forum in Norway. He's also been invited to give guest lectures at several universities in the USA, Sheffield Hallam University in the UK, and Oslo University in Norway. In 2001, Max "shared the stage" at a conference in Hawaii with former Speaker of the House, "Newt" Gingrich.

Max is the author and/or co-author of a number of books, including Designus Maximus Unleashed (banned in Alabama), Bebop to the Boolean Boogie (An Unconventional Guide to Electronics), EDA: Where Electronics Begins, FPGAs: Instant Access, and How Computers Do Math.


All Authors

Show More Show More
View Blogs by Date