The thing about passwords is that their whole purpose is to provide security. But passwords are hardly secure themselves, as we all know now due to the recent string of breaches… Once passwords get out into the clear, it’s like Christmas for cyber-criminals. So what we need are secure passwords… obviously.
Passwords are big fat target for hackers. The fact that Target stores were the “target” of hackers it is almost poetic. Heartbleed is another dangerous example of private information being bleeding out into the open. An unsecured password is sort of like leaving your keys in the car on the street in a really bad neighborhood. In cyber-city, where all of us now live, every neighborhood is really bad. So, what can you do? Why not try to embed some hardware security to protect passwords? In fact, it’s rather easy to do with hardware key storage devices like Atmel CryptoAuthentication. Hardware key storage devices lock up the password and keep it from getting out of the system where it is entered, such as from a computer or ATM keyboard. In such an example, the only things that get transmitted between the keyboard and the authorizing system are cryptographic information; Specifically, what is transmitted is a random number from the crypto device to the keyboard system and cryptotographically processed response in the opposite direction. Let’s take a closer look at the details via the video below.
The platform here is a keyboard entry device on one side and the secure key storage device (in this case the ATSHA204A) on the other. The input could be from a smartphone or other things as well. The password is securely stored in the protected hardware memory which protects against hackers reading it. The secure memory is in the ATSHA204A device. When the password is entered into the keyboard, it automatically tells the remote device with the secure memory chip to send a random number challenge to the keyboard machine. The keyboard machine hashes the random number with the password that was just entered to create a digest using a cryptographic algorithm (e.g. SHA256). That digest is called the “response” (meaning the response to the challenge that was sent over). That response is then sent to the ATSHA204A for comparison to a calculation using the same random number and the stored password on the ATSHA204A. If the response and the hash on the ATSHA204A are the same, the password was correct (real) and the operation of the device connected to the keyboard is therefore allowed.
As you can see, the value of this operation is that a the only places the password go are into the system connected to the keyboard (the local system) and the secure, protected.
Benefits of secure password protection:
Easy to implement
Secret storage is completely secure
Password is never in the clear
Several Passwords can be stored in the ATSHA204A (up to 16 slots)
Atmel CryptoAuthentication™ products, such as ATSHA204A, ATECC108A and ATAES132, implement hardware-based storage, which is much stronger then software-based due to the defense mechanisms that only hardware can provide against attacks. Secure storage in hardware beats storage in software every time. Adding secure key storage is an inexpensive, easy, and ultra-secure way to protect firmware, software, and hardware products from cloning, counterfeiting, hacking, and other malicious threats.
What platform has become the most sophisticated and intimate personal electronic environment ever? The car. To paraphrase a famous automotive company’s top executive, car companies are transforming the car into a powerful smartphone that allows drivers to carry around, customize, and interact with their digital world. Automotive electronics are currently centered around people (infotainment and communications) and the machine itself (to run the car and provide safety and convenience). Now a third element is emerging; namely, Vehicle-to-Vehicle (V2V) communications.
Just like that sounds, cars will soon “talk and listen” to one another — automatically. They will share information like proximity, speed, direction, road conditions, as well as other things that have yet to been imagined. The chief driver of V2V is signaling impending collisions so that the cars can automatically take countermeasures. That, of course, means the V2V network will become a critical technology for self- and assisted-driving cars.
While it may seem revolutionary, V2V is really an evolutionary branch of Internet of Things (IoT) technologies, which are creating a world where smart, secure, and communicating, sensors will become ubiquitous in planes, trains, and automobiles; inside homes; inside commercial buildings; on highways; in cities and towns; in agriculture; in factories; in retail spaces; and worn by and implanted in humans and animals. The Internet of Things could eventually connect everything from cars to cats.
A term that is being used to describe the technologies making such a smart, sensor saturated world is “sensor dust,” which captures the Zeitgeist that super tiny, smart, communicating sensors will be everywhere — like dust. Sensors, of course, are never just sensors. They are always connected to other things–mainly microcontrollers (MCUs). With the advent of ultra-low power and energy harvesting technology, the sensor-MCU combination has become an ideal, clear, and present foundation for widespread sensor roll out. Sensing often implies by its very nature detection and communication from a distance, and that is where wireless communication comes into play.
The dark side is that remote sensing and communication open the door very wide for bad actors who want to intercept, spoof, and misuse the data streaming freely through the air. So, security (encryption and/or authentication) becomes the final piece of the picture, and arguably the element that makes IoT even possible to be widely adopted. Huge amounts of information are already being collected every day about traffic flow from phone users worldwide (without their knowing it). Such storehouses of data can be mined real time and used to provide personal traffic reports to subscribers while driving. At least that is the story. As the car moves from one place to the other, social networking can be effectuated in real time to locate friends or certain activities and happenings (automotive flash-mob, anyone?). But, what consumers really want their whereabouts and other information out in the open in a completely uncontrolled way? No one. People are becoming extremely sensitive to data insecurity and there is a growing need to trust how the information that is being collected will be used. Without some type of trust, the IoT could be doomed. Maybe the term “Internet of Trust” should be coined to make that point obvious.
V2V & IoT
The evolution of V2V and IoT are intimately related because they both will be composed of the very same technological blocks. The overlap is easy to see. The foundational components of each are miniaturized MCUs, sensors, wireless technology, and security devices that operate using ultra low power. Describing IoT and V2V as equations, they could be expressed in the following way:
Equation one might imply that companies that can integrate the factors will lead in the build-out of the IoT market. Equation two effectively states that V2V is the IoT on wheels. In any case, there are certain basic blocks that must be integrated, and they must be integrated in the right way for the particular use-case. IoT and V2V design flexibility and time to market will matter, a lot. (But that is a topic for another time.) The growth of the connected car platform is expected to be remarkable. That makes sense since the car is the one place that GPS/NAV systems, smart phones, tablets, DVDs, CDs, MP3s, Bluetooth, satellite radio, high power stereo amps, speakers, voice control, and the Internet can all come together and interact with each other.
Such convergence is making the car into an advanced personal hub. Market researchers have estimated that revenue for the connected car market will grow from $17 billion in 2012 to $54.5 billion in 2018 for hardware and services (telematics, telecom, and in-vehicle). Unit sales of embedded, tethered, and smartphone equipped cars are expected to grow from around 10 million units in 2012 to 67 million by 2018, with over 50% of that volume being embedded systems that are controlled by media and sensor control systems.
Media control systems are not only becoming a standard feature in new cars, but according to consumer electronics and auto industry researchers, a chief reason that people are selecting certain cars over others. Electronics are becoming a main forethought rather than a minor afterthought for car buyers. Sophisticated electronic systems are becoming mandatory, and this powerful dynamic will only accelerate as more electronics products, features, and services are sped to the market by the car makers, consumer electronics companies, smartphone makers, and software providers.
However, all this electronic stuff has presented a huge challenge, which is safety. Using products such as the cell phone in the car actually interferes badly with driving. Anyone who has placed a call, or even worse tried to text while driving (and who hasn’t), can testify to the fact that dial-driving is a bad idea. So, what can be done to get cars electronics, phones, and humans to play well together in a safe way? The solution has been summed up succinctly by the CEO of a major auto maker who refers to in-car control systems as being able to free the user from the tyrannies and dangers of messing with that little phone while you drive. Rather than a car and phone (and other electronics) being at odds with each other, the car is transforming into the newest electronic platform: one that is highly integrated, easy to use, and distinct from anything else to date. It is easy to see that the emerging alloyed car-plus-consumer platform is primed for cars to talk to one another without the need of human intervention.
The list of electronics functions in cars is evolving fast and will likely include multi-person gaming; GPS with location-based services such as real time traffic and road condition updates; vehicle monitoring for maintenance status, performance, and eco-friendliness; vehicle and personal security; connection to home control/security systems; social networking opportunities related to location, and especially safety. In fact, the US Deportment and Transportation (DoT) and National Highway Traffic Safety Administration (NHTSA) are partnering with research institutions and auto companies to collaborate on technology development and interoperability of V2V to promote traffic safety. V2V can transform the automotive experience more than anything since Henry Ford’s assembly line made cars available to the working class. The notion of a car driving itself still sounds like pure science fiction, but prototypes are already driving themselves. So, it is just a question of time before we have auto-automobiles. (auto2mobiles) where you simply have to tell your personal digital assistant where you want to go, then take a seat in your personal infotainment pod until you get there.
But, well before that happens we will see significant improvements in safety due to V2V. It is clear that the lucrative auto electronics platform is already right in the sights of all car makers, and they clearly plan to take it to the next level and the next level after that, with no end in sight. As noted, electronic things sell cars, and more advanced electronics will show up in the more advanced cars. Then, last year’s advanced systems will naturally move down-market, so even more advanced systems will be needed for next year’s up-market cars. This endless cycle of innovation will drive automotive companies to create V2V and self-driving ecosystems sooner rather than later. As we move towards the self-driving omega-point we will see V2V and IoT showing up very early in the journey.
V2V (the IoT on wheels) will make it hard to tell where the car ends and the phone, tablet, computer, and sensors begin.
Interested in learning more about Atmel’s automotive portfolio? Check out our automotive-qualified category breakdown below:
A talented Maker by the name of Taylor Alexander, co-founder of Flutter Wireless, has recently gained a large amount of support for the company’s innovative wireless electronics development platform based on Arduino.
No novice to DIY, Taylor has spent a life of hacking, making and transfiguring things to have them do all sorts of different actions than these electronics were originally made to do. At the early age of five, he would break things down and rebuild them to create something entirely different — taking parts from old cameras, stereos and other electronic components, then transforming them into electric cars. From early on, it was evident Taylor was an innovator in the ‘making.’ Now, as everyone has witnessed, there are crowdfunding platforms such as Kickstarter, a startup incubator platform where individuals like Taylor and his co-founders can create value from their extraordinary talents and early fundamental interest.
Not only has Kickstarter offered a new way of doing things, but the platform is reshaping the business and creation cycle for people with talents in technical and creativity. The site has enabled people to get financing, allowing inventors to obtain the investment needed much faster at the early stage of incubation and product development. This money can then be better used to scale faster and prove its concepts early on via social acceptance and crowdfunding with the merits of community and validation.
The powers of the Maker Movement — a fabulous combination of getting the media, bloggers and influencers onboard, riding pre-existing trends, thinking outside the box, conducting frequent demonstrations, all while responding to the ideas and wants of the community. Arguably the most important aspect of the DIY revolution is the validation and acceptance of the community wanting to endorse and witness an idea come to fruition. At an individual level, it’s an exciting and opportunistic time for an inventor or anyone looking to contribute to the landscape of technology or where it is going. These are some of the most compelling reasons as to why Flutter Wireless is able to prove innovative ground, validate their product ideas and infuse the necessary capital to promote more success across communities. As in its Kickstarter’s illustration, the wireless electronics development platform can be communicated from of a large 3,200 ft (1km) usable range. It is packaged with a powerful Atmel ARM-based SAM3S processor, coupled with integrated encryption using Atmel’s ATSHA204cryptographic chip as the device to secure it’s system.
So, how does this wireless platform work? Well, as the Flutter Wireless site explains:
“Creating Flutter networks are easy, even if it’s just two boards. Specify networks in Arduino code or configure Flutter with our mobile app. Once configured, devices can enter and exit the network seamlessly. This makes it extremely easy to set up a network at home (or anywhere else) where all of your projects can reliably communicate. Flutter is like a second network for your devices.”
In fact, in the landscape of connecting devices and IoT, an individual building out of a wireless project shouldn’t have to be too expensive. “Flutter was built from the ground up with cost in mind, that’s why our boards start at just $20. We’ve worked hard to keep costs as low as possible and deliver you a quality product you can afford to use in as many projects as you’d like,” explains Taylor. The startup extraordinaire Taylor has helped further the ecosystem development by leveraging the concepts of “shields” and designing a handful of various protocol shields for Flutter. It’s really focused on individuals who want to get started quickly and build heterogeneous nodes of connected devices on a network. The Flutter boards come shipped with breakout boards and socket headers, combined with the power of connectivity to various protocols (Bluetooth 4.0 Low Energy or conventional Bluetooth 2.1). The Flutter Wireless platform is comprised of the network shield which connects to your home router, creating a bridge between mobile devices (M2M) the Internet and Flutter. For a wireless system, the important factors are range and reliability. According to Flutter Wireless Kickstarter:
“We use WiFi everyday, but take a few steps down the driveway and coverage quickly becomes scarce. Flutter is a different kind of wireless system, completely self-contained with over a half-mile range. This allows for a wireless platform without borders, and no longer being chained to a router means your projects are free to follow you out the front door, through the yard, and down the street.”
As previously discussed in Bits & Pieces, the combined Flutter Wireless Development platform is quite comprehensive, considering it’s Kickstarter and crowdfunding origins. Flutter Wireless comes packaged with Atmel’s ATSHA204 to ensure maximum secure storage and protection of encryption keys. Flutter is designed to address security and wireless in a combined package. The platform is comprised of a design, which encompasses a special cryptographic hardware (Atmel’s ATSHA204) that integrates cryptography into every communication layer of the software. In essence, this gives the user ultimate control over who can and cannot communicate with their devices.
The project is given strengths by making it accessible via the Open Source community – ensuring the possibility of enhancing the roadmap by contribution to improve upon Flutter Wireless foundation though the power of the community. Furthermore, Flutter’s wireless concept seamlessly routes messages across a varied number of connected devices to reach their destination. It’s sort of like a lily pad of daisy chaining across many nodes or protocols. With that said, there is a world of potential in the IoT buildup for a number of reasons. Arduino already has a big open-source following. First, this is already proven (via the Maker Movement and Maker Faire) and it’s one of the easiest ways to bridge the physical and digital worlds together. Flutter Wireless can be a node in a larger mesh network, which could be useful for large public projects. (i.e. Let’s say, a hobbyist or passionate drone user wants to fly his drone to the next town over, keep it connected across RC and mesh networks all within good range and security).
The winning formula:
ARM + Encryption + Easy Development + New IoT-Based Radio + Mesh + Shields + Open Source + Community + Crowdfunding = Thousands of lines of agile code, mesh support, tagging, and various protocol features required to support IoT buildup
Flutter still finds itself under development and continually evolving. The prototypes were designed with the Sparkfun Arduino Pro Mini for rapid development and proof of concept. Out of this ideated adventure, a new generation of boards are in the process being developed with Atmel SMART™ ARM-based SAM3S, a very affordable, versatile and powerful ARM core processor with a capacity for speed and storage space to suit any designer’s connected device project.
While perusing my latest copy of American Motorcyclist magazine, I was pleased to see an article on how vehicle-to-vehicle (V2V) communication might make roads safer for motorcyclists. V2V is where vehicles have their own dedicated micro-controller and wireless chip and security chip. Atmel makes all three, both as separate parts and combined into one. The vehicles will have a wireless RF “bubble” that travels with them. When two vehicle’s bubbles “touch”, then they will authenticate it is not some hacker on a bridge embankment. Then the vehicles can exchange information. It is anticipated that the system will have GPS, so each vehicle will know its exact position.
While drunk driving fatalities have plummeted, distracted driving is killing twice as many people.
As a guy with a broken collarbone that got hit from behind while my motorcycle was stopped for a red light, I think this is great. If vehicles can communicate they can warn each other of impending collisions. Auto manufacturers anticipate verbal and “shaker” warning for the cars, or so-called “cages” as we motorcyclists call them.
The AMA publishes the magazine and I am a proud supporter. One thing I disagree with is that the AMA wants motorcycles to be nearly silent. Now I hate open pipes, that is a moron thing to do since you can’t tune the motor because of the reversion pulses coming off the end of pipes. But silent bikes are too far in the other direction. With half the driver’s noses stuck in a smartphone while they drive, a little noise alerts them to my presence.
This V2V technology may make all this moot. I won’t need loud pipes if vehicles actively work to avoid collisions. I touched on this in an earlier blog post—Car-to-car communication.
The act of authentication is very straightforward. Essentially, it is making sure that something is real.
There are two parts to authentication:
Identification
Confirmation of identity
Authentication in the “crypto-verse” typically happens on a host and client basis where the host wants to ensure that a client is real. A typical use case occurs when a client device is inserted into a system, while the host asks (“challenges”) the client to confirm its identity. This can occur when an ink cartridge is inserted into a printer, or a water filter is put into a refrigerator. a battery is put into a phone, and numerous other applications. Firmware and software can be authenticated too, but that is a topic for another article.
Think of the challenge as when the castle guard in an old movie asks, :Halt! Who goes there?”. The guard expects a suitable response to prove confirm the identity of the approacher.
Getting back to the real world, authentication is accomplished using a process focused on calculations involving cryptography keys, and that is true for both of the major types of authentication; namely, symmetric and asymmetric. We will focus on the symmetric process here.
With symmetric authentication, the host and client both have the exact same key, which is in fact how symmetric got its name. Note that is critical for both keys to be kept secret to ensure security. Keeping secret keys secret is the main touchstone of authentication and data security of any type. The best way to do that is using a secure hardware key storage device.
The basic idea behind symmetric authentication is that if the client is real then it will have the exact same key as the host. Challenge-response is a prescribed methodology to prove it.
The host controller sends the client a numerical challenge to be used in a calculation to create a response, which is then compared to a similar calculation that is performed on the host.
To describe the process in more detail we can look at a typical symmetric authentication architecture using Atmel ATSHA204A devices on both the host and client and a microcontroller in the host. (Another article will explain how this is done with the crypto device on the client only, which is the fixed challenge methodology).
Step 1: The process kicks off when the host sends a random number to the client which is generated by the host’s ATSHA204’s random number generator. This is the“Challenge”and is illustrated above.
Step 2: The client receives the random number challenge and runs it through a hash algorithm (i.e.SHA256) using the secret key stored there. The result of the hashing function is called the “Response” and it can also be called the “Message Authentication Code” (or MAC). A MAC is technically defined as the result of a hashing function involving a key and message. The response is sent to the host.
Step 3: The host internally uses the same challenge (i.e. the random number) that it sent to the client as an input to its internal hash algorithm. The other input to the internal hash is the secret key stored on the host side. Then the host compares the hash value (MAC) calculated on the host side with the response hash-value (MAC) sent from client. If the two hash values (MACs) match – then the keys are indeed the same and the client is proven to be real.
Note that the secret keys are never sent outside the devices, as they always remain securely stored in protected hardware and invisible from attackers. Stated very simply: “You can’t attack what you can’t see.”
Benefits:
The benefits of a symmetric architecture with secure key storage crypto engine devices on both sides are:
Symmetric authentication with crypto devices on both sides is quite fast.
Secure hardware storage on both sides increases security.
Ensures a very low processing burden on the microcontroller.
For more details on Atmel CryptoAuthentication™ products, please view the links above or the introduction page at CryptoAuthentication.
If we wanted to reduce the definition of authentication to its most Zen-like simplicity, we could say authentication is “keeping things real.” To keep something real you need to have some sort of confirmation of its identity, as confirmation is the key (so to speak).
The equation could be as follows:
Identification + Confirmation = Authentication
Confirming or validating the identity of a document, item, data, etc. is what keeping things real is all about. Some of the “things” that can be authenticated with cryptographic methods are mobile, medical, and consumer accessories; embedded firmware; industrial network nodes; and sensors, among others. Soon IoT and vehicle-to-vehicle communication will join in.
Authentication is far more important than many people realize, especially in our growing hyper-connected world that now links billions of people (and things). In cyber-land, authentication is accomplished by deploying cryptographic keys and algorithms. Keys are fundamental to keeping things real—so that is what we mean by “the key to reality.”
There are two primary types of Authentication: Symmetric and Asymmetric. Atmel offers secure key storage devices for both types. These two important techniques take their names directly from whether the keys on each side (i.e. the host and client sides) are the same or different.
Symmetric Authentication
If the same secret key is used on the client and on the host, then the application is symmetric, just like the name suggests. Both of the symmetric keys must be protected because if either one gets out then the security will be lost. This is perhaps analogous to having two sets of car keys. Meaning, losing either one makes it easy for a thief to drive away with your car. So, the secret keys must stay secret.
Symmetric Keys are the Same
The identical keys on the host and client are used in mathematical calculations to test the reality of client devices. A very common mathematical calculation that is used is a hash function based upon a cryptographic algorithm (such as SHA). A hash operation produces a hash value (also called “digest”), which is a number of a specified length that is usually smaller than the numbers used as the inputs. A hash is a one-way operation, which means that the inputs cannot be recreated from the hash value.
With symmetric authentication a typical process is to challenge the client device to be authenticated by sending it a random number. The client then puts the random number challenge and a secret key into the hash algorithm to create a hash value, which is known as the “response.” Each challenge will generate a unique response.
It should be noted that cryptographers call a hash of a random number with a secret key a “Message Authentication Code” or “MAC.” The diagram below illustrates this process. Because the host key is the same on the host and client sides, the exact same calculation can run on the host. Once that happens, the hash values (“MACs”) from each can be compared. If the hash values match, the client is considered to be real. You can see that symmetric authentication is really a simple process, but it is loaded with mathematical elegance. Now let’s look at asymmetric authentication.
Hashing a Random Number with a Secret Key
Asymmetric Authentication.
Asymmetric keys are presented in public-private pairs. More specifically, the public and private keys are related to each other via a mathematical algorithm. An example would be the Elliptic Curve Cryptography (or “ECC”) algorithm. Only the private key has to be securely stored. Because the keys are different, asymmetric authentication cannot use the same calculate-and-compare process as symmetric.
Asymmetric requires more complicated techniques such as making digital signatures that are verified for authenticity (this is called “Sign-Verify”). An example of asymmetric authentication using ECC algorithms is Elliptic Curve Digital Signature Algorithm (or “ECDSA”). A major benefit of the Atmel ATECC108A device is that it can be used to easily implement ECDSA sign-verify. (The steps of ECDSA are very interesting, but they will be covered in a separate article). Note that an important trade-off between symmetric and asymmetric authentication is the speed of operation. For example, authentication time for the Atmel ATSHA204A is 12ms (typical) for symmetric versus more than a second for many microcontrollers to execute an asymmetric ECDSA operation.
Getting back to the keys: The secret keys must stay secret.If keys are the keys to authentication (i.e. reality), then secure storage of the secret keys is the key to SECURE authentication. And that is the real point here.
So the, how is secure storage implemented? The best way is to use hardware key storage devices that can withstand attacks that try to read the key(s). Atmel CryptoAuthentication products such as the ATSHA204A, ATECC108A and ATAES132 implement hardware-based storage, which is much stronger than software based storage because of the defense mechanisms that only hardware can provide against attacks. Secure storage in hardware beats storage in software every time. Adding secure key storage is an inexpensive, easy, and ultra-secure way to protect firmware, software and hardware products from cloning, counterfeiting, hacking, as well as other malicious threats.
For more details on Atmel CryptoAuthentication products, please view the links above or the introduction page CryptoAuthentication. Future Bits & Pieces articles will take in an in-depth look at how symmetric and asymmetric authentication is accomplished.
When considering adding cryptography to an embedded system (or any other information system) manufacturers always ask: “Why do I need cryptography?” That is, unless they have already been burned by a security breach. The answer is quite simple: “Because you have a lot to lose and the dangers are multiplying every day.”
Perhaps some of the closest analogies are driving without auto insurance, owning a house without fire and casualty insurance, living without health insurance…well, you get the picture. The point is, intentionally leaving an embedded system exposed to hacking, malware and cloning to save cost is simply not prudent from a financial perspective. Of course, safety, liability and brand equity also matter – a lot.
Cutting to the chase, dangerous exposure is directly linked to how exposed the cryptography key is to being accessed by unintended parties such as hackers and cyber-criminals. This has to do with how the key is stored. However, before we explore this topic, let’s look at the bigger picture.
The answer to “why” for product manufacturers? They need to protect their development investment, brand image and revenue in an increasingly hostile cyber-world replete with bad actors. As we noted in a previous article, the number of active Internet threat groups being tracked has risen to over 300, which is more than 400% higher than in 2011. Nation-states have become hyper-active in cyber-espionage and cyber-attacks. This is because it is now possible to literally upload damage to a target, which is kind of a science fiction scenario come true.
In the same vein, secret information is easily downloaded. More than 95% of networks have become compromised in some way, and directed attacks will only get worse as mobile platforms continue to expand worldwide.
Vulnerable systems placed on the Internet are currently being compromised in less than 15 minutes. Frankly, these statistics aren’t really a surprise given the wildly disproportionate cost / ”benefit” of cyber meddling, which is devilishly tempting to malicious operators.
It is clear from the above statistics that hostilities have already broken out and cryptography is the best available shield—perhaps the only one.
Now that we have looked at the “why” in cryptography, what about the “what?” What is cryptography? Let’s focus on the two pillars of cryptography, which are described below:
1. Authentication
Making sure the data source is what it is supposed to be.
2. Encryption/decryption
Scrambling and descrambling data so only an intended receiver can see it.
Both encryption and authentication are contingent upon keeping secret keys secret. This is the key point.
However, there are many different encryption algorithms, types of authentication schemes, architectures and applications. There is also the choice of how to store the encryption keys. The last point – key storage – is probably themost significant consideration manufacturers can make regarding security.
In essence, cryptographic security is a function of three critical factors:
The length of the keyused by the cryptographic algorithms,
The mathematical operations of the cryptographic algorithms, and
How securely the keys are stored (i.e. how vulnerable the keys are to attack).
Since the strength of security depends upon the key size and the specific mathematical properties of the algorithms, various combinations of key sizes and algorithms can potentially be stronger or weaker than any other combination. Meaning, manufacturers have to select one and the other according to their requirements. However, if the keys are not securely stored, well, then none of it matters all that much.
If the keys are not kept secret, then the information can be obtained by unintended outside parties, which defeats the entire purpose. Right? As such, the memory where the key is stored must be able to withstand attacks that try to read the key(s). Such attacks are always underway somewhere, which is a sad but true fact. Fortunately, hardware security devices, like Atmel CryptoAuthentication products, offer a proven method of protecting secret keys that not only restricts access, but also provides key generation and management.
Similarly, storing keys in general purpose (i.e. unsecured) memory in any system leaves the keys open to theft or authorized use via multiple paths. By definition, any system’s software must have access to memory, so any type of bug in the software can inadvertently reveal the key. Just look at the Heartbleed bug as an example. Specialty hardware devices, like CryptoAutentication products are designed for the express purpose of securely storing hardware keys. They do this by utilizing special defense mechanisms that only hardware can provide to repel attacks of various types.
As we’ve previously discussed on Bits & Pieces, secure storage in hardware beats general purpose storage every time. So, the “why” and “what” of cryptography boils down to this: Adding secure key storage is an inexpensive, easy, and ultra-secure way to protect firmware, software and hardware products from cloning, counterfeiting, hacking and other malicious threats.
The key to security is protecting the key. Plus, hard protection beats soft protection. It is that simple. This is precisely why Atmel’s ATSHA204A, ATECC108A and ATAES132 are all designed for secure authentication by providing a hardware-based storage location with a range of proven physical defense mechanisms, as well as secure cryptographic algorithms and processes. They represent over three generation of hardware security know-how, and experience matters when dealing with real world attacks.
Future Bits & Pieces posts will examine authentication schemes such as asymmetric and symmetric, and how Atmel key storage devices operate in the real world.
The Heartbleed security bug is a really big deal, especially given today’s hyper-connected, information obsessed society. This nasty bug, which has been characterized as “catastrophic” by industry gurus, permits anyone on the Internet to access the memory of systems using various versions of OpenSSL software. This is ironic since that very software was specifically designed to protect data.
Nevertheless, Heartbleed exposes secret keys used for authentication and encryption, which are the two primary foundations of how security is generally ensured. By exposing keys Heartbleed thus exposes actual data, user names, and user passwords to anyone. This is virtually everything. Ouch! Attackers (i.e. hackers, cybercriminals, spies, state-sponsored electronic armies, and others with malevolent intent) can observe and steal data without a trace, which is virtually the literal industry definition of the term “man-in-the-middle” attack.
The threat that Heartbleed represents has rightly gained widespread attention. Fortunately, such attention has stimulated a major market reaction and lead to whole scale changing of user passwords, proliferation of patches, and other fixes. It has also brought the need for more extensive code testing into the open. Heartbleed and other major security revelations are making people look at security much more seriously, which also extends to embedded systems.
Frankly, it is about time. Embedded system insecurity gained major notoriety recently with the revelation that commercial WiFi routers have old and buggy firmware that can be used as a back door into home and commercial networks. Such loopholes were in fact used by a criminal organization in Eastern Europe to steal cash. The risk was amplified by the revelation that mischievous “agencies” tasked with collecting and processing information without permission can exploit the vulnerabilities at will.
Embedded system firmware insecurity affects individuals, institutions, governments, and corporations—which is pretty much everyone. Highly respected market researchers have noted that bad behavior and bad actors are running rampant. For example, the number of active threat groups being tracked has risen to over 300, which is more than 400% higher than in 2011. Nation-states have become hyper-active in cyber-espionage and hacking. This is because it is now possible to literally upload damage to a target, which is kind of a science fiction scenario come true.
In the same vein, secret information is easily downloaded, especially with security vulnerabilities from Heartbleed, router back-doors, and others. More than 95% of networks have become compromised in some way, and directed attacks will only get worse as mobile platforms continue to expand worldwide. An unnerving figure is that vulnerable systems placed on the Internet are being compromised now in less than 15 minutes. That is not really a surprise given the wildly disproportionate cost / ”benefit” of cyber meddling, which is devilishly tempting to malicious operators.
The security situation is extremely complicated for embedded systems because embedded firmware is highly fragmented, difficult to update, hard to track, often obsolete, hard to access, and employs a wide range of processors and code languages. The router loopholes mentioned above are in fact a direct expression of the vulnerabilities endemic to embedded systems and the severe damage those vulnerabilities can cause downstream. It is now clear that embedded system vulnerabilities affect everyone. So, the question becomes, “What can be done to increase security in embedded systems?”
As Heartbleed and cyber attacks have illustrated, encryption and authentication keys must be protected. There is no other option. Cryptography may be mathematically and systematically ultra-detailed and uber-complicated, but the most important and fundamental security concept is beyond simple: namely, “Keep the secret keys secret.” The best way to do that is to lock the secret keys in protected hardware devices.
Hardware key storage beats software key storage every time, which is one of the “key” lessons of the recent vulnerability revelations. But how does an embedded system manufacturer ensure their products are secure and protected from attack? Fortunately, the solution is simple, available, and cost effective, and that is to use hardware key storage devices such as Atmel’s ATSHA204A, ATECC108A and ATAES132.
These products are all designed to secure authentication by providing a hardware-based storage location with an impressive range of proven physical defense mechanisms, as well as secure cryptographic algorithms and processes. Go to the links above for more details or the introduction page CryptoAuthentication.
Future Bits & Pieces posts will describe the different types of authentication and the various steps that the devices and associated processors implement.
Authentication means making sure that something is real, just like it sounds.
In the real world, authentication has many uses. One of the most recognizable is anti-counterfeiting, which means validating the authenticity of a removable, replaceable, or consumable client. Examples include system accessories, electronic daughter cards and spare parts. Of course, authentication is also employed to validate software and firmware modules, along with memory storage elements.
Another important and growing role for authentication is protecting firmware or media by validating that code stored in flash memory at boot time is the real item – effectively helping to prevent the loading of unauthorized modifications. Authentication also encrypts downloaded program files that can only be loaded by an intended user, or uniquely encrypt code images that are accessible on a single, specific system. Simply put, authentication of firmware and software effectively makes control of code usage a reality, which is important for IP protection, brand equity maintenance and revenue enhancement.
Storing secure data, especially keys, for use by crypto accelerators in unsecured microprocessors is a fundamental method of providing real security in a system. Checking user passwords via authentication means validation – without allowing the expected value to become known, as the process maps memorable passwords to a random number and securely exchanges password values with remote systems. Authentication facilitates the easy and secure execution of these actions.
Examples of real-world benefits are quite numerous and include preserving revenue streams from consumables, protecting intellectual property (IP), keeping data secure and restricting unauthorized access.
But how does a manufacturer ensure that the authorization process is secure and protected from attack? With hardware key storage devices such as Atmel’s ATSHA204A, ATECC108A and ATAES132 – which are all designed to secure authentication by providing a hardware-based storage location with a range of proven physical defense mechanisms, as well as secure cryptographic algorithms and processes.
The bottom line? Hardware key storage beats software key storage every time – because the key to security is literally the cryptographic key. Locking these keys in protected hardware means no one can get to them. Put another way, a system is not secure if the key is not secure – and the best way to secure a key is in hardware. It is that simple.
Future Bits & Pieces posts will explore various methods of authentication such as asymmetric and symmetric, the ways in which Atmel’s key storage devices operate, specific authentication use models and other security related topics.
There are two fundamental ways to use keys or secrets for encryption:symmetric and asymmetric. Symmetric encryption uses the identical key to both encrypt and decrypt the data. Symmetric key algorithms are much faster computationally than asymmetric algorithms as the encryption process is less complicated. The length of the key size is critical for the strength of the security. NIST has recommendations on how long a key should be– in general, 160-512 bits. There are inherent challenges with symmetric key encryption in that the key must somehow be managed. Distributing a shared key is a major security risk.
symmetric encryption
Asymmetric encryption uses two related keys (public and private) for data encryption and decryption, and takes away the security risk of key sharing. The private key is never exposed. A message that is encrypted by using the public key can only be decrypted by applying the same algorithm and using the matching private key. Likewise, a message that is encrypted by using the private key can only be decrypted by using the matching public key.
