Ever get lucky enough to hit a couple of green lights in a row on your morning commute? Well, it appears that it’s not so hard to make happen all the time. If you’re a hacker, at least.
A team of security researchers from the University of Michigan, led by computer science professor J. Alex Halderman, found that the state of Michigan’s traffic light infrastructure is wide open to hackers. The team, with the permission of a local road agency, was able to hack into nearly 100 wirelessly-networked traffic lights more than a laptop and a bit of custom code.
The team say the flaws they uncovered, which included the use of unsecured wireless networks, default username/password combinations and a debugging port that was easy to attack, are likely to be found throughout the country’s systems.
MIT TechReview reports that although the road agency responsible for implementing the system has never faced serious computer security threats, the possibility will become more worrisome as transportation authorities and automakers test new ways for infrastructure and vehicles to communicate in order to reduce congestion and accidents.
“The vendors had not enabled encryption by default and the road agency never did so themselves,” even though doing so would be trivial, said Ph.D student Branden Ghena, who was part of the team. “It is as simple to turn on as checking a button.”
Wirelessly networked traffic lights have four key components: Sensors that detect cars, controllers that use the sensor data to control the lights at an intersection, radios for wireless communication among intersections, and malfunction management units (MMUs), which return lights to safe fallback configurations if an “invalid” configuration occurs.
The Michigan researchers found that anyone with a computer that can communicate at the same frequency as the intersection radios, which in this case was 5.8 gigahertz, could access the entire unencrypted network. It takes just one point of access to get into the whole system.
“By sniffing packets sent between the controller and this program, we discovered that communication to the controller is not encrypted, requires no authentication, and is replayable. Using this information, we were then able to reverse engineer parts of the communication structure. Various command packets only differ in the last byte, allowing an attacker to easily determine remaining commands once one has been discovered. We created a program that allows a user to activate any button on the controller and then displays the results to the user. We also created a library of commands which enable scriptable attacks. We tested this code in the field and were able to access the controller remotely.”Once access was gained, in just minutes, the team had the ability to change light schedules, disable parts of the grid, or even put the the entire system into a failsafe mode. “Until these systems are designed with security as a priority, the security of the entire traffic infrastructure remains at serious risk,” a paper documenting the results explains.
The researchers in their paper add, “The vulnerabilities we discover in the infrastructure are not a fault of any one device or design choice, but rather show a systemic lack of security consciousness.”
If a hacker wanted to bring a city to a standstill, this study shows just how easily they could go about doing it. Given that this type of system is used in more than 60% of the traffic intersections throughout the United States, “the industry as a whole needs to understand the importance of security, and the standards it follows should be updated to reflect this. Security must be engineered into these devices from the start rather than bolted on later.”
ADT Pulse, the company’s existing automation service, will now include the capability for users to communicate with the hundreds of channels controllable by IFTTT. According to Mashable, this new partnership will allow developers and users to create recipes that work with door locks, thermostats, lights, cameras, appliances, and the main security system.
“We like to think of it like Lego pieces — you can make whatever you want out of it,” Arthur Orduna, ADT Chief Innovation Officer tells Mashable. “We are trying to be really cognizant of how people consume things today and do everything we can to make everything on demand.”
The newfound IFTTT integration will open up new opportunities for consumers such as receiving a live feed of their doorstep as the doorbell rings. With countless possible command “recipes,” ADT hopes users will have a simplified, personalized experience. Some of these proposed IFTTT recipes suggested by ADT include:
If a wearable changes from “sleep” to “awake,” then disarm the ADT Pulse security system.
If phone alarm goes off at 6:45 a.m., then turn on the ADT Pulse-connected coffee machine.
If Life360® family members are away from home, then lock ADT Pulse-connected doors and arm ADT Pulse security system “away.”
If the temperature outside is above 85 degrees, then change an ADT Pulse-connected thermostat to 70 degrees.
If a user texts “DogDoor”, then unlock the ADT Pulse-connected back door.
If the doorbell rings, then send me an ADT Pulse real-time video clip of the front door.
If the sun sets, then turn on ADT Pulse-connected outdoor lights.
While a customizable experience is highly desirable for home security users, there are inherent risks of opening a secure platform to countless new applications. With countless applications having access to a home’s security measures, there is undoubtedly a reason to be concerned about possible hacking.
Writing for CNET, Ry Cris relayed these concerns to ADT, which revealed that the team is promising to take things slow. “Exposing an existing home security system to so many new devices at once could potentially expose it to new vulnerabilities, however. If a third-party device that’s capable of turning the alarm off through IFTTT is easily hacked, for instance, that’s a real problem.”
“By integrating with IFTTT, ADT suddenly becomes compatible with dozens of new Web tools and third-party connected gadgets. It’s potentially, a very savvy defensive play, as small-scale, forward-thinking security startups with an eye on automation seem to be gaining traction,” Cris adds.
The new IFTTT channel will go through several months of beta testing before ADT opens it up to the public next year. At that point, the group aspires to have accounted for any possible security breaches.
Speaking of simplifying home programming with IFTTT, a team of computer science researchers from Brown and Carnegie Mellon universities recently adapted a method of programming known as “trigger-action” to more effectively communicate with IoT smart home devices.
Forget about car jacking, car hacking is now at the center of all the buzz. A grassroots security movement called “I am the Cavalry” recently introduced a cyber safety program to facilitate collaboration between researchers and car makers as vehicles become increasingly connected. Last Friday, the group presented an open letter to the heads of today’s leading automotive companies challenging them to acknowledge growing cybersecurity concerns that impact vehicle safety. In a detailed description of its “Five Star Automotive Cyber Safety Program,” I am The Cavalry outlined five critical capabilities that participating companies should demonstrate within their organization to improve security:
Safety by DesignVALUE: We take public safety seriously in our design, development, and testing.
PROOF: As such, we have published an attestation of our secure software development lifecycle, summarizing our design, development, and adversarial resilience testing programs for our products and our supply chain.
Third-Party CollaborationVALUE: We recognize that our programs will not find all flaws.
PROOF: As such, we have a published coordinated disclosure policy inviting the assistance of third-party researchers acting in good faith.
Evidence CaptureVALUE: We want to learn from failures and enable continuous improvement. PROOF: As such, our systems provide tamper evident, forensically sound logging and evidence capture to facilitate safety investigations.
Security UpdatesVALUE: We recognize the need to address newly discovered safety issues.
PROOF: As such, our systems can be securely updated in a prompt and agile manner.
Segmentation & IsolationVALUE: We believe a compromise of non-critical systems (like entertainment) should never adversely affect critical/physical systems (like braking).
PROOF: As such, we have published an attestation of the physical/logical isolation and layered defense measures we have implemented
“Modern cars are computers on wheels and are increasingly connected and controlled by software. Dependence on technology in vehicles has grown faster than effective means to secure it. Security researchers have demonstrated vulnerability to accidents and adversaries over more than a decade,” the group writes on its website.
It appears that some have grown tired of the same-old hacking of computers, email, websites and networks, and have elected to try a moving target instead; subsequently, with the emergence of connected vehicles comes numerous car hacking opportunities.
In its open letter, I am The Cavalry referenced vehicle-to-vehicle (V2V) communication, automated traffic flow, remote control functions and driverless cars as just some of the evolving technologies making their way to the public. “We don’t need to wait for bad things [to happen] before starting to take safety into our design [considerations]. It takes a very long time to develop technologies and get them in the market. What we start today may not manifest for several years,” Joshua Corman, I am The Cavalry Co-Founder and CTO of Sonatype, told SCMagazine.
(Source: Seth Rosenblatt/CNET)
A Change.org petition has also been set up, encouraging the car industry to urgently address security concerns. “When the technology we depend on affects public safety and human life, it commands our utmost attention and diligence. Our cars command this level of care. Each and every day, we entrust our lives and the lives of those we love to our automobiles.”
“The goal of our outreach effort here is to catalyze greater teamwork between security researchers and the automotive industry. Our combined expertise is required to ensure that the safety issues introduced by computer technologies are treated with the same diligence as other classes of automotive safety issues.”
Researchers have revealed that high-end cars have several computers to control brakes, acceleration, cruise control and self-parking. As a result, attackers have to find a way to exploit a system and then use that vulnerability to send a command to the electronic control unit. These flaws are a problem because it’s hard to patch a car. As VentureBeat notes, “Tesla has a lot of security in place, and it also has a vulnerability disclosure system. Most car makers seem unprepared for hackers because they’re not yet used to the idea of hackable electronic systems. The tire pressure monitoring system, for instance, is hackable. But the risks related to it are small.” As car makers add more computing power and communications to their cars, they become bigger targets. Tesla vehicles rely heavily on sophisticated software and electronics. Founder Elon Musk has even offered a $10,000 reward for a successful hacking of the Tesla Model S vehicle.
A study released at Black Hat 2014 by security researchers Chris Valasek and Charlie Miller also explored the “hackability” of 24 different car models. Among the “most hackable” include 2014 Jeep Cherokee, 2015 Cadillac Escalade and 2014 Infiniti Q50) while some of the notable “least hackable” include 2014 Dodge/SRT Viper, 2014 Audi A8, and 2014 Honda Accord.
Part 2 of The ABCs of ECDSA (“Sign-Here”) will describe how digital certificates are made and signed. In the previous article (The ABCs of ECDSA: Part 1), we examined the steps of ECDSA performing asymmetric authentication using digital certificates. You may have noticed that both Part 1 and Part 2 are in reverse chronological order; however, it makes better sense to first understand a bit about the actual authentication process before dissecting the details of making the certificate. (Just trust me on that.) Before we get into the nuances of the certificate, let’s recall that authentication is about keeping something real. Such things would be mobile, medical and consumer accessories; embedded firmware; industrial networks; and soon the new platforms of IoT, home automation, and vehicle-to-vehicle communications. Aside from those, there are several others given the fact that the need for authentication is increasing exponentially as more things communicate with each other, and through the cloud, are creating more opportunities for bad actors to apply their mal-intent.
Especially with the increased use of the Internet and the cloud for financial transactions and transmission of confidential personal/medical information, it’s critical to ensure that the sender of information is exactly who they are supposed to be, as well as that the data has not been tampered with. That is where authentication and hardware key storage come in. Here we will focus on asymmetric authentication. Asymmetric authentication using ECDSA is based upon a digital certificate, which in this case, is stored in the ATECC108A device.
So, now let’s go into the chip factory and see how the ECDSA certificate is made and stored in the device. Remember that ECDSA stands for Elliptic Curve Digital Signature Algorithm. The words “Elliptic Curve” are in the name because Elliptic Curve Cryptography (“ECC”) algorithms are used. No mystery there. The benefit of ECC is that it provides extremely strong security with shorter key lengths than other popular algorithms. Bitcoin, for example uses ECC predominantly for that reason. (We won’t go into Bitcoin here.) “DSA” points to the fact that digital signatures are the key element of the process, which is also fairly self evident. The digital signing process is what we describe here, step by step. “Certificate” is the name given to the concept of putting certain types of data together in a prescribed format and then signing that data using hashing algorithms and signing algorithms. (Again, the usage of the certificate is covered in Part 1.)
While we are fully immersed here in cryptographic alphabet soup, we might as well add one more thing to it: The prescribed format used in the ECDSA in the ATECC108A is called ASN.1. ASN.1 basically defines what is what in the certificate, including the serial number, the public key and that sort of thing. It also defines the length of those data elements.
Now, back to building the certificate: The certificate is made and loaded in the key storage device in the chip factory. It is made from two main components:
1. The certificate data 2. The signature
The certificate data is a collection of data from three sources:
1. Static data: Boiler plate type data that does not change, such as the name and address of the manufacturer. (This is the ASN.1 encoded stuff.)
2. Dynamic data: Data from the tester that can change with each device such as time, date, and serial number.
3. Client device’s public key, which has an algorithmic relationship to the client’s private key that will be securely stored in the client device.
The certificate data is formatted according to X.509 specifications (yes, more crypto jargon). X.509 defines the elements and order of the elements in the certificate, such as serial number, public key, subject’s common name (i.e. the name of the certificate), authority ID (normally a SHA-1 hash of the public key), authority common name (i.e. the name of the authority that signs the certificate data), among other things. We will leave more about X.509 for another day.
The certificate data comprises just half of the certificate, the other half is the signature. What is a little tricky to understand at first is that the certificate data do two things: (1) become part of the certificate as it is, and (2) gets hashed and signed to make the signature. Both the certificate data itself and the signature make up the certificate.
The specific steps in order to make the signature begins with a copy of the certificate data being put through a hash algorithm to create a number called a hash value (or digest). ECDSA specifies a 32 byte digest length and SHA256 as the hashing algorithm. Once created, the digest is ready to be signed by the sign module in the factory.
The sign module is a piece of equipment that securely stores the signer’s private key. No one can get access to that key. The sign module uses the ECC sign algorithm to sign the digest of the certificate data with the signer’s private key. The result of that process becomes the “signature.” The signature then joins the original (i.e. unhashed) certificate data to complete the certificate. Note that the signing key is tied to the OEM’s root key to create the root of trust (the notion of root of trust will be addressed in another article).
The certificate is now finished and can be installed into the crypto device. Once the device is finished, it is then shipped to the customer’s factory to be assembled into an accessory, consumable, board or any number of things, i.e. a consumable water filter that later gets installed into refrigerator. In this scenario, when a new filter is installed by the consumer into the refrigerator when the old filter expires, the new filter will be authenticated by the host processor in the refrigerator according to the ECDSA process as described in The ABCs of ECDSA (Part 1).
Below is a video (sorry, no sound) that will visually help walk you through the steps noted above.
Benefits of asymmetric authentication with ECDSA include:
Increased security because asymmetric authentication does not need secure key storage on the host (only the client)
No need to update the host with secrets in the field (can update the public key at any time.)
Uses the advantages of Elliptic Curve Cryptography (high security, short key, less computation)
Atmel CryptoAuthentication™ products such as Atmel’s ATSHA204A, ATECC108A and ATAES132 implement hardware-based storage, which is much stronger then 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, and other malicious threats.
One of the major difficulties in explaining anything cryptographic, among many other things, is what I call “Acry-phobia” which is fear of cryptographic acronyms. This is a justified condition.
Acryphobia is far from irrational because in cryptography (since it is math) every little thing and the relationships between them must be defined, specified, examined, theorized, tested, formulated, processed, scrutinized, proved, and…. well, you get the picture. Simply stated, this means there’s a whole lot to it. Therefore, in order to teach cryptographic concepts, it’s imperative to focus on a specific area at a time and then break that down further into its fundamentals: That is sort of like breaking down the works of Shakespeare first into episodes, then into Old English then modern English and finally the ABCs. In pretty much similar fashion, that is what we want to do here. Namely, focus on one type of authentication scheme and break it down into its fundamentals and explain those one step at a time.
The specific fear-inducing cryptographic acronym we will try to overcome during this session (and one more after it) is ECDSA, or Elliptic Curve Digital Signature Algorithm.
To quickly dispel some of the Acryphobia, let’s look at authentication from a less mathematical viewpoint.
The basic idea of authentication (just like the name says) is to authenticate, meaning to confirm that the sender of a message is exactly who they say they are. Confirmation is the key to authentication and it requires using some type of trusted credential from another party to verify a declared identity. As noted in an earlier article, this identity confirmation process is sort of like those scenes in old movies where a guard of some type challenges an approacher by saying, “Halt! Who goes there?”
Once challenged, the approacher must respond by identifying himself (or herself) and produce a document (certificate) with the signature or seal of the king, general, or some other trusted authority to confirm that the bearer is not an impostor. That seal or signature links the approacher to a recognized, trusted signer/sealer. The signer/sealer can be described therefore as the certificate authority. (Note that “Certificate Authority” is in fact a technical cryptographic term.)
Cryptographic authentication is just the mathematical version of this challenge-response-certificate-signing-verification process. It uses digital processors, rather than people with bayonets or other weapons of choice.
Getting back to the math, the type of authentication we are discussing in this article is asymmetric, meaning that the secret key is not stored on both the host and client (like with symmetric authentication). Asymmetric authentication stores the secret key on the client side only and then the uses certain mathematical algorithms on certain prescribed information that the client sends it for the ultimate purpose of verifying that the client is real. ECDSA is one of the available types of processes, and what we are going to explore throughout the rest of the article, in a step-by-step fashion. Later on, in an upcoming article, we will address the details about how the crypto devices are originally loaded in the chip factory with the important information needed to make ECDSA authentication happen out in the real world.
So, let’s get into the asymmetric authentication process, which typically begins when a client device is inserted into a host system or the host system wants to know what exactly is connected to it. Examples include a printer ink cartridge being inserted into a printer, a thermostat control block wanting to talk to a remote temperature sensor, a cell phone connecting to a wall charger, among a number of others.
ECDSA (Elliptic Curve Digital Signature Algorithm) is a two-phased process:
Phase 1is to verify that the public key on the client
Phase 2 is to verify the private key on the client.
If both phases pass these two verify calculations then the client is verified as real (i.e. by showing that there is a valid private-public key pair in the client).
(Remember that authentication of any type is meant to keep something real. How the keys are used defines if the process is symmetric or asymmetric.)
The steps of ECDSA are depicted in the diagrams below. In this particular example, the illustrations are based upon a host system that contains a microcontroller and a client (accessory) equipped with an ATECC108A secure key storage device.
Phase 1 starts with the host requesting information to be sent over by the client (accessory). That information comes over to the host as a “certificate.” This certificate is made and then programmed into the crypto device in the chip factory. For now, we’ll start with the already assembled, stored and ready-to-use certificate.
The certificate contains two main things:
Certificate data (made up of the client’s public key + static data + dynamic data)
Signature (made by hashing that certificate data and the signer’s secret key in the chip factory)
When the host receives the certificate, it extracts the certificate data (static data, dynamic data, and client public key) and the signature (made by the signing module in the chip factory). The host runs the same hashing that was used in the chip factory on the certificate data it just received, creating a 32-byte message digest that will be used in the phase one ECDSA calculation. If the client is real, then this hash function run in the host should have the exact same result (digest) as the one that was run the chip factory to create the signature.
On the host, the message digest made from the received certificate data, the signer’s public key, which also came over from the client (more on how that arrives will be in yet another article), and the signature from the certificate are put into the ECDSA verify calculation. If the ECDSA calculation is successful, the client’s public key is considered to be real. That then starts phase 2 to verify the client’s private key.The whole point of this two-phase process is to verify mathematically that the client’s private key and public key are indeed a valid key pair.
The goal of phase two is to verify the client’s private key. This phase begins with the host generating a random number challenge and sending it to the client. The client device uses the ECDSA signature engine in the ATECC108A to create a new signature using this random number and the client’s (secret) private key stored there. That new signature is then sent to back the host, which uses it along with the random number and the client’s public key (that was verified in phase one) as inputs to another ECDSA verify calculation. If that calculation succeeds, the host has then proven that the accessory (client) is real (i.e. contains a valid private-public key pair)
As you can see, the ATECC108A does all the heavy mathematical lifting, and Atmel provides what users need to make it easy to program the microcontroller to do its part of the process. The engineering and mathematics behind authentication using sophisticated algorithms may not be easy in theory, but that does not matter as Atmel makes it simple to implement cryptography without having to be a cryptography expert…. and that is the “REAL” point here.
The video (now with sound) will step you through the two phases of the ECDSA process described above.
So, in summary, the key aspects of asymmetric authentication with ECDSA include:
Increased security because asymmetric authentication does not need secure key storage on the host (only the client)
No need to update the host with secrets in the field. (can update the public key at any time.)
Uses the advantages of Elliptic Curve Cryptography (high security, short key, less computation)
Atmel CryptoAuthentication™ products such as Atmel’s ATSHA204A, ATECC108A and ATAES132 implement hardware-based storage, which is much stronger then 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, and other malicious threats. For more details on Atmel CryptoAuthentication products, head on over to its introduction page here.
The Internet of Things (IoT), as noted in previous Bits & Pieces articles, is really just a concept at this point because the “things” are undefined. As those “things” become more defined, the IoT’s things stop being just things and become something. So, the main question right now: What are those things going to be? Perhaps the IoT should more accurately be called the “IoXT”with “X” being the variable describing what that particular thing actually is. An example could be the Internet of wearable fitness trackers, factory robots, home automation, smart appliances, vehicle to vehicle communication, traffic control… well, you get the picture. The X can (and will) be many different things.
Clearly, for the IoT to be meaningful, the X must be identified in detail. The IoT must evolve from the ultra-general (i.e. “things”) to specific applications, components, systems, and integrated circuits, among others. There appears to be an emerging need for a classification hierarchy to describe the IoT as it differentiates and evolves. The Linnaeus classification model that is used in biology to describe living “things”, comes to mind. The same classification process can apply to silicon-based things and not just carbon-based things (beings).
Do you see the connection?
In a silicon-based classification regime, the term “IoT” would probably lie somewhere between phylum and family. Though it is not entirely clear exactly where yet, that does really not matter at this point; however, what matters is that engineers and product managers must push product definition to the genus and species levels for the IoT to ever truly matter.
In the early stages of IoT’s evolution, there could easily be a type of Cambrian explosion with the genesis of an insane number of new devices covering a wide spectrum of applications that from the truly inspired to the ridiculous. Economic Darwinism would later surely take over to narrow down the numbers overtime with many going extinct and others continuing to adapt into world-changing “things.”
Because the IoT’s silicon building blocks (i.e. the DNA of IoT) are getting into place, it will become very easy to create, modify, and adapt countless smart, sensing, secure, communicating devices. That ease of design is what is making IoT’s potential staggering, and why so many companies (especially silicon companies) are aggressively pursuing the IoT market.
As for the numbers, Gartner believes 26 billion devices will have connectivity by 2022, while Ericsson and Cisco both forecast the number being even higher at 50 billion units by 2020 and 2022, respectively. McKinsey Global Institute (MGI) expects IoT to have an economic impact of $2.7 to $6.2 trillion by 2025. Gartner notes that IoT suppliers will generate incremental product and service revenue exceeding $300 billion in 2020, resulting in over $1.9 trillion in global economic value-add in diverse end-markets. According to IDC, the installed base of IoT will be 212 billion by the end of 2020, with 30.1 billion of that being connected autonomous things.
The following chart from McKinsey Global Institute details their view of the impact from various economic categories. Note that healthcare is the largest, which makes perfect sense given the affinity of bio-sensors, continuous monitoring, wearable devices, and wireless communication. Subsequently, it is no accident that the major mobile platform and consumer product companies are pursuing bio-metric capabilities for wearable products.
With an increasing demand for medical care as populations age in Western countries, remote telemedicine to cover under-served populations makes great sense. Telemedicine could easily revolutionize medical care, and connected-sensing devices could revolutionize telemedicine. There is little to hold the growth of medical sensing and communicating networks back, especially since governmental agencies are on a mission to extend the provision of health care universally. Perhaps this is a perfect storm.
Health networks will be joined by networks of many types; each of those will be driven by the ability to create IoT devices from their four main building blocks:
1. Brains (MCU) 2. Wireless Communications 3. Sensors of Various Types 4. Security.
Devices with those fundamental IoT building blocks will differentiate on each of those four axes depending upon what they need to do. Some of the types of networks that could show up and drive the IoT’s evolution are noted below:
M2M: Machine to Machine network
V2V: Vehicle to Vehicle network
Personal medical network
PAN: Personal area network (wearable network)
Home entertainment network
Personal social network.
Home automation/security network
Personal fitness network.
Car infotainment network
Highway sensor network
Hazardous material sensing network
Smart appliance network
Augmented reality network
Multi-screen network
Energy management network
There are of course others, too.
One last thing: The dirty little secret of the IoT is that there probably cannot be such a thing as the Internet of Things if those things are not secure. That is where devices like Atmel CryptoAuthentication ICs play an important, if not catalytic role. Making sure that the nodes in the various networks are authentic and that the data being transmitted have not been tampered with is what CryptoAuthentication devices do. It is easy to see why security is important when there are billions of things keeping track of you, right?
So, authentication may in actual fact be the sine qua non (“without which there is nothing”) of the IoT.
Or, to put it another way: No security? No IoT for you.
One could say that any term with the word “thing” in it is vague — by definition. So, one could also assume that the term “Internet of Things” (IoT) is also vague by definition. Why is it that the tech and investor communities cannot define IoT? Maybe it’s because the IoT is indefinable — by definition.
In order to try and define something, it helps to analyze is compsition. There appears to be an emerging consensus among engineers, industry analysts, authors, tech executives, and others about the fundamental pieces that will make up the IoT; namely, the following items:
Intelligence
Communication
Sensing
Security
Ultra-low power drain and miniaturization are other aspects. So, perhaps a definition of the IoT today could be the following: “Low power, ultra-small things inside other things that sense more things and communicate (securely) between these things and other things.”
Obviously, that’s not a meaningful definition, and rightfully so, because the problem of defining the IoT is that today the IoT is not any ‘thing.’ Certainly not anything specific. The IoT is a generality — by definition. The only true specifics are the component pieces as noted above, and once those components are assembled and programmed, they differentiate into real things.
The point here is that the IoT is analogous to undifferentiated silicon stem cells, and these silicon stem cells can differentiate into a spectrum of specific, tangible, and identifiable…
The differentiated devices would address a wide spectrum of specific, diverse solutions for use in an even wider range of equipment and applications. Most of the eventual applications and solutions have not even been dreamed up yet. This is a similar situation to world of cellphones back in 2006 before anyone outside a certain city in Silicon Valley knew that a new device would eventually turn everyone’s phone into a smart black rectangle for years. IoT potentially will have similar power to transform the world on a large scale as well — far beyond mobile communications. We just don’t know exactly how the silicon stem cells will differentiate yet… but we will.
Each of the main IoT functions — communications, control, sensing, and security — will surely undergo micro and macro integration. Micro integration is putting the component subsystem pieces together into low power, small, integrated physical platforms. Companies with microcontroller, sensor, communication, and security IP will be best positioned. (Do any come to mind?)
Macro integration refers to creation of ecosystems. It is easy to visualize what those will be, like a medical ecosystem with biometric sensors of various types connected to one’s body and the cloud through smartphones. Another could be an automotive ecosystem that senses the location, speed, and direction of your car and other cars near you and reports that data to each other (V2V communications). One more automotive ecosystem could sense and control the systems inside a car, such as entertainment, information, and mechanical. Yet another would be mobile ecosystems that include wearable products that sense biometrics, interface with automotive and home entertainment systems, control home automation, perform electronic transactions, and a plethora of other functions. It is easy to envision a world where mobile handsets, tablets, glasses, watches, and other things that people wear or carry automatically interact with sensors and screens sprinkled throughout the environment. Some refer to the sensors spread all around as “sensor dust.” Now you can see why.
The irony is that by the time that the component pieces of the silicon stem cells differentiate into specific things, they cease being just things. And that means that the IoT starts to fade away, product by product.
To put this in a Dr. Seuss sort of way, “When a thing starts becoming something, it starts stopping being a thing.”
To be a leader in the post-IoT universe where things are not just things anymore, silicon providers must put all pieces in place and stimulate differentiation before the other guys do. It’s all about vision… but that is a topic for another day.
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:
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.
