Recap: Hands-on Session with Things Network Board & a Helium Network Board (IoT)

John Lindsay presented a light overview of the Things Network and Helium Network based on the following topology:

There was a Things Uno connected with a breadboard with a photoresistor and LEDs and a Things Node (modified SparkFun board with several incorporated sensors). Originally, the plan was to rely on existing Things Network and Helium Network gateways. Fortunately, our benefactors at Object Spectrum provided a Things Network gateway and a Helium Network gateway.

The presentation continued with an overview of a complete application/system architecture using the Invisileash dog collar as the working example, where the dog collar includes a radio and GPS (“device”). When the dog is lost, the dog collar transmits GPS information over the Things Network (“gateway”) and a companion mobile app (“application”) uses the GPS data to display the dog’s location.

Facilitating the application layer, The Things Network and Helium Network include some basic integrations like HTTP integration and MQTT. The Thing Network includes a storage integration and AWS IoT integration (Helium plans to release this integration).

Before attendees started working with the boards, an application created by John based on the “Dog Collar” example was shown as a walkthrough for the stack, from device to application. The breadboard was the “electronic dog collar with the radio and GPS,” which would transmit the sensor data over the gateway. The Things Network converted the sensor data in JSON packets for the storage integration and published the dog collar data over MQTT. The sample Android app screen pictured below allowed the dog owner to activate the GPS (published over MQTT), receive position data (subscribed over MQTT,  along with storage integration), and display it on a map to assist finding the lost dog.

I believe that everyone who attempted was able to connect the prototyping board to their computer and send sensor payloads to their account and trigger the LEDs from their account over The Things Network.

Recap: Google Environmental Sensor Board and IoT Core (of the Google Cloud Platform)

Google recently released the Coral Environmental Sensor Board ( https://blog.hackster.io/google-releases-coral-environmental-sensor-board-for-the-raspberry-pi-d63245510fbb ), a board with a light sensor, barometric pressure sensor, and humidity/temp sensor, as well as connections for UART, I2C, and PWM. Its further goal is to allow you to securely link your projects and collect, analyze, and process the sensor data using Google’s lineup of various tools. The sensors and connectors on Environmental Sensor Board are interesting but what piqued the interest for the event was Hackster’s article stating:

Google states that the board includes a single key (private, public, and certificate) that will enable communication with the Cloud IoT Core right out of the box.

I was unable to locate (and did not make any significant effort to) Google making that assertion but Google’s Getting Started guide states:

 It includes a secure cryptoprocessor with Google keys to enable connectivity with Google Cloud IoT Core services, allowing you to securely connect

By the time of this posting, I was not able to connect to IoT Core out of the box nor confirm an onboard cryptoprocessor. I was successful using the getting started guide to display sensor values locally on the Environmental Board’s OLED screen. A post on the Coral support repository outlines steps to push data from the Environmental Board to IoT Core. Note that those steps include manually creating a key pair and that the steps were based at least in part with Coral support. Also note that the Environmental Board API doesn’t reference a cryptoprocessor or secure communication. The Coral CloudIot Core API lists a publish_message method which could employ the out of the box secure communications, although the question would remain how to later ingest that published message. No response from direct email to Coral support was received by the time of this post. Unfortunately I agree with the support repository post:

the ‘getting started’ doc for this board just wasn’t deep or broad enough

For the event, we used a slightly modified blend of the IoT Core Quickstart, where attendees pushed data from the Pi to IoT core and viewed the pushed data.

 

 

Playtime with Mozilla WebThings

Mozilla WebThings recently moved out of experimental phase ( https://www.i-programmer.info/news/91-hardware/12721-mozilla-webthings-isnt-an-experiment.html ) and is their foray into the Internet of Things (currently primarily “Smart Home” devices ). It’s a platform for monitoring and controlling devices over the web. The core components  of a deployment are a WebThings Gateway, the WebThings Framework, and a Thing implementing the Web Thing API.  There are Node.js, Python, Java, Rust, Arduino, MicroPython, and other libraries.

Mozilla hopes that WebThings will be installed in commercial products, so this was a good reason for us to explore and assess the technology. A Raspberry Pi was setup on a LAN as the WebThings Gateway. A Netatmo Weather Station,(which uses wifi and has temperature, noise, pressure, humidity, and carbon dioxide sensors) and a Flic button (bluetooth connected button trigger) were setup as Things for for attendees to work with. Attendees brought laptops and/or breadboards/components, depending upon their interest and background.

Some attendees brought laptops and interacted with the gateway to enumerate sensors and values in Javascript, Python, and Android. One attendee brought an ESP8266 (an Arduino like prototyping board) with wired up an additional LED. He  uploaded code to the board that controls the LED states and added the custom “Thing” to the Mozilla gateway. Another attendee then created an Android client to control the LED.

 

I3 Decentralized Data Marketplace Overview

Professor Bhaskar Krishnamachari of I3: The Intelligent IoT Integrator (I3), presented “Towards a Decentralized Data Marketplace for Smart Cities” at a recent IEEE Smart Cities conference. The presentation was based on a recently released, open sourced Decentralized Data Marketplace (DDM).

John Lindsay presented an overview of the system, followed by group discussion.

Ethereum Applications Overview (Notes and Recap)


John Lindsay  presented an overview of Ethereum from an application perspective, with Ethereum being a blockchain-based cryptocurrency and distributed computing platform with a turing complete scripting language functionality. He started with the some discussion of the miners executing the programs in an Ethereum Virtual Machine.

The presentation continued with discussion of some general applications such as:

Prediction markets
Crowdfunding
EtherTweet

followed by some sensor and IoT focused Ethereum applications such as:

Selling/buying IoT sensor data
Smart Locker
Toll tag logging and payment

The presentation concluded with light discussion of the posted toll tag logging and payment code.

Ethereum Applications Overview Slides.

 

 

 

 

Blockchain Basics (Notes and Recap)

Blockchain Basics

We heard from John Lindsay on the basics of a blockchain, starting with the perspective of it being an independently usable technology from Bitcoin. We started with the fundamental elements of a blockchain:
1. Block index
2. Data
3. Hash pointer to the prior block

Afterward, the presentation moved to demonstrations from data to its hash to a block to a basic blockchain. We explored how different blockchain based technologies might configure the different elements for their use case, touching upon:
Bitcoin
Toll tag logging and payment
Smart City sensor data sharing in Singapore
Walmart supply chain tracking
Logging sexual consent

Blockchain Basics Presentation Slides

Deployable Communication System for Public Safety (Notes and Recap)

We started discussion with the Haven app, an app which incorporates smartphone data in order to determine when someone has entered the room and/or tampered with personal assets such as a computer. It uses accelerometer, camera, light, microphone, and power data in order to determine activity around the smartphone. When triggered, (reaches the configured sensitivity threshold), notifications are sent via SMS or the Signal end-to-end encryption system. Remote access is available via TOR. The Android source code is open source.

We then briefly heard from Eric Brunner, who recently completed a prototype of a thin (~.25 mm), light-weight, plastic flex sensor. He demonstrated its touch and proximity sensing as shown in the linked slide (Eric Brunner Flex Sensor) He is seeking “your help if you have comments/suggestion on routes to monetization or other potential applications.

We then heard from UNT Electrical Engineering Professor Kamesh Namuduri on a locally deployable communication system for public safety. The system is intended to aid communication in emergency response zones, for example, person to person via voice/SMS/data or sensors/IoT system in the disaster response zone. Intended ground communication devices/radios may be smartphones for person to person comms or sensor/IoT systems for supporting emergency responders in the zone.

The system can be deployed by using balloon, drone, or other air vehicle. The system may facilitate radio communication within the response zone or may employ backhaul. Duration of deployment for emergency communication systems is limited by battery-life. One remedy to limited power (and bandwidth) was a tether with a power cable and a data cable. Further research is needed to understand optimal altitude of deployment and scaling the system to increase coverage area, among others. Professor Namuduri concluded with possible future work including networking the deployed systems to mitigate and improve the system. Professor Kamesh Namuduri Slides.

 

 

 

Window Break Sensor Systems – Group Discussion (Notes and Recap)

We started with a presentation from Barry McCleland of Myconi Technologies, who recently won the Fort Worth Business Plan Competition for their devices, which measure temperature, humidity, pressure, light, in handling of pharmaceuticals and other goods during shipment.

Next we moved to group discussion of glass break sensor systems. We used the recent Mandalay Bay shooting but noted that the technologies may have some relevance in shooting, suicide, and “smash and grab” thefts. We noted that end receivers of an alert might be a front desk attendant, armed or unarmed security guard, or police officers. Regarding timing we did not know the time between the Mandalay Bay hotel glass being broken and the time the shooting started but speculated several minutes. We discussed an online suicide video where it was about 4-5 minutes before they jumped. We discussed a Willie Sutton theft where he locked the employees inside and stole jewelry from window display.

On sensors, some discussed points included included additional sensors other than just glass break detection in order to provide more usable alerts. For example audio or video might help determine the scenario and response. This raised some privacy concerns. We discussion possible use of approaches along the lines of local startup NoiseAware, which processes noise level as opposed to raw audio.

On connectivity, some discussed points include the possible viability of wifi in the presumed single ownership of Mandalay Bay. In a multifloor, multi-tenant office building LPWAN might be more viable.

 

Demand Side of IoT: Notes and Recap

We started with a presentation of opportunities in the space from Todd Russell on some federal government solicitations in our space. Part of his presentation centered around various agency approaches to adopt innovative technologies. He used the Defense Innovation Unit ExperimentalNational Security Technology Accelerator, and Homeland Security Innovation Programs as example programs. Part of one implied approach was finding an agency who has a need that matches your upcoming/nascent technology. For example, if you’re developing a highly sensitive anthrax biosensor, you might explore the Homeland Security Innovation Program. His slides are here (PDF).

Next we heard from Kurt Kelley. Kurt presented some needs that were directly expressed by the Los Angeles CIO at a recent conference. One of the needs centered around the seemingly mundane issue of cracks in sidewalks. In that vein, one of the points that Kurt mentioned centered around our enthusiastic technical focus. He suggested considering not presenting a possible solution in abstract technical terms, such as “I’ve got an IoT solution for you”, but rather “My solution detects cracks in sidewalk and integrates into existing city cameras… uses computer vision …” An excerpt of his slides are here (PDF).

Fundamental Best Practices in Secure IoT Product Development: Notes and Recap

We started with discussion of the Federal Drug Administration recall of 465,000 pacemakers that attackers can gain unauthorized access to issue commands, change settings and maliciously disrupt.

One of the vulnerabilities allowed an attacker to significantly reduce the battery life of a pacemaker. “The pacemakers do not restrict or limit the number of correctly formatted ‘RF wake-up’ commands that can be received, which may allow a nearby attacker to repeatedly send commands to reduce pacemaker battery life” Notice the parallel to the traditional cyber traffic based denial of service attack. In the cyber realm, the primary concern from the flood is the amount of traffic limiting access for legitimate visitors. In the IoT realm, the primary concern from the flood is the battery impact for the user.

We also heard briefly about proposed legislation involving baseline security requirements for IoT products.

Next we heard from  Mark Szewczul, CISSP, is an IoT Security Architect at Zimperium and technical contributor to the Cloud Security Alliance’s Future-Proofing the Connected World. He took us on whirlwind tour of best practices in secure IoT development. His ~forty slides are available here (PDF).

The core of the presentation focused on 13 areas of focus in secure IoT development. For example:
6. Protect Data – Security Considerations for Selecting IoT Communication Protocols:
•Wired & wireless scanning & mapping attacks
•Protocol attacks
•Evesdropping attacks (loss of confidentiality)
•Cryptographic algorithm and key management attacks
•Spoofing and masquerading (authentication attacks)
•Denial of Service and jamming

A good starting point for IoT security principles, testing, and mitigation is at the OWASP Internet of Things (IoT) Project.

Miscellaneous
Light interview on security/resiliency in power grid (MP3, starts at:20:39)
White paper on the “Blueborne” bluetooth vulnerability (PDF, detailed, lengthy)