Embedded Security: Top Ten Myths
by Mukesh Lulla, TeamF1
Perhaps no other area of embedded technology gets as much visibility today as security. After all, if .connectivity. of modern embedded systems was the wave of the last decade, it.s no surprise that .secure connectivity. is becoming an almost inescapable requirement as networks come of age. The prevalence of wireless, remote management, storage, and mobile technologies has reinforced the urgency of this requirement and sparked renewed interest in not just protection of data-in-transit, but also data-at-rest.
State of the Onion
As prolific as the exhortations to protect embedded devices are, the current state of security in many embedded applications still hovers somewhere between confused complacency and intimidated inaction.
.Security is a multi-dimensional problem., insist some pundits while others claim, .simplicity is the key to practical security.. .Think of security as an onion with layers and layers of defenses., more experts chime in. .Layers serve as obfuscation and give you an illusion of security., retort the critics. Confusion hath now made his masterpiece!
While the high priests of security duke it out and management, sniffing the fumes of unrealistic end-customer demands, wants nothing short of an absolute guarantee of security, we engineers are frequently left to sort out what is and what is not feasible. When it comes to security, conventional wisdom just isn.t!
Hit or Myth
Muddying the waters further are some widely held misconceptions. We cannot resolve the apparent contradictions surrounding the best practices for secure devices without first clearing this fog, so we.ll start by dispelling ten of the more egregious myths surrounding this subject:
- Myth #10 : We aren.t the likely target of an attack
This is the most pernicious myth of all and takes various forms: .The data on/from my device is useless to others, ergo I don.t need any security.. Or, .who would ever want to spend the effort to hack my system?.. But with the proliferation of easily accessible hacking tools, advanced crackers aren.t all you need to worry about-a whole army of kiddie-script writer wannabes is waiting for their 15 minutes of fame.
- Myth #9 : My embedded system.s security has never been broken, so it.s all we need
Sure, that.s like saying: .I intend to live forever – so far, so good.. Enough said!
- Myth #8 : My device is password .protected.
Well, password protection at least implies awareness of a requirement for security. However, passwords are usually sent over a network in clear-text and are easily captured by packet sniffers on intermediate network nodes. In most cases, they provide only a deceptive veneer of security. If the password scheme protects remote management or access to the device, an attacker could potentially gain complete control of the device with impunity. Even if passwords were sent over a secure channel, they may still be susceptible to dictionary attacks.
- Myth #7 : Security protocol XYZ is the silver bullet
Once convinced that real security is needed, many users start looking for a quick fix believing that some single well-known security protocol is all that their device needs. One common manifestation: .My device has a firewall, so I don.t need to worry about security threats.. Such delusions of adequacy may blind one to serious vulnerabilities in the system such as lack of protection for network data.
- Myth #6 : Two security protocols are better than one
This is only a half-myth, but is so frequently abused that it deserves attention. Belief that there is no one panacea for security convinces some to take it to the next logical step-back up the truck and load up on it. After all, more security can.t be worse than less security. But what.s forgotten in this exquisite distillation of logic is that security is weakest at the seams, so adding multiple security layers to an embedded device without thinking it through is like putting three dead-bolts on a door whose door jamb is not anchored to the wall. Security should be a strategy, not a bunch of protocols.
- Myth # 5 : Security is the same as encryption
This myth and its corollary-.cryptography is the same as encryption.-are byproducts of buzzword hype. Certainly, encryption is a cornerstone of information security, but consider this fallacy: what if an encrypted (and thus, confidential) connection goes not to the entity you expected to communicate with, but to an unauthorized one? In other words, you may have a completely secure channel, so no one else can listen in to your conversation with. an attacker! Security needs to include authentication (identity verification), integrity (tamper-resistance), and various other techniques to thwart attacks. These are typically based on cryptographic operations, which include but are not limited to encryption.
- Myth #4: More .bits. mean stronger security
Yet another fallacy related to encryption is that more .bits. of encryption mean higher security strength. However, like all data, the impact of the .bits. (usually key-size or block-size of encryption algorithms) only depends on the application that uses it-in this case, the encryption algorithm. Assuming that 256-bit RC-4 is stronger than 128-bit AES encryption is like comparing apples to oranges, not to speak of the watermelons that elbow their way in when 1024-bit public-keys (RSA, DSA) are thrown into the equation.
- Myth # 3 : Security will get in the way of my application
Security is a subject that turns many embedded developers off. The resource requirements (code size, memory usage, CPU .horsepower.) for cryptography are often formidable by embedded standards. Even if that were reconciled, developers often think that security detracts from their productivity by making things difficult. However, a well-designed security solution that leverages hardware / software optimally, and provides a common framework to secure different aspects of an embedded application can be less intrusive than one may imagine.
- Myth #2 : I can do it better
Embedded development frequently revolves around the efficiency of solutions developed in-house because .No one understands my systems as well as I do.. Security protocols, in particular, are viewed as laden with more baggage than a Samsonite factory, so some developers concoct small-footprint, lightweight implementations without the .bells and whistles.. If this is done without a full understanding of why a protocol required it, the bell or whistle that was left out might spell the difference between strong and weak security, and worse, may not be exposed until it.s too late.
- Myth # 1 : A proprietary implementation is more secure than an open one
It is a human tendency to equate secrecy with protection of sensitive information and this reasoning has been used to promote some really arcane security implementations. However, if secrets extend beyond the realm of replaceable secret keys to the use of secret methods and implementations, this can be a major cause of brittleness. .Security by obscurity. flies in the face of good security practices. Core security-especially the security protocol and cryptography-should be based on code available for public review. This ensures a deeper analysis of any vulnerabilities than would be possible with any single company.s proprietary code which claims compactness and is written partially in .high-performance. assembly that looks like line noise, just so that .no one can break into it..
Deconstructing Security
Achieving strong security is indeed a multi-dimensional problem, but the key is to architect the system using a cohesive approach to security, rather than stitching together a solution from various pieces-remember, the seams are always the most vulnerable. Inadvertent vulnerabilities resulting from the use of a well-designed crypto algorithm in an application it was never intended for, may be worse than choosing a weaker algorithm and knowing the consequences upfront. The .layers-of-onion. model of security can provide defense in depth, but only if the layers are standard components put together in a consistent manner so as to complement each other.
It is important to recognize the different facets of the embedded security problem first and make sure all relevant ones are considered in the solution. One way to divide the security requirements of an embedded system is to analyze three areas:
Data Security-security of raw data residing on the device e.g. configuration files, statistics, or even databases.
System Security-security of the embedded device as a networked node, or security of the perimeter of a network of devices.
Network Security-security of the data moving between a device and other systems.
Of course, a heavy-gauge steel box welded shut is a very secure container indeed, but not a very useful one. So it is important to remember that a secure system does need to allow access to AUTHORIZED users. This ties in to the concept of identity or more specifically, proving that an entity is who it purports to be-Authentication, which is another important dimension of security that needs to be analyzed.
An embedded device that integrates these elements of security in a seamless manner and complements them with consistent system-wide security policies would be a truly secure device, not just one believed to be secure. After all, while optimism has its place in the world, it has no business being a part of your device.s security strategy.