Making Toast with Azure Sphere

The Personal Area Counter Surveillance Concept

I can't say I have ever really been a fan of spy stories. What I have found fascinating is the gadgets, sometimes disguised as every day objects but usually portable and powerful beyond current consumer tech. Often literature romanticizes the spy game, specifically the ability to be highly aware of ones situation. Spy stories taking this a step further and often depicting the cat-and-mouse game of 'tailing' or surveillance. I would like to leverage this as a setting for this project.

Many of us are aware of the fog of signals that follow us due to our possession of ubiquitous electronic devices. Each of these devices emanate some sort of identifier into the open air that may not be universally unique, but combined create a sort of digital finger print. As you are probably aware finger prints themselves not universally unique, but unique enough to differentiate people and serve as a sort of weak authentication. Correlating these signal identifiers is the first step to tracking (not to be confused with locating) an individual.

Many of these id broadcasting signals do not carry far. So if we sense them, we can deduce a location based relative to the sensor. If you are following, we just walked through identifying and locating an individual. The next natural step is to correlate this data with events. For example: every time I get coffee person A is there. Often when I go for a walk I pass by person B. Person C passes by my house every day about 5:00PM. Person F is there when I get coffee, when I go to the park, and came near my house last night at 3AM... I might have a stalker.

Processing location data is a subject I am going to put off to a different time. To simplify this we will assume our sensor is in a fixed location like our house or on our person.

There is a great talk about physical counter surveillance from DefCon 26. Perhaps having a device to identify people near you without seeing them can help you evade a stalker. The talk is given in the fun setting of the spy game. However, I think it could prove beneficial to victims of domestic abuse. A project like this could help and act as a first stage detection system an perhaps enforcement of a restraining order.

When caring such a sensor on our person, we would want to make sure that if lost or stolen it would not compromise our own privacy. This makes the Azure Sphere an ideal secure platform since there is no need for personally identifiable info on the IoT device, and yet it always maintains it's identity making it useless to someone else.

The device is to use the built in Wifi to scan for SSIDS, then connect to the configured Wifi to send the update to Azure. Later the plan is to use additional external modules to scan while keeping a stable connection to the Internet. Other add-on modules will scan for BLE and other things that can be used for identification. Perhapse detecting and fingerprinting Bluetooth with a BLE click or off load some of the wifi listing to ESP8266. Eventually I would like to add deauth detection and other suspicious wireless activity detection to the edge.

Identifying what is around you is the first step. I identifying threats is the second.

Plan

For the scope of this project I am going to stick to the sensors on the Avnet board and the MT3620 module. The basic function will be to list the networks, fingerprint them, and send the readings to IoT Hub for collecting and computing. We will craft the data so that we can send several types of readings in the future.

On the server these items will be associated, and events raised. This will allow for various alerts to be configured to be triggered in certain situations. The software project will be ongoing. Obviously the server side being the most complex, but I hope to expand the client as well.

The goals are: identify WiFi nodes; identify them as friend, foe, or indifferent; alert when a flagged node is detected.

Learning the things

First, Azure Sphere is not initially aimed at the grassroots, entry level developer like Arduino or Raspberry Pi. There is more involved than plugging the board in and uploading the blink sketch. Azure sphere is meant to be hard for someone to hijack after it is deployed or otherwise sold. Even when someone has psychical access. (read a good example why this is important) MT3620 is compatible with just about any IoT service, but it's chip level security and OS is handled by Azure. All this may sound complicated. However most of the complexities of securing a device like this is taken care of for you. To understand the rest there are some great resources out there, and I would suggest you visit those first so you don't get frustrated too much before you even start.

I will be honest, I had a starter kit for nearly a year before I tried anything, and then due to holes in the instructions I set it aside for a while longer. Both the Azure portal and the documentation have improved greatly. It seems Microsoft is learning the good from the Open Source community at large and mixing in their decades of experience to actually be making a thing of beauty.

The best resources I have found are from Hackster and Microsoft themselves. Hackster has a great workshop that walks you through many of the basics of Azure Sphere with the Avnet starter kit. I would highly recommend it. We are going to hook this up to Azure IoT Hub. Fortunately Microsoft has recently leveled-up their documentation and created some great training. Check out the Azure IoT Modules.

Before you begin

At the time of writing, the MT3620 tooling only runs on Windows 10. In the future it is planned to have Linux support, this will give everyone added flexibility. Part of securing the Azure Sphere is claiming the device. To do this you need an Azure account. There are many ways to do this for free and even a pay-as-you-go account can be locked down to control spending.

• Grab yourself a copy of Visual Studio (there is a community edition).
• Install the Azure Sphere sdk
• Claim your device (this can prove a hanging point, don't give up)
• enable application development from the Azure Sphere Developer Command Prompt with the command:

azsphere device enable-development

Putting it together

There is plenty of sample code that is available in the Azure GitHub repository. You will want to use the following sample libraries to manage Wi-Fi connections.

GPIO - we can take some input and flash an LEDWiFiConfig - Manages WiFi configuration on the deviceNetworking - Manges the network configuration of the devicelog - give yourself some output while developing

The MT3620 requires you to specify the things it is going to be doing. So you need to Tell it that you will be controlling WiFi and what GPIO we will be using. Once the code is built and uploaded to the device watch the output to see the successful posting to Azure IoT Hub and updating the device clone (we are sending a bunch of extra info for fun at this stage).

What is next

I would like to publish a stand alone API for ingesting fingerprints and alerts. It would also be useful for some to have some sort of integration with beats to allow for correlating with activity in Elastic Stack.

I can look at the data in Azure IoT Hub, but my next step is to create a WebJob and some Azure Functions to do some alerting using Notification Hub. A logical development of this would be to show alerts on the device. This would require the device to listen to the Notification Hub

I also want to add I2C to talk to several subordinate configured peripherals like an Esp8266 to have better WiFi management. To secure this external chip that is meant to be easy to modify, maybe it will be possible to send it fresh firmware from the MT3620.

To save energy, I want to take better advantage of the architecture and scan more often when it seems likely to be activity. I could detect people with motion sensors, or sound, or abrupt changes in light.

Sharing the information you gather would interest some I am sure. Crowdsourcing your counter surveillance data to form detection grids of mobile sensors would be fascinating.

Another logical step is to design a custom PCB. I have some PCB art I would love to pair with this so it looks cool. Maybe as a Defcon Indy Badge.

If you like this project, reach out and let me know or let me know what you did with it.