Sending TLS Packets

Since I got everything up and running a few weeks ago, I’ve been trying to start making a TLS implementation.
This is effectively using the same setup as before, where the ESP8266 is connected by Serial to a computer, and wirelessly connects to a Raspberry Pi access point for packet capture.
First off, I found a neat little AES -128 encryption implementation that works with only a little modification! In fact, it seems to take under a second to encrypt a 64-byte string, so sending periodic sensor readings shouldn’t prove too troublesome.

Next I started trying to initiate a TLS handshake by sending a ClientHello packet over TCP. This proved tricky at first, particularly because I was using the client.print() method (for strings) instead of client.write() (for sending bytes of data).

At the moment, when I send and capture the packets (see previous post), Wireshark recognizes them as valid TLS packets, but the server I’m sending them to (data.sparkfun.com) keeps returning TLS alert packets, saying that there was a decode error. This, apparently can either be attributed to some problem with the packet, for instance a “length” field not correctly stating the length of the packet, or potentially because this method could be an explicit handshake, for which the server is not configured. (source: streamsec forum post ).

While I could continue trying to solve this particular problem, I think my next step will be to try using DTLS, or Datagram TLS, which is effectively TLS over UDP instead of TCP. Because UDP is connectionless, sending a DTLS datagram manually (i.e. with a predefined packet for testing purposes) should, in theory, be indistinguishable from one sent from a client that already has a fully-functioning DTLS implementation (e.g. anything with OpenSSL).

If the problem persists after trying this, it’ll have to be a problem with the way my packets are composed. (although I’m about 80% sure this isn’t the case!)

 

Advertisements

Project Update

Things have been a little quiet on the blog lately; that’s mainly because the past week or so have been used to do some research into the security landscape, and to figure out the exact direction of this project.

As it stands, this project is going to have a more definite focus on security, specifically implementing some form of TLS, as well as addressing the chromecast vulnerability.

The initial focus will be to implement TLS, starting off with a basic implementation that achieves encrypted communications, which will then be developed to produce an implementation of TLS that could be considered secure. The initial implementation won’t use TLS records, but these will be implemented.

A tested version of AES will be implemented. Different implementations are being looked at at the moment, such as these:
https://github.com/kokke/tiny-AES128-C?files=1
http://forum.arduino.cc/index.php?topic=88890.0
https://github.com/spaniakos/AES/

The initial basic implementation will feature Basic TLS handshake, with self-signed certificate, and allow sending encrypted messages. Following this, a mock CA will be created, and authenticating the server, and possibly the WiFi chip will be implemented.

ESP8266 Packet Sniffing

As I said in the To-Do list section, one of my goals was to capture some packets from the ESP8266 temperature sensor setup to show that the data is indeed very easy to read.

This took more time than I expected, as I decided to set up a raspberry pi as an acces point for the Esp8266 and use it to capture the traffic going through. I mainly did this because setting up mirroring on the router(s) I’d be using was a bit of a pain, plus there was a LOT of background traffic to have to sift through, since it was a shared router.

There wasn’t a huge amount to it: I basically just followed these instructions, although you’ll want to omit the step titled “Update hostapd” if you’re not using an Adafruit WiFi adapter (which I wasn’t).

Following this, I just installed tshark on the raspberry pi with:

sudo apt-get install tshark

After this, I added a user to the “wireshark” group with:

sudo usermod -a -G wireshark <username>

After doing this, remember to log out and then log back in for the changes to take effect, else they won’t, and you won’t be able to run tshark… Which is why I wasted a few minutes googling the problem…

Next, I just modified and uploaded my sketch in the Arduino IDE to use the SSID and password for the raspberry pi access point (see the “Configure Access Point” step of the “Install Software” section of the Adafruit guide to change these).

I set up the ESP8266 and temperature sensor as before and used the serial management console in Arduino to make sure it connects to the access point.

Now we’re ready to capture some packets:

tshark -i wlan0 -w /home/pi/espcapture.pcap

This will capture all packets being sent between the Pi and the Esp8266. You could change the interface to eth0 to see what’s going between your router and the pi, but frankly it will largely be the same stuff you see, alongside any other traffic being sent/received by background processes on the Pi. Hit Ctrl+C after a minute or so and you should have a good sample.

Finally, make sure you’ve installed Wireshark on your computer, then grab the file from the Pi (I use WinSCP because of personal preference, but FileZilla and other FTP clients are great too) and open it using Wireshark to see the contents of the files. Since they’re unsecured HTTP GET requests, they pretty much get sent in plain text, which should appear as follows:

espcapture2

This snippet of the output from Wireshark shows clearly the private key that I was using, as well as the temperature reading, completely unobscured, and obtained with completely free software!

Definitely not the way to go if you’re sending sensitive or critical information, and it could also compromise the security of other systems (i.e. the private key)…

Next, I will probably try to set up a simple web server on the raspberry pi and send information there so that I can try to implement some security measures in the ESP8266 firmware, and modify the server-side code to be able to handle this. If I find that something like HTTPS can be used, the Pi might not be necessary, but we’ll see!

Hooking up a Temperature Sensor

Unfortunately there aren’t many resources online that deal specifically with connecting an Olimex ESP8266-EVB board like mine to some temperature sensors. (I used the DS18B20 temperature sensor)

When I hooked my sensor up, this IoT Playground post was the most useful. However the pins on the diagram provided don’t correspond to those on my board. It was simple enough to translate this diagram using the schematic that Olimex provides, specifically using the UEXT section.

The pinout for the original post’s chip helped a lot too!
xesp8266-pinout_etch_copper_top.png.pagespeed.ic.SiFP37EJYg

This means that, when holding the DS18B20 with the flat side facing you, the first pin should be connected to ground on the board (a small slot on the board marked “GND_PIN”), the centre pin to one side of a 4.7 kΩ resistor, and this should then be connected to GPIO2, also known as UEXT pin 6. Finally, the right hand pin of the sensor should be connected to the other end of the resistor, with this then being connected to VCC, which is UEXT pin 1.

(I’ll update this post with a diagram or picture soon)

Following getting this working, I combined the code in the IoT Playground post with the WiFi client example I used in an earlier post to update my Sparkfun page.

Next I’ll try to read the packets being sent out, and then try to use HTTPS to send them and (hopefully) try and fail to read the contents of these packets!

Connecting to a Server

This will be a short one, since connecting to an HTTP server was surprisingly easy!
After doing everything mentioned in the last 2 posts, I started playing around with some examples, and found some ESP8266 specific ones.

Of particular interest was the example at: File>Examples>ESP8266WiFi>WiFiClient

The comments at the start of this example mention sparkfun.com, which allows users to send small amounts of data and display it either as a list of raw values, or as a chart via analog.io.

The only issues I had getting everything up and running were as follows:

1: The example code has a constant named “streamId” (line 15), which isn’t mentioned on the sparkfun page providing all private keys etc for the stream. Looking at the examples provided in the documentation, it’s clear that this field corresponds to the public key that sparkfun provides.

2: When you create a stream on sparkfun.com, you can choose to set a number of field names. I set mine to “temp” initially. If you choose any field name that isn’t just the word “value”, you will need to change “&value=” to something like “&temp=”.

After doing all this, I was able to see the incremented value posted to my sparkfun page (it’s not very interesting at the moment):

sparkfun1
My super interesting sparkfun page

 

Some things to note when using sparkfun: you can only upload 50MB of data before the earliest values start getting overwritten, and the maximum upload rate is 100 updates every 15 minutes (it’s all explained here).

At the moment I’m waiting on some temperature sensors to arrive, so when they do, I’m going to start trying to get one of those hooked up and post the results to the page!

Getting Off the Ground

esp8266plugged
The board with everything plugged in

Being fairly new to working this closely to the hardware, it took me a little while to get off the ground. I started off with the Olimex board that I linked in the previous post, and from there I had to find a way to get code from my computer onto this chip, and then figure out if said code was running.

I started off with the goal of trying to get a really simple example which makes an LED light on the chip blink.

First the shopping list:

That’s pretty much all you’ll need. A couple of important notes:
as I mentioned, the USB to TTL cable I linked is NOT compatible with windows 8 and 10 out of the box, and I had trouble getting it to work. This, paired with the fact that many of the instructions I saw online were for Unix systems (think Ubuntu and Mac OSX), made me decide to switch over to my Ubuntu 14.04 partition before continuing. Additionally, if you are using a different board to me, you probably won’t be able to attach a 5V power supply. You have been warned!

Much of what I did came from Olimex’ very own wordpress blog, however this is a little dated and leaves out some important info.

In particular: the above blog mentions selecting a programmer in the IDE, but in newer versions of the IDE, this is not necessary; just leave it at the default programmer.

Additionally, the blog does not mention that, in order to put code on the chip, it must be set to bootloader mode by turning off the power, holding down the big white button, turning the power back on, and then releasing this button.

The specifics can be found in Olimex’ more official documentation.

After following most of the steps on the blog and in the documentation, I managed to get the LED blinking! Success!

Next I’ll talk about connecting the chip to your WiFi and sending some basic messages to and from it.

A Newbie’s Guide to WiFi Sensors

The “things” in the Internet of Things can be found just about anywhere; in your home, in an industrial plant, an office… Maybe you want to monitor the temperature of your house to save on bills? Maybe you want to have your house send you an e-mail to let you know that you’ve left something on, and remotely shut it off? Or maybe you want to booby-trap your house like some kind of 21st century Home Alone scenario.

homealoneblowtorch
Definitely don’t try this

To be more specific,the “things” in question are generally sensors and actuators. Broadly, a sensor is something that gathers raw data, like temperature or power usage, and an actuator can be thought of as something that moves or takes some (generally physical) action, for example remotely turning off a plug socket (in the UK) or automatically torching the hats of any unsuspecting Joe Pescis.

Of course, sensors on their own aren’t very useful; they need a middle-man to take their readings, transmit them, and in some cases interpret them.

I’m going to be focusing on using a particular type of middle-man; namely the ESP8266 WiFi chip, or at least a variant of it as you’ll soon find out. The idea is to learn about how to use these chips in combination with sensors and send the information to a web server. Once I’ve managed this, I’ll be moving on to looking at other aspects of IoT data transmission.

I mentioned before that these chips could have a industrial or commercial uses, which is why I will also be investigating how to securely transmit this data. The potential issue here is the fact that some security measures, like encryption, can be computationally expensive, especially in combination with real-time data transfer.

Once I’ve got a setup where there’s at least one or two sensors feeding data to some server, I’ll begin investigating what security measures can be implemented to avoid things like packet sniffing or the Chromecast Attack which has been demonstrated to work on the ESP8266.

If I manage this in good time, I’ll continue to look into optimizing the setup to give maximal battery life, as well as making the setup more robust when it comes to switching out the sensors (e.g. switching from digital to analogue temperature sensors, or taking different measurements).

I’ll be posting info about my experiences with the chip, so to anyone who reads this; your mileage may vary!

esp8266
The Olimex Board

At the moment I’ve managed to get an Olimex ESP8266-EVB up and running (with one or two hitches). By “up and running” I mean that I’ve managed to connect it to my network and upload some code to it using the Arduino IDE. I’ll make another post detailing exactly what I did, as the instructions I used to get this working were somewhat scattered.

 

Next on the list:

  • try out more examples, particularly WiFi related ones
  • find a server to use and communicate with it (I’m thinking thingspeak is viable)
  • hook up a temperature sensor and get the chip to pass on this data (ideally in real time)