User login

Dan Collins's blog




I have spent the last few weeks working on my thesis. Last night I submitted, which means my honours project has come to a close.

I need to remove ubiquiOS so that I can release the project as open-source. I will license this project under a 3-clause BSD and make it freely available on my github.





Put more time into my implementation chapter.

I'm taking a break from writing the standard, as I really need to get my thesis written so it can be reviewed.

I'll be starting on the background chapter next. I'll try to leave the secure provisioning chapter until after I finish writing the standard.




Been a wee while since I last wrote a report. I was in Germany and Amsterdam over the semester break and didn't make any progress on the project.

The presentation went well (in my opinion). The fact that I had a live demonstration that worked was a real asset! I showed a wireless sensor network that could measure temperature, ambient light and also a 'knock knock' sensor representing a door. The various readings were transported over the network to the coordinator which then passed the information to a python program for visualisation.

All of this required that each feature was functional, so I'd say it was a good demonstration of the features I had developed (sending/receiving packets, device association and authentication).

I'm now working on writing a standard for device provisioning. It's very similar to WPS which I think is a good compromise between security and usability. It supports the same PSKs I used initially which gives the developers the flexibility to add additional authenticity checking.

I am unlikely to implement this standard before the report is due, however I do have a personal interest in the project so it will get done some time! Over the break I should have some free time here and there to add provisioning support as well as IPv6.

At the same time as the standard, I'm writing my thesis. According to the word count graph, I'm sitting at about 2,700 words (which is mostly the provisioning standard).




Another week in presentation mode.

The demonstration itself is now working much more reliably. Dean was a big help here as I'm leveraging some features of ubiquiOS (Bluetooth Smart). I'll keep the exact details a secret for this coming Tuesday!

I've also re-done all of my slides and diagrams. I tried to make the presentation more like a story where I introduce a problem, some reasons why existing technology doesn't solve that problem and then discuss my solution. I discuss at a high level to cater to a broader audience before I start drilling down into the architecture and the problems I had along the way.

I still need to write some presentation notes, take some photos (in case the demo doesn't work for some reason), and also draw some more technical diagrams to cover specific technical questions I anticipate.

I've had the system running for the past 24 hours collecting sensor data for the presentation!




This week I focused on my presentation, and then secure provisioning.

The presentation feedback so far can be grouped into two categories:

* Relying too much on domain knowledge:
- Heavily technical explainations of 802.11i RSNA (perticularly the key derivation)
- Too many acronyms!

* Not covering the problem and my own solution enough
- The jump from IoT to IEEE 802.15.4 was too abrupt
- What about Wi-Fi and Bluetooth?
- How much work have I actually done?
- Does it work?
- Nobody else has creating an open source implementation that uses beacons. This is important!

Andreas helped me out hugely by sitting down with me to refactor my slides. We came up with something very quickly for the next day's presentation that was much better than the first. I still have some more feedback I need to fold in before Wednesday next week.

I also spent some time trying to get a demo going. I want to demonstrate what is possible with a convenient provisioning process. I've written an Android app that will scan QR codes and pull a MAC address and PSK from it. I have also added Bluetooth Smart (BLE) to my coordinator application to accept BLE connections. The aim being to transfer the MAC and PSK to the coordinator (which can then push the PSK into the security supplicant).

tl;dr. Scan QR code on network node with Android. Bluetooth used to transfer PSK to coordinator. New device can then associate and authenticate with coordinator. Profit.




Have stopped work on the project, and am instead working on my seminar. I have one at Virscient on Tuesday, one in class on Wednesday, one at WAND the following week and then the final seminar the week after that.

Before I present, I really need to get some actual evaluation data. My title, "Creating a secure and low power internet of things platform", suggests I'm concerned with security and low power. I've got the security (I followed standards including RSNA, so it's at good as 802.11 assuming I implemented it correctly). For the low power, I'm not going to have time to implement serious power savings before my presentations (maybe I will before the final one, who knows). My goal here instead is to waggle GPIO pins to tell me which state the CPU is in, and then use the datasheet values to calculate energy assuming I add power savings.

At the same time, this profiling will tell me where most of the power isused nd where to focus my power saving efforts!

I've been sick the past week, so aside from the presentation I haven't been able to do this profiling. Maybe later today.




The security supplicant is now functional - encryption and decryption. All devices are using the same key which is written at compile time. I need to do some research into viable key exchange mechanisms, but I figure something like 802.11i / 802.11ai based will do the trick. 802.15.9 documents a key exchange protocol, however only members of IEEE 802 WG4 are able to see it. There is a very brief draft which I might be able to use to get something similar in functionality.

There's actually a fair chunk of functionality missing from the security supplicant. It is missing support for other key ID modes (explicit) as well as different security levels (MIC only, ENC with 64 and 128 bit MICs). It should be easy to add the additional security levels, however I think that this is a nice to have and doesn't really affect the end result.

My final presentation is not going to be on the 2nd of September. I am attending a wedding in Germany so my seminar will instead be on the 18th of August at 11am. More information to follow on the department mailing list!

Soon I will have to start focussing on the presentation rather than getting new features implemented.




I got AES going! 802.15.4 uses the CCM* block cipher mode with AES as the cipher (using 128bit keys).

This was really difficult! Small changes in the input resulted in wild changes in the output (as you would expect!). I wrote a tool with libtomcrypt to create some reference data (something that I would then try to replicate with the CC2538 libraries). In the end, I managed to make this work.

I also got this going with Wireshark (which highlighted an endianness issue with my libtomcrypt tool). Wireshark will now accept my AES encrypted messages which gives me confidence that the implementation is correct.

The implementation is a bit hacked together at the moment (as I was hacking about to get it going) however tidying it up should be simple. Then I can move on to decryption.

As for the security, I have no idea how well this implementation would perform against side-band power analysis attacks. This is something I'm not even going to consider trying to defend against at this stage! In the future, however, this might be important.




Have fully integrated the new packet scheduler. This works great! I have the default number of link-layer retransmissions enabled (3) and this gives great reliability to my ping demo. I also added some debug GPIO so I knew what was going on when and things line up well enough (4 - 5ms of error between the coordinator and device slot timers ain't bad!).

I'm now looking into the AES-CCM* based security supplicant. I already had a supplicant that accepted messages to encrypted/decrypted but it didn't actually do any tranformation on the data. The CC2538 has an AES core built in where you pipe data in one end and encrypted data comes out the other. TI provides a library to do this, so I'm in the process of wiring it up. This is actually fairly simple once I figured out how the CCM mode operated (and understood the parameters L, M, a, m and c..!). I expect that once I get encryption working that decryption will be trivial (as you simply input the cipher text rather than the plain text and run the same algorithm on the data).

I'm pretty pleased with progress to date!




I think I've missed two of these...

I've spent a bunch of time re-wrorking my packet scheduler this past week. I wanted to allow for link-layer retransmission of packets which ht epacket scheduler was not originally designed to do. It compiles, and messages get sent however the upper MAC layers manage their own re-transmissions and ACK messages no longer get passed up and so nothing works just yet. This is a simple case of re-working the state machine to accept the new packet states; ACK, NO ACK and NOT SENT (in the case the packet fails CSMA and never leaves the radio).

ubiquiOS (which seems to be the topic of my last report) is well integrated and working. Before the packet scheduler re-work, I had 3 nodes able to simultaneously associate with the gateway node (pan coordinator). After association, the nodes would ping the gateway and measure the response times. With a beacon period of 500ms, the response time averaged at 500ms with 1% packet loss.

Adding link layer retransmission should improve that packet loss figure.

After that, I want to start working on AES. I'll hard code the keys for now, and try to install them at a sensible time. At which point, I can celebrate because that's the infrastructure I needed to start my project! I can then remove the hard coded keys, and replace them with authentication and key exchange.

Stretch goal is to add 6LoWPAN on top - which shouldn't be too difficult, as I've essentially made a pipe that correctly sized packets can be piped into.