User login

Search Projects

Project Members

Dan Collins admin

Creating a Secure and Low Power Internet of Things Platform

The Internet of Things is an up and coming pervasive technology. While there are many platforms available to create IoT products, many are not suitable for battery powered devices designed to be deployed for years without service. More concerning is the lack of focus on security. Creating a new platform that is both secure and low power will allow even the most resource constrained (and therefore cheap) devices to enter the home.

23

Oct

2015

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.

FIN

02

Oct

2015

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.

18

Sep

2015

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

15

Aug

2015

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!

06

Aug

2015

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:
- MAC, PHY, CSMA
- 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.

31

Jul

2015

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.

24

Jul

2015

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.

16

Jul

2015

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.

11

Jul

2015

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!

03

Jul

2015

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.

12

Jun

2015

Have a copy of ubiquiOS in hand. No further progress on the project.

Looking forward to integrating ubiquiOS and improving all the low-level OS functionality (software timers, memory allocation and debug output spring to mind!).

05

Jun

2015

I have most of the association procedure implemented meaning nodes are able to associate with the coordinator. However I'm having problems with my custom OS. Rather than spend more time on that venture, the plan is to use ubiquiOS for now. I can always write a new OS later - or use something like Contiki.

I have a fair bit of experience with ubiquiOS so this will be the fastest path forward.

Not much will get done until at least the end of next week. The next step is to integrate ubiquiOS and make sure error states are handled with the association. Then it's on to security!

21

May

2015

I've had MCPS going for a while now, however the structure I came up with initially made it difficult to pass frames between layers. For example it was up to the top layer to build the frame for sending - a bad way to do things!

The way it works now is that the MAC manages all of the frame memory and the upper layers simply pass in data. This is obviously a much nicer way to do things.

I also spend some time implementing some OS timers (which I am currently modifying to allow the addition of timers from an interrupt context). This allows the code to use callbacks, from a background context, to pass data around in a more event driven manner. While I like the idea of owning my own OS, ubiquiOS is available as an alternative which is likely to be far more stable. I'm still a little undecided but a few more bugs in my OS and I'm sure I'll jump ship. The intention will be to keep an OS abstraction layer so ubiquiOS can be swapped out and replaced as needed.

I've totally restructured the mac into several pieces - MCPS, MLME, coordinator and packet scheduler. The packet scheduler manages queues and timing of sending and receiving packets. MCPS is working, however no CCA is currently done so collisions are possible. I plan to implement beacons before I worry about CCA.

Patrick and I worked together to get 802.15.4 packets into wireshark. Patrick and Richard managed to get the full 6LoWPAN packet decoding going by ignoring the FCS in the MAC packets.

15

May

2015

Woops. Missed a report last week...

Last week I wrote the radio driver which is able to send and receive 802.15.4 data packets. The Contiki software was useful to see which registers I needed to initialise to get data moving. There's plenty left to do but it's enough to get running.

This week I have started writing the MAC layer. I want to start with the PAN coordinator, specifically with beaconing. Once I have beacons, I can start work on the three scan types - active, passive and energy detection. This will allow the PAN coordinator to survey the site before starting a network.

Once I have the surveys and beacons working, I can get association working.

03

May

2015

Dean lent me a Segger JLink which I was able to use to start tracing down the hardfault. I was unable to do this, as the newlib library doesn't contain debug symbols.

While I could build my own, I created a work around exploting the fact that vsnprintf works fine.

The JLink is still very useful as I'm very likely to need to debug other issues later on. The XDS100v3 is pretty useless for this task. The JLink also provides a way better (faster, CLI) way to program the device so I suspect I'll even become more productive.

The next step is to try and get some reliable radio sniffing going. I need to ensure I can see 802.15.4 frames so that when I'm developing my own MAC I can make sure the frames are correctly formatted. This should be a trivial task as the CC2538DK comes with a USB dongle which there is already sniffing software for. I'm just unsure if I'll be able to do the sniffing under Linux.

tl;dr: I have UART, printf and malloc working. Now I need to start radio dev.

28

Apr

2015

After the last project meeting, we decided to ditch contiki as it does not offer much that will be useful to this project. Rather than trying to hack in a new mac controller and modify the existing mac data path, it is going to be easier to just write something from scratch. The future plan will be to add networking layers on top.

In order to facilitate a new platform, we're sticking with the CC2538DK. I've spent a bunch of time getting a linker script, start up file and some basic code running. So far I've got the LEDs, UART and LCD working fine. The next step is to try and get libc (specifically newlib) going to add support for things like printf, malloc and free. Printf is extremely useful for debugging and it makes the project much simpler to implement. Malloc will be useful for packet buffers and the like (although static memory could be used instead).

Unfortunately calling printf causes a hardfault. We don't even manage to get through newlib down to the stubs that are environment specific (the part that takes the characters from printf and passes them to the UART). Using GDB, we can examine what caused the hardfault and go about debugging from there.

I have no idea why, but I am unable to read any of the useful registers. It seems like the GDB server provided by TI (which gdb connects to) doesn't like hardfaults and somehow locks us out of some registers. This is a big problem, as I need to be able to debug the CPU in order to get anything done. I've lodged a support request with the TI forum: https://e2e.ti.com/support/wireless_connectivity/f/155/p/419436/1493827#... I don't have very high hopes as I haven't had very good support in the past.

I'm really hoping that Dean (as he has a lot of experience dealing with ARM Cortex M3 parts) is able to help me solve this. It's hard to debug without printf and without gdb!

06

Apr

2015

Since the last report I've been reading through the 802.15.4 standard to get an idea of what to expect from silicon radios that say they are compliant.

Both Dean and Richard made the point that just because they use the 802.15.4 radios doesn't mean they follow the standard and as such I shouldn't expect to see a whole lot of structure from the standard. For example the standard is very vague when referring to a network not using PAN controller beacons which would allow the network designer to make whatever decisions they like. This is an issue when interoperability is desired as the IEEE802.15.4 standard really doesn't offer anything that would facilitate such interoperability - the application and the networking (in cases where it is not a star network with PAN controller beacons enables) are not defined by the standard.

I also attempted to trace through the source for both RIOT OS and ContikiOS. RIOT OS is a microkernel meaning that messages get sent between different processes by the kernel. As such, I was able to trace the transmission of a TCP packet through the RPL routing, through the 802.15.4 framing to a call where the frame was sent to a transceiver. ContikiOS was far more complicated as they use a lot of preprocessor macros for various things which makes tracing a little more difficult. I wasn't interested in spending a lot of time tracing when my main interest was just figuring out how the 15.4 layer worked (PAN beacons? PAN controller elections? free for all?). I actually didn't figure out how either worked, but I imagine reading through the RPL routing document would give more information.

Finally I tried to evaluate both ContikiOS and RIOT OS. I like the RIOT OS source as it is very clean and readable. For this reason I was really hoping that I could use RIOT OS for this project. However, support for the CC2538 transceiver (distinct from the microcontroller core) is not in the mainline branch. I was able to checkout a branch that claimed support (and is in the process of a pull request) however it was hard to tell if it was actually working. ContikiOS on the other hand was ready to go out of the box. My sniffer seemed to have some kind of latency in showing me received packets (or it was rejecting them because they aren't using standard frame checksums?) which made it difficult to figure out how packets were flowing. In any case I was able to create a gateway running SLIP to a tap interface as well as a web server node that I could access over the air using the gateway.

I plan to continue evaluating both options but it appears that ContikiOS is more polished than RIOT OS in terms of CC2538 support. I find it interesting that RIOT OS claims support for the CC2538DK but doesn't support the radio (yet). RIOT OS is an embedded RTOS but I don't think I would choose it over FreeRTOS unless I wanted the networking and radio stack.

24

Mar

2015

This report will cover the progress to date. I've also attached the proposal I submitted in case anyone is interested in reading that.

In order to make a start there are two areas that need to be considered. The first, and likely most important, is to consider how the provisioning flow is going to work. IEEE 802.15.4 has some build in AES security stuff as well as different channels (much like Wi-Fi has channels). At the link layer there needs to be a way to negotiate some kind of connection which will involve scanning for a channel both nodes can talk on as well as some kind of key exchange to encrypt the communication. Above that, in the networking layer, we probably want some kind of authentication and encryption to ensure that nodes are who they say they are. Finally, the application layer will need to support some kind of key store so users can add the new node before trying to connect it to the network.

The other side that needs to be considered is which platform the project should be built on. The CC2538 hardware has already been decided. Not only does it have IEEE 802.15.4 radios, it is also supported by all the major WS platforms I could find. The other convinient aspect is we already have development boards for it. The software, at this stage, will either by RIOT OS or ContikiOS. The issue with ContikiOS is that I've seen Brad and Isabelle working with it and it seems like there are a number of challenges along the way. RIOT OS is lacking a gateway software which would make it difficult to get any of the application layer stuff working. A gatteway is also useful for sniffing network traffic, but that can be done with any of the nodes and a serial port.

I think I'll start by reading through the IEEE 802.15.4 standard to gain some understanding of how the channels and encryption work. Those are likely to be key to the project. I may as well take the oppourtunity to draw some diagrams at the same time (which will help with report writing!).