The ATSHA204A includes a 4.5Kb EEPROM divided into 16 slots. This array can be used for storage of keys, miscellaneous read/write, read-only, password or secret data, and consumption tracking. Access to the various sections of memory can be restricted in a variety of ways and then the configuration locked to prevent changes. Access to the chip is through a standard I²C interface at speeds up to 1Mb/sec.
The Saleae logic analyzer has no problem keeping up with these fast speeds. ATSHA204 device supports either a single-wire interface (SWI) or two-wire interface (TWI) depending on the part number.
When you drop the right dll into the Saleae program directory, you will get a menu callout for the Atmel SWI (single-wire-interface).
You use a dll to add the single-wire debug analysis to the Saleae, while the two-wire interface debugging can be handled by the I²C menu pick. So check out the Saleae logic analyser. My buddies tell me it is worth every penny compared to the cheapo stuff on Seeed Studio since the mechanical engineering is so much better on the Saleae, and the quality of the test leads and the capability of the software, which is a huge part of what a logic analyzer does for you these days. It’s one thing to see highs and lows on the screen, but it’s really nice when the logic analyzer tells you what characters are being sent on the wire or wires.
The Saleae logic analyzer comes with high-quality cables and clips.
So check out the Saleae logic analyzers and be sure to secure your systems with a hardware-based security chip. When it comes to securing our intelligent, connected world, there’s no need to fear… Atmel CryptoAuthentication devices are here!
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.
HackADay’s Brian Benchoff was lucky enough to catch up with Josh and asked him to break down how the nifty device works.
“If you need to add security to your project or you want to learn more about embedded security the CryptoCape adds encryption and authentication options,” the Maker added.
As its webpage notes, the CryptoCape functions as the BeagleBone’s first dedicated security daughterboard. Known as a BeagleBone Cape, the device attaches to the expansion headers of the BeagleBone and “adds specialized ICs that perform various cryptographic operations which will allow you to add a hardware security layer to your BeagleBone project.”
Previously discussed on Bits & Pieces, the CyrptoCape is packed with hardware, including 256k EEPROM with a defaulted I2C address (plus write protection), a real-time clock (RTC) module, a trusted platform module (TPM) for RSA encryption/decryption, an AES-128 encrypted EEPROM, an Atmel ATSHA204 authentication chip that performs SHA-256 and HMAC-25 and an Atmel ATECC108 that performs the Elliptic Curve Digital Signature Algorithm (ECDSA).
The reasoning behind the developer’s choice to use the SHA-256 Authenticator? “It creates 256-bit keys that can be used in keyed Message Authentication Codes (MACs), or HMAC, to prove the authenticity of the device.” In addition, the authenticator allows the device to “implement an anti-counterfeiting system with the exchange of nonces and MACs between other embedded devices.”
If you are interested in boosting the security of your Maker project or learning more about the CryptoCape, you can head to the product’s official SparkFun page here.
At last month’s MIT Technology Review Digital Summit, PubNub CEO Todd Greene discussed the importance of connecting Internet of Things embedded devices on a reliable and secure realtime network. CPU, battery, and bandwidth consumption, as well as security are all paramount considerations that need to be taken into account when connecting low-powered embedded devices.
You’ll find that when developing and networking Internet of Things devices in the lab, connectivity is fairly seamless. You may have a few embedded devices connected to a backend server, so latency isn’t an issue.
However, deploying that IoT app on a global scale, to thousands or even millions of users simultaneously, is a whole other ball game. Unfortunately, the Internet isn’t just one big network, but rather is composed of an infinite amount of heterogeneous networks, including proxy servers, firewalls, cell towers, and WiFi networks, all slower and faster than one another.
As a result, there are 5 major challenges when it comes to Internet of Things connectivity. Keep scrolling down to see them, or watch the video below:
At PubNub, we think a lot about IoT connectivity and how we can make it as reliable, secure, and fast as possible. So to make PubNub the best network for connecting and signaling between Internet of Things devices, we first had to understand the challenges of doing so. Presenting the 5 challenges of IoT connectivity:
1. Signaling
When connecting IoT embedded devices, you need to start with bidirectional signaling to collect and route data between devices. Whether it’s embedded devices talking to a server to collect data, or devices signaling one another, you need to stream IoT signals and data quickly and reliably. You need to be 100% sure that that stream of data or signal is going to arrive at its destination every time.
2. Security
Security is a huge umbrella, but it’s paramount in Internet of Things connectivity and should be forethought, not an afterthought. For example, what good is a smart home if anyone can open your garage door? Here are three considerations for IoT security:
Authorization: When publishing or subscribing to stream of data or IoT signal, it’s essential to make sure that the IoT device or server has proper authorization to send or receive that stream of data.
Encryption: You need end-to-end encryption between devices and servers.
Open ports: An IoT device is dangerously vulnerable when it’s sitting and listening to an open port out to the Internet. You need birectional communication, but you don’t want to have open ports out to the Internet.
3. Presence Detection
Who’s there, (or in terms of IoT, what device is there)? It’s important to immediately know when an IoT device drops off the network and goes offline. And when that device comes back online, you need to know that as well.
IoT embedded devices are small and expensive, so CPU and power consumption need to be considered. When you have hundreds or even thousands of devices sending data and signaling one another, it takes a toll on power and CPU consumption. You need to maximize efficiency while minimizing power and CPU drain.
5. Bandwidth
In addition to power and CPU, bandwidth consumption is another challenge for IoT connectivity. Bandwidth on a cellular network is expensive, especially with hundreds of thousands of IoT devices on a network sending request/response signals to your server.
That’s a huge server issue and a requires a large scale server farm handling all this data. You need a lightweight network that can seamlessly transfer data between devices and servers.
Connecting IoT Devices with PubNub
Connecting devices in the lab is one thing, but once they’re out in the wild, it’s a whole new ballgame. So where do you start? Having a scalable IoT network to connect embedded devices and servers is especially critical for IoT applications with a large user base.
These are the types of Internet of Things challenges we’ve solved at PubNub. With over two hundred million connected devices connected to our global realtime network in fourteen data centers, we average 50 to 60 thousand transactions per second, peaking at over 3 million. PubNub is used to stream data and signal for hundreds of different IoT uses cases including:
Automotive:Connected cars need a realtime communication layer to stream data and signal between their fleet, dispatch, and the consumer on the app. Examples: Sidecar, Lyft, Easy Taxi, Gett,Zoomy
Home Automation: A realtime network can be used to signal and trigger actions for smart devices and home automation solutions. Examples: Insteon, Revolv, Vivint
Wearables: IoT wearables require a low latent, lightweight network to stream data between the device and a server. Battery, CPU, and bandwidth consumption are all important considerations that must be taken into account. Examples:3rd Eye
By 2020, it’s estimated that there will be between 20 and 30 billion connected devices on the Earth. As a result, how we connect those devices should take precedence as the IoT field grows exponentially.
