Chapter Goal: Understand the Basics of IOT Computer Security
Topics Covered in This Chapter:
Why are we worried about computer security on the IOT?
Hackers are everywhere. They attack our banks. They attack our stores (think Target). They are trying to attack our infrastructure (power, water, sewer, etc.). Now, with the advent of IOT, they have a gateway into your home.
Guess what? They are going to attack your IOT device. You may think you are safe because you are not very important (see no. 2 below - not being important is not a good defense); they will attack.
Understand one very important fact. Hackers rarely attack something specific. They use programs to attack thousands and tens of thousands of things at a time. Then they just wait for the results. If you are exposed on the Internet, they WILL find you. Your job is to make sure they can’t do anything important about it.
Who are the hackers ? There are the black hat people trying to make money from attacks or ransomware. There are nation-states doing this (and not just the United States, China, and Russia, either. North Korea and many other nations have programs). It’s just not that expensive to do and the Internet gives you access to anywhere.
There are white hat hackers that are trying to find and fix security issues in programs and on the Internet. These people are trying to actually help the problem.
Oh, and then there is a whole other category of people that are somewhere in the middle. Gray hats if you like. These are people that are not really sure what they are doing. People can download hacking programs and run them without having any idea what is going on. These people are called “Script Kiddies” and can cause all sorts of damage on purpose or not.
The author has run a computer security company and has taught computer security and information warfare at the undergraduate and graduate level at several universities. In this chapter I am taking a different look at computer security than most technical books. While I am discussing methods of encryption and authentication, I am also taking a top-level view of the problem and a realistic view of what can and can't be done with the small computers that make up the IOT.
With that, let’s start with my thoughts about the Top Five Things to Know About IOT Computer Security.
“What? That doesn't make any sense. My application only has 200 lines of code in it and I can see that it is secure!”
There are two things to consider here . First of all is that those 200 lines have been compiled by a compiler that has 100,000+ lines of code. The operating system you are running on has at least 25,000 lines of code (yes, even an Arduino) and millions of lines of code in a Raspberry Pi or Windows machine. Your 200 lines of code interact with tens of thousands of lines of code. You don't know how big your own program is. You don't know about the compiler. You don't know about the operating system. Yes, some micro-controllers allow you to set up everything, but in today’s development systems this is the exception, not the rule.
The second thing to consider is a proven theorem from Matt Bishop’s excellent book [Computer Security: Art and Science, Matt Bishop] on Computer Security: “It is undecidable whether a given state of a given protection system is safe for a given generic right.”
What does this mean? It means that “You can tell if your computer program is insecure, but you can't know if it is secure.”
An IOT system that relies on secrecy of the implementations or components of the system is not security. Obscurity can be part of a defense in-depth strategy but should not be relied on to provide security. Yes, someone can take your design and reverse engineer it and find out everything about it. Using a different port for SSH doesn't even slow down hackers these days. People can snoop on what you are sending and figure it out. Your system needs to rely on the key to your system and not the structure of the lock.
Every moment that your IOT device is connected to the Internet or the network is a moment that it can be attacked. Keep your device off the network as much as possible. This saves power, too, which is often a defining design criteria.
Does a hacker care that the temperature in your aquarium is 85 degrees? Probably not. Do you want them to be able to change the temperature in your aquarium? Probably not. Do you want your front door lock (that is connected to the Internet?) to be secure? Yes, all the time. And no, you don't want hackers to be able to tell if the door is locked or unlocked. Just remember all the encryption in the world doesn't matter if a person has the key. In this case, either a physical key or a cryptographic key. Both can open your door. In our door lock IOT application, we must keep the key safe.
Confidentiality is defined as the concealment of information or resources. Keeping things secret (like keys) so the hackers can't use them.
Integrity is defined as the trustworthiness of the data or resources. Making sure that a hacker can't forge the directives to open your house door or car doors. Oh, that happens. Not good when it does.
Availability refers to the ability to access information or resources when required. If someone is doing a Denial of Service on your house or your Internet provider, you can't get to your door lock. Yes, even with an Internet-connected door lock, you should take your physical key along. And don't set the access code to your birthday.
In this chapter, I am going to talk about some IOT applicable techniques for addressing all three parts of the Triad. The CIA Triad is shown in Figure 7-1.
Figure 7-1.The CIA Triad
The dangers of computer insecurity depends on your information type and actuators of your IOT device. First, let’s talk about information types.
The danger of hacking your device to gain information completely depends on the “value” of the information, both in a local sense and in a temporal sense. For example, a sensor reading the temperature in your closet probably isn’t worth very much at any one time and knowing the temperature of your closet ten hours ago (temporal value) is probably even worth less.
Going the other direction, transmitting your password for your WiFi in the clear from an IOT device is a valuable piece of information; and in most systems, it is still valuable from ten hours in the past.
So, the value of information has two main components. Is the information valuable at the time of production, and does it continue to remain valuable as time advances?
In a real sense, the ultimate risk of data disclosure can be described as the value of the information disclosed. In the recent Target store information loss, it was expensive. The value of the information lost (credit card and customer information) was high, not only in fraud, but in fraud prevention (replacing all those cards) and eventually cost the CEO of Target his job. Now, note, because of these remedial actions, the time value of the information lost declined rapidly after the disclosure. What was the value of the information lost to Target? Somewhere around $10 or $15 million. While that might seem like a lot of money, it was less than 1 percent of the company’s revenues.
After reimbursement from insurance and minus tax deductions, it was probably even less. The startling conclusion after looking at the reports is that big data breaches don’t cost all that much to these companies. Similar numbers and costs apply to the Sony and the Home Depot data breaches. The costs just aren’t material to these large companies.
All the consumers inconvenienced by getting new credit cards, or having fraud on their card, or their identity stolen would probably feel differently.
On a much smaller scale, I have experienced this on a more personal level. In 2000, I started a bank (yes, a real FDIC-insured actual bank) and have served on the board of directors since then. Naturally, I have served as chairman of the Technology Committee. It’s been interesting.
In the mid-2000s, our Visa payment provider was compromised and we had a small fraud problem with the compromised cards (around $2,000) that the regulations say we were responsible for. We also had about $10,000 of cost in issuing new cards. We got a small reimbursement from our cyber-insurance but we had to go after the payment provider. After six months that went nowhere (they didn’t want to pay anything even if it was clearly their fault), we gave up. So who really pays in this case? You, the consumer, with higher costs passed on to you.
Most academic papers focus on the cost of data loss and exposure in large- and medium-size enterprises. There is surprisingly little work about the cost of information loss and exposure in IOT.
So, how do you assign value to information in the IOT? You look at what it means to the user to have the data lost or compromised and estimate a financial (or personal) harm to the user. The companies above focus on cost to themselves. In the IOT you need to look at the cost to the end user.
What happens if someone hacks your front wireless door lock? How about your TV? According to reports, the Samsung Smart TV listens to you even when you aren’t talking to the TV. They warn you not to discuss sensitive information around your TV. Good grief. When it was disclosed that it was possible to hack into the Samsung Smart TV camera on the top of the set, they suggested putting black tape over it or pushing it into the set with a pencil. Samsung is a $180 billion a year company. You would think they would put a little more into computer security.
Gartner forecasts [ www.gartner.com/newsroom/id/3165317 ] that there will be 6.4 billion IOT “things” connected by the end of 2016. And they further forecast that by 2020 it will be 20 billion “things” connected. Using the rough numbers of the amount Gartner forecasts that will be spent on the global IOT security market (about $7 billion in 2015 and increasing to $30 billion in 2020), we come up with an interesting number. The amount that will be spent on securing the IOT will be about $1 per IOT device. Now this is something we can use in our budgeting for IOT development. My gut feel is that is about right.
Back to the value of information. In 2016, 5.5 million IOT devices get connected every day. These devices being connected include cars, kitchen appliances, smart TVs, wristwatches, toys, medical instruments, etc., etc.
When an IOT device gets connected, it needs to be protected.
Computer security is a complex topic with lots of interactions between different systems and subsystems in even a simple transaction from an IOT device to a server across the Internet. We are going to now return to the CIA Triad (Confidentiality, Integrity, and Availability) and see what we can do with each of these concepts in practice on these small computers.
Confidentiality is defined as concealment of information. As was mentioned earlier, you can almost always get information out of device if you have physical access to the device. What we are focusing on in this section is protecting the information transmission channel rather than the physical IOT device itself.
Note from no. 2 above, obscurity doesn’t count as far as computer security goes. If we are transmitting valuable information, then we need to encrypt it using cryptographic techniques. What is cryptography? Cryptographic techniques include uses for all of the CIA Triad, but here we are going to focus on encryption that is a subset of these techniques.
Discussing cryptography and encryption techniques can easily fill an entire book so I will stay away from the math and focus on the application. The one thing we do need to discuss is that modern cryptography is very heavily based on math and computer science methodologies. All of these techniques below can be broken based on the theoretical considerations of the algorithms, but it is impractical to do so by any known techniques. That makes these techniques “Computationally Secure.” Someday in the future they may be able to read your thermometer, but will it be worth it? Depends on the value of the information.
There is one important thing to realize about encryption and cryptography. These algorithms tend to be computationally expensive in terms of amount of CPU clocks and RAM memory to do these calculations. Remember that IOT devices don’t have a lot of CPU clocks or a lot of RAM memory. Therefore, use the minimum amount of these techniques to protect your data. You need to be smart to save battery and RAM space.
There are basically two ways for Arduino to communicate with external devices. You either have a network connection (Ethernet, Bluetooth, WiFi, Zigbee, or other networks), or you have a serial connector (USB, straight serial). While the techniques described in this section are applicable to both kinds of connections, we will focus on the network-type techniques. For the Arduino I am going to focus on using AES. While this next example is run on Arduino Mega2560, it can also be run on an ESP8266 with minimal changes.
AES is what they call a symmetric block cipher used by the U.S. government to protect classified information. It’s pretty good encryption and can’t be broken at the writing of this chapter by brute force attacks. However, as Bruce Shinier has said, “Attacks always get better; they never get worse.”
Following are just some of the AES libraries available for the Arduino:
We are using an Arduino Mega2560 (shown in Figure 7-2) instead of an Arduino Uno because the Mega2560 has 8K bytes of SRAM available versus 2K bytes in the Uno.
Figure 7-2. Arduino Mega2560
We are going to use the Davy Landman library for our examples. To install into your Arduino library, follow the directions in the README.md file. Following is an example of how to use the AES library in an Arduino program. You can substitute any Arduino for this example. However, it does not compile under the ESP8266 Arduino IDE unless changes are made to the AES library itself.
//
// AES Library Test
// SwitchDoc Labs
// February 2016
//
#include <AESLib.h>
// 256 bit key for AES
uint8_t key[] = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31};
void setup() {
Serial.begin(115200);
}
void loop() {
// put your main code here, to run repeatedly:
// 16 bytes
char data[] = "01234567890Hello";
int sizeOfArray;
int i;
sizeOfArray = sizeof(data) / sizeof(char);
Serial.println();
Serial.print("data to be encrypted (ASCII format):\t ");
Serial.println(data);
Serial.print("data to be encrypted (Hex format):\t ");
for (i = 0; i < sizeOfArray - 1; i++)
{
if (uint8_t(data[i]) < 0x10)
Serial.print("0");
Serial.print(uint8_t(data[i]), HEX);
}
Serial.println();
// Now we encrypt the data using a 256 byte AES key
aes256_enc_single(key, data);
// print the encrypted data out in Hex
Serial.print("encrypted (in Hex):\t\t\t ");
for (i = 0; i < sizeOfArray - 1; i++)
{
if (uint8_t(data[i]) < 0x10)
Serial.print("0");
Serial.print(uint8_t(data[i]), HEX);
}
Serial.println();
// Now decrypt the data and print it out
aes256_dec_single(key, data);
Serial.print("decrypted:\t\t\t\t ");
Serial.println(data);
}
Note the key given at the beginning of the program. This 256-bit key is what you need both to encrypt and decrypt the data. Granted, this is not a very good key in our example.
Below is an example of the results of the program:
data to be encrypted (ASCII format): 01234567890Hello
data to be encrypted (Hex format): 303132333435363738393048656C6C6F
encrypted (in Hex): 438693C632D91AF2283651F416BBA61E
decrypted: 01234567890Hello
This is the single piece of secret information. Both ends of the communication channel need to have this key for AES to work.
Key management (how to send these keys around) is a key topic of IOT computer security design and will be discussed later in this chapter.
Looking at this program, you could see how you could decompile this code and retrieve the secret key. This is an example of why physical access to the device can often lead to the ability to hack the device and then the network of devices.
How fast are these libraries on an Arduino? Based on a 16MHz ATMega328, a 128-bit AES key can generate about 27,000 bytes per second. Using a 256-bit key gets you about 20,000 bytes per second.
Now that is full bore CPU usage, so if you have other things to do with the processor (as is almost certainly the case), you won’t be able to make these data rates continuously.
Note that AES libraries are already built into the firmware for the ESP8266, but as of the writing of this chapter there really are no complete examples of how to use them and the documentation is very sparse.
The Raspberry Pi has a far richer set of cryptography libraries available in the operating system or as easily available downloads. For example, if you are communicating using web requests (between Raspberry Pi’s or Linux-based computers), you can use SSL to encrypt the traffic between the two nodes. It is highly standardized, and if properly configured is strongly secure. Why don’t we use SSL on an Arduino or ESP8266-based system? Two reasons: first, memory / processing power limitations; and second is the problem of distribution of the certificates necessary for secure SSL links. This is another variant of the key distribution problem.
The same AES-256 functions are available on the Raspberry Pi so they could be used in communicating with an Arduino. However, this method is a long way from the full SSL implementation used by modern web browsers and computer (think https:// instead of http://).
The Spaniakos AES encryption library as cited above under the Cryptography on the Arduino section is also available for the Raspberry Pi.
Note that there are hardware implementations of AES starting to appear for Arduinos and Raspberry Pi.
Integrity is defined as the trustworthiness of the data or resources. Note the difference between Integrity and Encryption. When I speak of integrity, I am speaking of making sure that the directives or data sent to my IOT device has not been changed en route and that I know for sure who sent it. The directives or data may or may not be encrypted.
Looking at this from a value-of-information perspective, this means that we don’t really care if a hacker looks at the data (I am turning up the heat in my house), but we use integrity to make sure that a hacker cannot forge the directive or data and that the hacker cannot change the data itself.
There are many ways of using cryptographic algorithms for establishing the integrity of the contents of the message and establishing who sent the message.
Establishing that the message has not been changed en route can be done by using what is called a cryptographic hash on the message. In concept, you take each byte of the message and by using a cryptographic algorithm, you can determine that the message has not been changed – with a very, very high degree of certainty.
In order to prove that the message has not been altered on transit, you will need to send the message + the hash across the network. Much like the encryption example above, you need to take your message and cryptographically hash the message to generate the hash codes. We will use the fork from Cathedrow library [ https://github.com/maniacbug/Cryptosuite ] for this example.
However, the libraries required some tweaking to make them work in the newer versions of the Arduino IDE, so I have included them in the download of this software as additional tabs. This will work with an Arduino board and an ESP8266 board.
// SHA256 Hash Test
//
// For both the Arduino and ESP8266
// SwitchDoc Labs
//
// February 2016
#include "sha256.h"
void printHash(uint8_t* hash) {
int i;
for (i = 0; i < 32; i++) {
Serial.print("0123456789abcdef"[hash[i] >> 4]);
Serial.print("0123456789abcdef"[hash[i] & 0xf]);
}
Serial.println();
}
void setup() {
Serial.begin(115200);
Serial.println("SHA256 Hash Test");
Serial.println();
}
void loop() {
uint8_t *hash;
Sha256.init();
String hashMessage;
int i;
while (1)
{
hashMessage = "This is a message to hash-";
hashMessage = hashMessage + String(i % 10);
Serial.print("Hashing Message: ");
Serial.println(hashMessage);
Sha256.print(hashMessage);
hash = Sha256.result();
printHash(hash);
Serial.println();
delay(5000);
i++;
}
}
Hashing Message: This is a message to hash-2
f2a47cefff87600aeb9089cf1f11a51b833ccdd91b808df75b7238fc78ba53f2
Hashing Message: This is a message to hash-3
5d135bc35a33004cad4c4ed37fc0011c1475f09c6ddd7dec01c348734e575f41
Hashing Message: This is a message to hash-4
fe1aa898ab0e041d1ce4539b388439c75a221efab0672896fc5e14b699c01492
If the hashed message is changed, the SHA256 hash will change. You can say that the message has not been changed en route to your device. Note we have no cryptographic key to exchange. SHA256 will work the same everywhere.
Proving something has not been altered in transit will tell you it is good. However, what if we just have a slightly corrupted message? This could be caused by noise in the line (think satellite communication). If you want to correct errors in a message like this, a whole other set of algorithms is used. Reed-Solomon error correction codes are a great example of these. You can correct the data, then decrypt it. Obviously, you need to encrypt the message first and then put these codes over the top of the encrypted data to make your communication channel more reliable. Reversing the order (encrypting the Reed-Solomon code) makes no sense and will not provide error correction.
The Raspberry Pi code is very similar.
So, this seems pretty straightforward. What are we missing? We have the proof that the message has not been changed. Great. Proof of data integrity.
However, we have not proved that the data has not been forged using a man-in-the-middle attack. Now we have to look at the last part of data integrity. Proof where it is coming from, or in other words, non-repudiation.
Non-repudiation is usually based upon some variation of Public/Private Key Encryption.
It works like this. Bob has a private key, only known to him. He also has a public key that he gives to anybody who wants to communicate with him. When Bob wants to send a message to Alice, he encodes the message with his private key and sends it to Alice. Alice uses the public key she got from Bob to decrypt the message. If it successfully decrypts, then Alice knows that the message came from Bob.
So, using this public/private key method, we can encrypt the message and prove it came from Bob and is unaltered. Reversing the procedure, we can send a message to Bob from Alice safely.
OK, looks perfect. What are the complications? Once again we are back to key exchanges. Both our IOT server and the IOT device have to have private keys and publish public keys to the server. This does sound like a lot of work. And it is. Those more-sophisticated readers will notice that this sounds a lot like SSH/HTTPS. Correct. And as noted above, those are big libraries for small computers, although the Raspberry Pi can handle it, the Arduino class of processors really can’t. The ESP8266 is barely able to do this (and does it for their over the air update option) but they are not distributing keys. They update a one-way communication. For bidirectional communication links, you need keys for both directions.
There is a whole additional level of complexity laid on top of this. Certificates must be traceable to a known trusted authority to prove the system hasn’t been compromised.
Showing examples of the public/private key software is well beyond the scope of this book. Some keywords to look for are “Digital Signature, Diffie-Hellman, and RSA Public Key Encryption” when searching for this technology. A good example of a system showing this kind of a system between an Arduino and a Windows PC is available at this link: github.com/arpitchauhan/cryptographic-protocols-arduino-and-PC/
The overall methodology used is as follows:
Public keys are exchanged securely between the two devices (note: both have their own private key).
After the Public keys are exchanged, you can transfer a key for AES encryption.
Now the devices can communicate securely and safely using AES as in the example above.
An important thing to remember is public/private key encryption is much more computationally expensive than AES encryption. This is why you exchange your AES keys with this scheme and then just use AES to send the data in normal operation.
There really isn't a lot of difference between an attack to deny you service (DOS), the Internet going down, your wireless router rebooting, or your microwave oven going crazy. All of these things disrupt your communication path to your IOT device.
One thing that commercial wireless IOT devices are especially vulnerable to is the inability to talk to the server because of electrical noise in the environment whether generated by error or on purpose. When you are planning your IOT device, you need to make sure you design it so your device can handle a disruption of communication service, whether it is done on purpose or by equipment failure. There needs to be some method for telling the user or consumer that you have a fault.
How does the military get around this? It uses complex schemes like frequency hopping radios, large amounts of radiated radio power to “burn through” the noise, and big antennas. These are not techniques that are cheaply available to our IOT devices.
Key management is a hard problem. Configuration management of IOT devices is difficult. From the sections earlier in this chapter, we need to have a shared key to do AES256 encryption to keep our communication confidential. We also need keys to prove that the message has come from the correct person or server.
Remember that ANY time your IOT device is communicating with the Internet or the local area network, there is a possibility of compromise.
There are two approaches to key management on IOT devices. The first is by using hardware key management.
Companies like Infineon build chips that include private and public keys that can be used to build networks of IOT devices. You can establish trusted certificates (linking to a trusted certificate authority) at the time of manufacture and then establishing a set of software protocols for using these keys after deployment. As the process and chips become less expensive, I believe we will see more and more of these types of systems deployed. At the writing of this book, these chips are not cheap. Using one will roughly double the price of your IOT device in many cases. What about physical access to these devices? Yes, you can compromise a device by taking it and tearing it apart (and I don’t just mean taking the screws out. I’m talking about removing the plastic from the chips and going through the chip with a microscope. Remember our discussion about the value of information? It’s probably not worth doing all of this to compromise your thermostat or toaster.
The second method is to use software to distribute the keys during configuration (or even during manufacturing). These methods in general are called PKI (Public Key Infrastructure).
Generally, many IOT devices are more vulnerable to attacks than normal servers, PCs, and smartphones because they operate with embedded software (firmware) that has been developed without online security in mind. There are many examples of really bad software flaws that can include back-end management with default passwords that are easily found on the Internet and non-encrypted communications. People are actively hacking into things like routers and other connected devices and using them in DOS (Denial Of Service) attacks. Think of our LightSwarm devices in a previous chapter. You could program them all to start sending messages as quickly as possible and create your own DOS attack. During the development of the LightSwarm, I inadvertently did that very thing. I overwhelmed the Raspberry Pi server by sending messages all at once, as quickly as possible.
Another real issue with IOT devices is that the internal IOT device firmware may not be updated for years (or the company may go out of business) and the infrastructure for updating these devices just doesn’t exist or not.
The use of current PKI methods are just impractical to scale to the upcoming multiple billions of IOT devices projected to be connected to the network. Because of this many manufacturers take short cuts to secure their devices. For example, all of the IOT devices may share a single key (either an AES encryption key or a single public/private key pair). This method does supply a significant amount of security, but if the single key is compromised (as has happened many times in the computer industry. Think Sony and Microsoft) then the entire network is open to hackers.
The industry has the mathematic and technical tools to protect the IOT. What we don’t have is a simple and secure method for distributing the keys to all of the IOT.
This is a problem that has not been solved yet and probably won’t be before we deploy another few billion computers.
According to one pundit (actually me), the two biggest problems for keeping IOT devices safe are the following:
Being able to update your firmware is key to avoiding obsolescence and to recover from flaws that come to light after deployment of devices. This is one very important channel of information that needs to be cryptographically secured, both from a data integrity point of view and to make sure it is only being updated from where it should be updated from (non-repudiation). The techniques above can be used to do these very things.
If anybody can figure out how to fool your updating system, the person can reprogram your entire system.
Why would someone want to break into your thermostat? To provide an entrance to your network. Remember the Target data breach I talked about earlier? That was initiated via a cooling system maintenance application. They got in the network via the air conditioner.
The IOT represents a huge opportunity to improve people’s lives and experiences. With great power comes great responsibility. When you design your Internet Of Things killer application and device, design security in from the beginning. Don't tack it on at the end.
Watch the news. In the near future, you will see articles about people (and programs) hacking into cars – oh wait, they are already doing that. You will see articles about people hacking into hotel door locks – oh wait, they are already doing that. And you will see people hacking into your home thermostat – oh wait, they are already doing that, too.
Following is an example from an Amazon review:
The man wrote that his wife had left him for another man and then moved her new man into their old home that they had shared, which had a Honeywell WiFi thermostat. The ex-lover could still control the thermostat through the mobile app installed on his smartphone, so he used it to change the environment for the couple now living in his old house:
“Since this past Ohio winter has been so cold I’ve been messing with the temp while the new lovebirds are sleeping. Doesn’t everyone want to wake up at 7 a.m. to a 40 degree house? When they are away on their weekend getaways, I crank the heat up to 80 degrees and back down to 40 before they arrive home. I can only imagine what their electricity bills might be. It makes me smile. I know this won’t last forever, but I can’t help but smile every time I log in and see that it still works. I also can’t wait for warmer weather when I can crank the heat up to 80 degrees while the lovebirds are sleeping. After all, who doesn’t want to wake up to an 80 degree home in the middle of June?”
Now granted, that isn’t really a technical hack – more of a social engineering experience, but it shows what can be done with these little systems.
Your Nest Thermostat (insert your own IOT example here) can be a gateway into your home. In many systems, like the Nest Thermostat, you are only one password from being hacked. Makes a good argument for good passwords on ANY system that is exposed to the Internet.
And remember that all devices are vulnerable to being hacked with physical access. So make sure you keep your “real” metal keys safe, too.
The IOT is an area of active research and now active deployment. Nobody in the industry has yet found the “killer application” that will take the IOT to mass consumer deployment, but it is just a matter of time. If you took the time to build the IOT projects in the previous chapters, you now have a basic set of skills to prototype and innovate in the IOT space. There is no better way of learning a new set of abilities than actually building things. That is the mantra of the Maker Movement.
Following are some of the IOT projects that I am currently working on. They are good suggestions for further work on your own, if you are so inclined.
OurWeather - a no-soldering required IOT Weather Station kit for ages 8 and up
Building IOT Devices using Grove Connectors for easy and fast prototyping
Another idea is to regularly scour the following web sites for new devices and new sensors:
When I see a new sensor that is interesting, I jump on it, build a project, and publish it in either magazines or on my blog. There are new IOT base devices (like the Adafruit Huzzah) coming online every day. If you see one and you are interested, buy it and build something. Come visit my blog and join the conversation at www.switchdoc.com .
