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!)
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:
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.
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!
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!