NDC2015 - Is it possible to secure micro-controllers within IoT

All right, guys. Well, hopefully now you're all versed up on BLE. So, great little protocol. I'm actually a representative of EvoThings, and we actually do a lot of things with BLE as well. So we have a small developer kit where we try and help developers build mobile apps. We utilize a lot of technologies like BLE, XMPP, standard TCP/IP. But one of the things we've been looking at over the last few months, mainly because there's been a little bit of a lack of traction in this area, or a lot of interest I think in the last 1 or 2 months, is the idea of IoT and security. So what I wanna try and do today, it's, I have about 46 slides. I'll try and get through them at a relatively quick pace. I do have the slides on SlideShare, right? So you can just search for my last name and slide show or just come by the booth, I can give you a link. But I think what I want to do today is try and go quickly over the main issues that are out there in terms of IoT security. I'm sure a lot of you guys already know a lot of the concerns. The purpose of what we did on this presentation was really to test how feasible it is or the reason why we should make an argument as to why developers should and products should actually include security in their products. And basically though, we just wanted to analyze, you know, is there a reason why there is a lack of security? And, you know, the end result is that it's not. So, and basically, and then I'll go through a couple of things that are happening. If you're a developer and you need to know what's happening specific to some of the low-powered embedded solutions, I do have a few libraries I can reference. And the last one's food for thought. And we'll see where that goes and maybe it opens up some discussion if we have time. But if not, you can always come visit us at the booth. All right, so first thing is why is it such a hot topic? HP did a beautiful report about a month and a half ago, and basically they recognized that a lot of the commercially available products in the market are totally lacking security, right? So they found about 250 vulnerabilities looking at webcams, thermostats, power outlets, etc. 76% of the devices didn't even use encryption for their network communication. So you can see that it's totally open. Someone can just hack into your public or your open Wi-Fi network and start controlling a TV or fridge. And you can imagine the fear that was put in people's minds with this. 80% failed to use strong passwords. So if you're used to using old Netgears, the old admin pass, if you go around some neighborhoods that aren't really technically advanced, you can hack their Wi-Fi points and do whatever you like. And the last one, which is interesting, which I think most people have probably overlooked, is the idea that a lot of companies have failed to really provide adequate protection to secure their firmware. So if you were able to get root access to the device, you could simply upload a new firmware. I had a couple of examples, and as I said, I reduced my slides from about 50 or 60 down to 46. A good example was Foscam. So Foscam was a baby monitor and in Utah some Russian hacker hacked into it and started screaming at the baby saying, wake up baby, wake up baby. Right? It's real, right? Basically their fault was they allowed the ability to reflash a Linux kernel and then you could dump the memory system and you can get all the passwords, you can write your own firmwares. Absolutely crazy. This is a $20 webcam on the market right now. Dick Cheney was so paranoid about security in IoT, he had his pacemaker's wireless functionalities disabled. There was a hacker who was going to announce it at Black Hat, but he mysteriously died 2 weeks before the conference. So you can probably think there's something wrong with that. The last example I had was actually with Google Nest, which is actually the 60%. Even though they got physical access to the Nest, they were able to pop it open, and hook into the USB ports of the device and reflash a custom firmware, right? So even some of the bigger players right now are having struggles with this. In Sweden, just 3 days ago, I was flying back from Australia, so I'm jet-lagged, but I'm ahead of you guys, so I'm all good. It's a morning presentation. So this was very interesting. There was a report in Dagens Nyheter in Sweden, And basically they exposed that there's one security firm providing infrastructure. So basically police stations, transit stations like bus stations, train stations, churches, all using the same infrastructure. Someone figured out how to hack it. They can just change the time on the church and ring the bells, right? Apparently they could also open sensitive doors. So they say, look, you wanna get access to that room? Open, right? So the police station actually, I think half an hour after the report went out, pulled the plug, right? So this is really getting serious and, you know, it's getting— this is the whole thing about IoT and security getting a lot of exposure right now. So it definitely needs to be something we did solve. So why is it an issue? First issue is we're right at this peak of this hype cycle, right? So everyone wants to talk about IoT. They want to get involved with IoT. Secondly, we've got a lot of microcontrollers hitting the market. Like you have your Arduinos, your Raspberry Pis, you have your Beaglebones, you have these custom embedded solutions. There's probably about, you know, 400 to 500, you know, well-known devices out there. Some of them range from running 1 GHz CPUs all the way down to 8 MHz, right? So what's happening in the market right now? due to this big hype is, I like to call it companies making land grabs, right? So they're saying, you know, let's just release something and we're in IoT, right? Every company's saying IoT, IoT. I think some companies are saying we don't want to use that buzzword anymore. They're trying to think, you know, let's go to the smart homes or the wearables and stay away from IoT because it's getting diluted so bad. The focus is about releasing products, not about the quality. I believe on Slashdot, About a week ago, there was a report saying that a new TV had a 46-page disclaimer about privacy and it was not possible to turn off the fact that the TV could record you and monitor everything you were doing. Even though you had an option on the menu, it still wouldn't do it. There's a lot of crazy talk about that some companies are looking at security but they're just not really enabling it correctly. One of the biggest issues I find on the market and what's happening with these reports like with HP is that a lot of people are using common firmware. So they're looking at buildings inheriting off a standard Linux distribution. And as a result, they don't really provide any over-the-air updates or update mechanisms at all. So if there's any form of zero-day exploits, and I will cover the 3 most popular this year, and I'm sure there's gonna be a lot more, these devices are forever doomed. Last point, it's comes down to why there's no real security is it's an argument saying that in order to implement SSL or TLS, the Transport Layer Security, you need to have a lot of RAM and CPU. And this presentation is gonna say that's bollocks. It's just lazy developers who just don't really wanna invest the time to write good code. And the biggest problem with that is that if you look at existing libraries like OpenSSL, they do have an embedded version. For example, one's called MatrixSSL. But that's still about 80 to 100 kilobytes of code and the Arduino only has 32K, right? So good luck trying to fit your program and some security in at the same time. To make matters worse, and I think this was covered in the keynote, where basically you're saying, you know, every dog has its day and they're just going crazy. There is no standards, right? So everyone's trying to make their position. It's a pity that the IEEE came in so late into the picture. It would've been great if they were doing stuff 10 years ago, 'cause then we wouldn't have this mess. But everyone's trying to say, not invented here. I have to create my own. I wanna own the IP. So we have all these things here and they have their own set of protocols. They're defining different set of security requirements. And we're gonna find that what's going to happen in the long run is that we're gonna have silos of different divisions of IoT and they're just gonna have different standards. So it's a pity. There's no universal standard, even with all the efforts, it's just not gonna happen very quickly. So these are the zero-day exploits, I'm sure you've heard about them all. Heartbleed was a nice one, right? If you had any OpenSSL servers, Shellshock was a beautiful one as well, that was so nice that you could actually pull down systems by browsing the web, setting a custom user agent string, right, and you can actually have a server denial of service on itself just by making one request. The other one that came out was POODLE. POODLE is quite interesting 'cause that's also another OpenSSL one. And the most recent exploit I saw was the fact that the SSL libraries would actually still negotiate an SSL 3 handshake even if the code was compiled to disable SSL 3. So this is really scary stuff. If you're basically looking at building an environment and you're looking at operating systems, right, what are your choices? Do you go bare bones or do you actually go with some existing OS and hope that nothing really goes wrong, right? So I'm more the type to go for bare bones. But there are some opportunities where you do have to use an existing Linux or there are some real-time operating systems like ARM mbed and RTOS being developed as well. But I will typically try and avoid that. One last thing in regards to security, it's not just about encryption. There's a lot more to security than encryption. So we have integrity of information, authentication, are we dealing with the right people? Non-repudiation is along the lines of saying, if someone does something, we wanna hold them accountable. And of course confidentiality. There's a great blog post there. You can grab this from the SlideShare presentation. So hopefully got through all the junk. Let's get to the serious stuff. So one of the things we looked at for Arduino is that we had a very limited CPU and we said, you know, what can we do with this thing? So the idea was saying, let's look at the most complicated algorithm out there, which is basically public key cryptography. And the idea was to say, can we implement RSA in less than 32 kilobytes or ideally less than 4 kilobytes so that we can at least have 28K of code on our Arduino devices, right? So the idea here is if you're not familiar with public key cryptography, you know, you, if you wanna send something to someone, they give you a public key, you then encode a message with that public key, then on the receiving side they would decrypt it using their private key and obviously they're the only people that can decrypt that information. And get the message back, right? So this is typically a standard protocol used for TLS, right? So typically if you use SSL, it's normally a public key cryptography exchange for exchanging a symmetric key for doing some form of stream cipher like AES. And then on top of that they do like hashing like MD5 or SHA. So key thing here was out of those 3 algorithms, RSA was saying that's the bitch. That's the hard one. So without going into the math, it's a very, very simple equation, but it's not that easy to implement. If you're talking about 1024-bit encryption, you have to create your own BigInteger object that actually would have 128 bytes of storage. And you have to do multiplication operations, division operations, et cetera. There's some good algorithms out there and we implemented some. So what we did is we wrote something in C first and we designed it specifically around RSA. So we didn't wanna bring in OpenSSL. So we handwrote everything from scratch. We define our keys as raw bit streams because if you use an existing web server that has a key exchange, the key itself is about 1.5K and you've got 2K of RAM. So obviously not feasible to work with official systems by downloading the UU-encoded versions of the keys. We designed it to be portable and have a very small code footprint, and you'll see the results soon. And we basically did 128, 256, 512, 1024, and 2048 where permissible on the devices. So it was very simple to work with. We just had a couple of library functions. So I wrote my own library around big integers. and implemented the algorithms as per what's out there on the market. They're pretty well-defined for RSA. It could be just as easy to do for elliptic curve as well. Elliptic curve has a better security in terms of the bit sizes, but the NSA kind of provided NIST a recommendation for the curve configuration and I wouldn't really trust that either right now. So what we did, This is the code implemented it. So here's some results. So for an Arduino Uno, which is the lowest powered Arduino device out there, obviously a public key, I guess you couldn't call it encryption or encoding 'cause the algorithm is exactly the same. When you use a public key, you have a smaller exponent. So the public key encryption is actually faster than the private one 'cause the private one's actually typically a massive number. So if you're dealing with a 1024-bit key size, then you can imagine doing mathematics like, you know, A to the power of E with numbers that are 300 decimal digits long, right? So that's how complicated this type of mathematics is. Obviously, if you go to 2048, then you're looking at about 650 or 670 decimal points. So not bad, you know, Arduino running at 16 MHz, we got a public key encryption down to 16 seconds. Not really something you can use commercially, but it was with C, right? So as a hardcore developer still using VI and command line, I decided to convert it to assembly and we basically got a 48% performance boost, right? So the message here is, you know, even with the minimalistic Arduino-type device, there are some devices that run at 8 megahertz, but they're mainly for wearables and not really something you hook up to sensors, just really for parties and stuff like this, like the LilyPad. But basically we got it down to saying we can actually encode an AES key in 8 seconds, which is not too bad, right? You can actually do that and possibly reconnect later on. You can see that decrypting it on an Arduino Uno takes 727 seconds. which is a good 2.5 minutes. I think it might be a little more, I have to do the math. Yeah, it's, oh, actually no, it's 10 minutes if I do the math correctly. So it's not really feasible to do that type of stuff. But I think the key thing here is that if we look at the SSL and TLS, you only need to do RSA once, right? 'Cause then once you have that exchange of that symmetric key securely, then you can use the stream cipher, then the AES is actually quite feasible on Arduino. Upgrading the device, we decided let's just pull out the ARM. And the Due actually has an 84 MHz ARM CPU. And we were able to do that initial public key encryption in 1 second, which is okay, not bad for 84 MHz. The private key took about a minute and a half, so it's 88 seconds there. And of course we can do 204 bits, so you can see the exponential growth. As the keys get more and more larger, it gets more and more complicated to do the mathematics. Now with private key decryption, you can implement what's called a Chinese remainder theorem, but that requires that you have the exponent or the 2 prime numbers and the inverse prime, which we don't have space for. So you could do it if you worked with lower bit sizes, but you'll see these numbers are quite largely different, mainly because they use exactly the same algorithm in both scenarios. There is an optimization called the Chinese Remainder Theorem that will do a 4 times or 5 times speedup. So most servers will do all this work for you for free. On the Yun, this was a very interesting device. This is a device that has 2 CPUs. It has an ATmega CPU just like the Uno and the Leonardo, but it also comes with this nice beefy 400 MHz MIPS processor. So for to test, like, let's look at all the crazy scenarios. I wrote a small sketch on the Arduino and had a small Linux program running on the Atheros chip. And when I wanted to encrypt something, I sent a message to Linux saying, do the work and then send the result back. And interestingly enough, we got 1024-bit down to 700 milliseconds, right? And 10 seconds for the decryption, for the the decryption using the private key. What's interesting with this is that we compare it to, comparing MIPS to x86. If you look at that number there for 1024-bit, the decryption is 10 seconds here, and on the Galileo, which is a raw 400 MHz Intel, it's actually 16. So even with that dual processor situation and the overhead of communicating back and forth, MIPS is destroying Intel. In terms of CPUs. Now, I don't know how many of you guys have heard about the Galileo and all these other devices, but I'm sure you've heard about the next device. So Intel's done a lot of work pushing this little sucker, and you can see the boost basically going from 192 milliseconds all the way down to 76 using the Edison. So surely you guys have heard of Edison, right? Yeah. So they did a good job with that, it's just it sucks a lot of power. So I think the biggest challenge we have here is that you can see that, yes, we can go to more powerful CPUs. But if we run into situations where we need to have a device that's doing simple monitoring and then reporting, and it needs to run off AA batteries for 3 months, it's not going to happen with these type of devices. So basically the key thing here is we did the math, looked at the compile options. So with AVR, if we did an empty sketch, it was actually 450 bytes. That's basically a Hello World scenario. We put the code enabled to do the RSA, and you can see there it actually used about 3.5 kilobytes of code and under 1 kilobyte of RAM. So we still had, you know, 28K of code to do other things and a whole 1K of RAM for doing other things, right? So of course, other devices, they do have more RAM and so forth. This is like the absolute crazy I'm insane, let's add security to an Uno. ARM actually does a lot better. So with ARM, the basic sketch was 10K and it just was increased to 12K. So you can see that the resulting code size was just 1,400 bytes, which is nothing if you consider the available amount of space. You can have 96 kilobytes of program memory. So very, very easy to add RSA to your devices. They also have a lot more RAM, so I think it's basically, with the variables here, you have 96K of RAM, we've used 981 bytes, right? So nothing. On Intel, not so nice. A lot of bloatware with the x86 instruction set. But still, the Edison can have 10 megs of program space, so who really cares if you're dealing with 10K versus 1K. But the key thing here is we're looking at for all different processor architectures. I don't have numbers for MIPS even though I should have had them when I did the Linux build. We're looking basically about 10 kilobytes maximum on some of the higher-end devices and 4K for AVR. And RAM usage is basically 1 kilobyte. So from this perspective, there's really no reason why you shouldn't be able to do some form of encryption on these devices. So looking at how we would integrate this, this is one scenario where we drew it up. It's a bit bright here. So the idea here was to have an Uno basically make a request to a server and it would respond with the public key. And then the Uno could take its 8 seconds to encrypt its symmetric key, create a packet with a UUID. so that the server knows who I'm talking to, send it over, decrypt the key. It then would have the key required for AES encryption and then you're all set, right? So it's only that initial request that would actually be very expensive. The advantages of this is that you could actually have dynamic public keys across sessions, right? Only the public key is used for encryption and the server does all the hard work, which you've got terabytes of information and a lot of CPU resources there. The disadvantages are obviously that you're communicating this public key and there's no way to really validate that that server you're talking to is authentic, right? So typically TLS as part of that key exchange does some form of validation against a certificate authority, right? So this would be a nice way, it'd be better than nothing, but I probably wouldn't recommend it 'cause it'd be very easy to do a man-in-the-middle attack. This is the hardcore version, right? This would work. The idea here is that basically on the Uno, we would have the server's public key, the device's private key, and we'd actually encode that in the sketch, right? So it would never be transmitted over the network. What would happen is that the Arduino, before doing any form of communication, it would say, you know what, I'm going to create my 256-byte symmetric key used for AES. And basically it's gonna sit there and churn, right? Using private key encryption, I wouldn't recommend that on the Uno. I think it takes about 2 hours, right? But if you're using one of the more higher-end ARM chips, you know, you're looking at about 16 seconds. And then once you have that packet, you can then initiate the communication, do the exchange, and then you basically have a secure channel to work from, right? So advantages of this, is that, you know, you're never really communicating any keys over the network, right? So the public keys of the server and the device are actually stored in the Arduino itself. The interesting thing is by having the UUIDs and the public keys, the server could have a database saying this is a UUID and this is the associated public key. The great thing about that is only the Arduinos that are registered could actually communicate with the server. And if any of them were compromised, just simply removing it from the data store on the server side would say adios. Every single device would have a different UUID and a different public key. The only real challenge with this is that the initial time to actually do that encryption using the private key. So the mathematics is insane right now for doing this. You could go to 512, which would obviously give you a 4x speedup. But right now the recommended for doing RSA is 1024-bit because the 768 keys have been broken, right? So you may be better off doing this than nothing at all, right? That's the most important thing there. Another interesting thing of Arduino is this whole principle of, you know, generating a secure random number generator, right? So typically you have a pseudo-random number generator, which is basically using a simple algorithm to take a seed and then generate a pattern of numbers and you hope that it's random. One of the requirements for having a secure random number generator is the idea that your random number sequence should not be predictable. What I did in this case is I basically hooked on the analog signal of the Arduino and it would just basically receive random inputs. I have a couple of functions that would do this Van Neumann algorithm that would reduce biasness and I can get access to that code if you're interested in it. And the idea here is that I would generate the first request saying, how often should I change the seed? And since the AES key would require 256 bytes, I can actually say, give me a random byte. I can divide it by 4. I think that's actually 64. So basically I can say between 0 and 64 iterations is gonna happen using the normal pseudorandom number generator. And then when it does that, it will regenerate the next thing. And you can see how it would be absolutely unpredictable even if you're using a pseudo-random number generator to actually utilize or predict what those random numbers would be. So this is not— you could have these math guys go crazy and say, oh, but it's not secure, blah, blah, blah. But I would love to challenge people to figure out exactly what my random seeds would be. So you can see by using atmospheric details and actually reducing the seed usage, basically down to less than 64 times and I'm generating a 256-byte array, there's no way. It could change the random seed a minimum of 4 times if the random number is always 64, or it could be up to 256 times. So I'd love to see anyone try and figure out how that would work. So that's kind of the work we did with the Arduino. So we're doing a lot more work. We did get kind of sidetracked with a lot of other things. But the good news is, after we started doing this stuff, things started happening in the IoT ecosystem. First one is Arduino and Atmel joined forces and they're providing you a Wi-Fi shield that has integrated TLS. Why they didn't do a shield that was just the chip so you can actually make requests to it and then use the same encryption over BLE or Ethernet and Wi-Fi, it's beyond my understanding. Maybe they'll still do it, but it's using ECC-256, which is the equivalent to RSA-3072, AES-128. Nice to use 256. But basically it's just a shield that you plug in and do normal Wi-Fi stuff and it will be transparent providing you complete TLS, right? Bit expensive, I think it's like $70, right? So if you've got an Arduino for $30, it's kind of double the price. So you can write it in code. It'll probably cost you more than $30 to write the code. Next one is ARM. ARM actually did some nice stuff. So they announced mbed. Basically they're providing not really an OS, but kind of a set of frameworks for you to work from. So they're providing you crypto and device security, device management, IPv4 and v6, 6LoWPAN, trying to give you all the libraries you can do and build a bare-bones OS. But unfortunately, it's specific for the Cortex-M7. So they believe that everyone's gonna be buying Cortex-M7s 'cause we can make 'em for a buck. But unfortunately, until they can get that power consumption right down, AVRs are still gonna be used. What I like seeing on the community is SAFE released a library, the first library that actually did do end-to-end encryption that's more than just hashing and so forth. They provided ECDSA, which is one of the implementations for elliptic curve. I think it uses a lot of memory. I'm sure I can go into that code and rip out a couple of bytes from RAM usage. Might be worth it. But it's a good start. I think it's great that the community is actually doing this. This is an MIT-based license as well. So that's good. One that's been around for a while is the AVR Cryptolib. Unfortunately, this doesn't do RSA or ECC. at this point, but it does a lot of stream ciphers, hash functions, so you can actually maybe combine 2 things together. This is a great thing that's actually appeared even after we started doing the work. We started seeing these things pop up. Some of these things were only announced in the last 2 or 3 weeks. Things are changing as we go more and more further. Got 2 minutes left. Managed to squeeze it. One of the interesting things I like to cover, and I think this is a great area of discussion is, are we really approaching security in the right way? So traditionally, we've been copying the physical world when looking at security. So we have firewalls, we have keys, we have safe zones, et cetera, et cetera, et cetera, DMZs. Problem with that is that you're trying to basically say, from start, let's try and be secure. That's impossible. Someone's always gonna find the flaw. There's always gonna be more powerful CPUs or processors entering the market to break keys and so forth. So I found an interesting article on EE India Times where researchers were actually looking at maybe we should look at nature, right? So looking at a biological approach to actually doing security, right? So the idea is saying, you know, just like organisms have been on this planet for billions of years, Survival of the fittest, right? Expect to get infected, but design systems in a way such that if you do detect an intrusion of some form, isolate it and have a new node spawn. A lot of interesting discussion around this. I don't see this happening on AVR CPUs in the short term. It's gonna be difficult enough to do on a 1.2 gigahertz machine, right? But at least it gives a lot of interesting ideas and it comes back really to the diversity of nature, right? So Classic study here is the idea of potatoes, right? So there's a potato that's susceptible to disease, right? And if you have a diverse environment where you have a lot of potatoes, different types of brands, and you get an infection, the diverse environment will still have some guys left over, right? And as you evolve these type of biological security solutions and you become different from everyone else, even if you're using traditional solutions, stay away from the Linuxes and stuff like this and try and build your own custom solutions. Because the more diverse you are, the less likely you're gonna have this last scenario here where you have a crop that's only this specific type of potato. Disease comes in, everyone's dead, right? So that's the worst, worst case scenario. And if we keep going the route of reusing Linux or certain distributions and not having update mechanisms, right, you can see how we're gonna run ourselves into a lot of problems. I saw on the, the presentation, or the booklet about that the guess was there's 50 billion devices. Here's 4 different numbers from 4 different companies. Gartner's saying 26, Cisco and Ericsson are saying 50, Intel's saying 200, and IDC is saying 228 billion right now. I think the key message of this is it's actually time to talk to the people making products, talk to developers, at least implement some form of security because right now it's just getting out of hand. So that is 1 minute over and I squeezed it in. So I'll be open to questions. I know we have a break now, but I can be at the table if you guys are interested to know what we did and how we did it. We haven't released the code for that stuff yet. We're still working on it. We are trying to build a solution that could actually talk to a real TLS server. We're very close, but we just didn't have results for you now. And contact information, You know, there's my email address. I do have a private blog where I cover a lot of topics. So that blog page there actually has a link to the SlideShare presentation if you wanna get a copy of it. But by all means, come by the booth and, you know, we will happily show you our development environment. But this is something that's close to my heart and I think something that as an industry we need to solve. So thank you everyone. Thank you.