Comments on: Is embedded security necessary? http://www.embeddedinsights.com/channels/2011/02/16/is-embedded-security-necessary/ Shedding Light on the Hidden World of Embedded Systems Mon, 28 Jul 2014 16:18:37 -0400 hourly 1 http://wordpress.org/?v=3.0 By: Gaurav Agarwal, TI http://www.embeddedinsights.com/channels/2011/02/16/is-embedded-security-necessary/#comment-5588 Gaurav Agarwal, TI Fri, 18 Feb 2011 14:49:07 +0000 http://www.embeddedinsights.com/channels/?p=450#comment-5588 As more and more embedded devices in the consumer space are getting attached to the network and many of these devices are without sophisticated security support, I see a real threat. Imagine a set-top box (or a video game console or a TV) connected to the network. And someone with the desire to cause physical harm corrupts the application stored on the flash. Next time the power cycle is needed, the device won't start. The device now has to be sent back to the manufacturing facility or would need a visit from a technician. What if, instead of corrupting the code, the application is carefully changed to run specific functionalities that can cause more harm on the other systems in the network in the vicinity or sniff on important personal data from other systems. Doing this on embedded systems is relatively difficult as compared to a PC. However, with increasing popularity of embedded systems, the expertise about these systems is becoming widespread. I believe that this threat will become more prominent in this decade. A two tier security (Hardware + Software) should be used to provide proper defense mechanisms against these threats. With the life cycle of more than just a couple of years, these embedded systems will need more security than just the effort for someone to understand these systems. If you are an embedded system designer, now is the time... As more and more embedded devices in the consumer space are getting attached to the network and many of these devices are without sophisticated security support, I see a real threat.

Imagine a set-top box (or a video game console or a TV) connected to the network. And someone with the desire to cause physical harm corrupts the application stored on the flash. Next time the power cycle is needed, the device won’t start. The device now has to be sent back to the manufacturing facility or would need a visit from a technician. What if, instead of corrupting the code, the application is carefully changed to run specific functionalities that can cause more harm on the other systems in the network in the vicinity or sniff on important personal data from other systems. Doing this on embedded systems is relatively difficult as compared to a PC. However, with increasing popularity of embedded systems, the expertise about these systems is becoming widespread.

I believe that this threat will become more prominent in this decade. A two tier security (Hardware + Software) should be used to provide proper defense mechanisms against these threats.

With the life cycle of more than just a couple of years, these embedded systems will need more security than just the effort for someone to understand these systems. If you are an embedded system designer, now is the time…

]]> By: tz http://www.embeddedinsights.com/channels/2011/02/16/is-embedded-security-necessary/#comment-5577 tz Thu, 17 Feb 2011 21:40:01 +0000 http://www.embeddedinsights.com/channels/?p=450#comment-5577 It is worse than that. There have been lawsuits over breathalyzers (which can declare you guilty and send you to jail) where the vendor didn't want to reveal the source, and when it was eventually analyzed was shown to be buggy. Or the tire pressure monitors - which are inherently wireless - can be spoofed to the point it can shut down a car. The first problem is you really need to analyze the actual threats, and then meet them. Embedded device has a wide meaning (remembering the Naval ships that were literally dead in the water because of an NT bug but most people don't consider windows to be an embedded system). The motorola 6809 that had an (invalid) instruction that would destroy the chip (radio shack color computer). Most of what I first think of when hearing the term embedded devices are running from read-only flash (as opposed to something like an SD card). The firmware can be updated, but not partially. This limits the exploits. They typically are behind routers (NAT) and initiate connections so it is difficult to do an exploit. Not impossible, but again what is the threat. Could you zap the device by uploading a bad firmware image? Can you hack the firmware to make it open to exploits?... So the short answer, is probably, "Yes" - security is important, but only in the same sense that any quality or safety problem should be considered. It is worse than that. There have been lawsuits over breathalyzers (which can declare you guilty and send you to jail) where the vendor didn’t want to reveal the source, and when it was eventually analyzed was shown to be buggy.

Or the tire pressure monitors – which are inherently wireless – can be spoofed to the point it can shut down a car.

The first problem is you really need to analyze the actual threats, and then meet them. Embedded device has a wide meaning (remembering the Naval ships that were literally dead in the water because of an NT bug but most people don’t consider windows to be an embedded system).

The motorola 6809 that had an (invalid) instruction that would destroy the chip (radio shack color computer).

Most of what I first think of when hearing the term embedded devices are running from read-only flash (as opposed to something like an SD card). The firmware can be updated, but not partially. This limits the exploits. They typically are behind routers (NAT) and initiate connections so it is difficult to do an exploit. Not impossible, but again what is the threat. Could you zap the device by uploading a bad firmware image? Can you hack the firmware to make it open to exploits?…

So the short answer, is probably, “Yes” – security is important, but only in the same sense that any quality or safety problem should be considered.

]]> By: Jon Titus http://www.embeddedinsights.com/channels/2011/02/16/is-embedded-security-necessary/#comment-5573 Jon Titus Thu, 17 Feb 2011 15:42:57 +0000 http://www.embeddedinsights.com/channels/?p=450#comment-5573 Everyone I know has a locks on the doors to their home. Who's responsible, the builder or the home-owner? First, the owner has responsibility for his or her property, so they should maintain the locks, ensure they work, and change the key once in a while. Technology changes and locks get easier to pick. Maybe a fingerprint-detector lock next year? Second, the builder has a responsibility to install the locks and perhaps even deadbolts before it turns over the home to a new owner. Third, when the home buyer sells the property, the new owner must take responsibility for changing the locks. So I say add at least a minimum level of security to embedded systems and let the the buyers add on higher levels of security or disable them as they wish. (Add on security could get specified at the time of purchase or added later. That's up to the buyer.) Upon delivery, unless specified otherwise, the owner assumes responsibility. Everyone I know has a locks on the doors to their home. Who’s responsible, the builder or the home-owner? First, the owner has responsibility for his or her property, so they should maintain the locks, ensure they work, and change the key once in a while. Technology changes and locks get easier to pick. Maybe a fingerprint-detector lock next year? Second, the builder has a responsibility to install the locks and perhaps even deadbolts before it turns over the home to a new owner. Third, when the home buyer sells the property, the new owner must take responsibility for changing the locks. So I say add at least a minimum level of security to embedded systems and let the the buyers add on higher levels of security or disable them as they wish. (Add on security could get specified at the time of purchase or added later. That’s up to the buyer.) Upon delivery, unless specified otherwise, the owner assumes responsibility.

]]>