I recently had an unpleasant experience related to online security issues. Somehow my account information for a large online game had been compromised. The speed in which the automated systems detected that the account had been hacked into and locked it down is a testament to how many compromised accounts this particular service provider handles on a daily basis. Likewise, the account status was restored with equally impressive turn-around time.
What impacted me the most about this experience was realizing that there is obviously at least one way that malicious entities can compromise a password protected system despite significant precautions to prevent such a thing from occurring. Keeping the account name and password secret; employing software to detect and protect against viruses, Trojan horses, or key loggers; as well as ensuring that data between my computer and the service provider is encrypted was not enough to keep the account safe.
The service provider’s efficiency and matter-of-fact approach to handling this situation suggests there are known ways to circumvent the security measures. The service provider offers and suggests using an additional layer of security by using single-use passwords from a device they sell for a few bucks and charge nothing for shipping.
As more embedded systems support online connectivity, the opportunity for someone to break into those systems increases. The motivations for breaking into these systems are myriad. Sometimes, such as in the case of my account that was hacked, there is the opportunity for financial gain. In other cases, there is notoriety for demonstrating that a system has vulnerability. In yet other cases, there may be the desire to cause physical harm, and it is this type of motivation that begs this week’s question.
When I first started working with computers in a professional manner, I found out there were ways to damage equipment through software. The most surprising example involved making a large line printer destroy itself by sending a particular sequence of characters to the printer such that it would cause all of the carriage hammers to repeatedly strike the ribbon at the same time. By spacing the sequence of characters with blank lines, a print job could actually make a printer that weighed several hundred pounds start rocking back and forth. If the printer was permitted to continue this behavior, mechanical parts could be severely damaged.
It is theoretically possible to perform analogous types of things with industrial equipment, and with more systems connected to remote or public networks, the opportunities for such mischief are real. Set top boxes that are attached to televisions are connecting to the network – offering a path for mischief if the designers of the set top box and/or television unintentionally left an opening in the system for someone to exploit.
Is considering the security implications in an embedded design needed? Where is the line between when implementing embedded security is important versus when it is a waste of resources? Are the criteria for when embedded security is needed based on the end device or on the system that such device operates within? Who should be responsible for making that call?
Tags: Risk Management
Processor Tracker
All Entries RSS Feed
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.
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.
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…