Tuesday Jul 14, 2009

Sun SPOTs, SPOTWeb and Sensor.Network

Sun SPOTs are tiny, battery-powered, wireless computers that can be programmed in Java. Different types of sensors (e.g. GPS, temperature, humidity, proximity, light) and actuators (e.g. servos, motors) can be attached to these devices for use in a wide range of applications. It has been more than two years since we started selling these and they've proved quite popular with students, researchers and hobbyists (see here and here for some pictures/videos of Sun SPOT-based projects from around the world). This blog entry discusses two web-based services - SPOTWeb and Sensor.Network - for interacting with these devices and collecting, analyzing and visualizing data from attached sensors.

The SPOTWeb service lets remote users interact with a network of SPOTs using a standard browser. Authorized users can monitor the state of sensors, applications and other system statistics. They can also install, start, pause, resume, stop and remove applications. In the following video, I walk you through many of these features (I recommend the HD-version in full-screen mode to minimize the blurriness of on-screen text). You can follow along on your own by downloading the latest SPOT SDK (red-090706 at the time of this writing) from sunspotworld.com and running SPOTWebDemo (it is one of the new demos bundled with the red release).

Sensor.Network is a web-based service for sharing, visualizing and analyzing sensor data collected from a variety of sources, e.g. mobile phones, automobiles, datacenters or embedded devices like the Sun SPOT. Besides supporting a heterogenous mix of data sources, the service supports multiple sensor installations, each of which could potentially be owned by a different entity. It places a strong emphasis on security and privacy concerns and gives researchers and scientists fine-grained control over how their data is shared with authorized partners. Additional details are available in this article. The service is still under development but the following video filmed during JavaOne 2009 provides a good overview of the currently available functionality.

Last month, I demonstrated SPOTWeb and Sensor.Network at a meeting of the Sensor Web Enablement working group at the Open GeoSpatial Consortium (OGC). The OGC is an international organization that develops standards for geospatial content and services, GIS data processing and data sharing, e.g. KML (used by Google Earth) and Sensor ML. Both of these are of interest to our potential customers like the USGS.

We are currently in the process of integrating SPOTWeb and Sensor.Network more closely and finalizing a REST-based API for Sensor.Network that would allow others to input, retrieve and share their sensor data with strong access controls.

The Internet started out in 1969 as a network of four nodes (it was called the ARPANET back then). Today, it has grown to over half-a-billion nodes that include not just computers (mainframes, servers, desktops, laptops, netbooks) but also PDAs, smart phones, automobiles, industrial equipment and home appliances. New technological developments, like the ones outlined here, promise to extend the Internet's reach to even smaller, more ubiquitous devices turning it into the "Internet of Things".

Friday Dec 19, 2008

Epidemic Code Deployment on Sun SPOTs: Take One

Today, the only way to deploy the same code to multiple SPOTs is one-at-a- time -- the user "connects" each SPOT to a host computer containing the application (either via USB or via a radiostream over-the-air) and invokes ant deploy. Epidemic code deployment is a more efficient mechanism that lets code propagate from SPOT to SPOT. Imagine several dozen SPOTs, spread over a large area in a battlefield, in need of a new software update. With epidemic code deployment, one could upgrade the software on a single SPOT (potentially, in a more peaceful, safer locale), air-drop it, and, after some time, "automagically" have the new code propagated to other SPOTs.

This sort of functionality is available in TinyOS but certain aspects of the SPOT software rule out a straight port of that code. Unlike more constrained devices, Sun SPOTs support multiple application slots and use digital signatures (based on elliptic curve public-key cryptography) to guarantee code authenticity. The private key used for code signing never leaves the host computer. The SPOTs only store the corresponding public key used for signature verification so, even after compromising a SPOT, an attacker does not gain the ability to run malicious code on other SPOTs. We'd like to retain these advantages while adding support for epidemic deployment.

In our existing suite deployment process, the host computer first queries the SPOT for an empty application slot and, based on the response, remaps all pointers in the suite. This remapping (also called suite relocation) is slot-specific -- a relocated suite cannot be sent from SPOT-to-SPOT unless the destination SPOT plans to put it in the same slot as the sender. So the first step towards supporting epidemic code deployment is moving the suite relocation process from the host to the SPOT.

Our use of standard digital signatures precludes pipelined forwarding of code from SPOT-to-SPOT -- a SPOT must receive a suite in its entirety before the signature can be verified. In fact, with the existing scheme, a suite isn't verified until the frst time it is about to be executed by the Squawk virtual machine. The use of signed hash chains gets around this problem. Here's a brief description of how this would work:

  • The unrelocated suite is divided into fixed size chunks p0, p1, ... pn-1.
  • For 0 <= i < n-1, chunk pi-1 carries with it a hash hi such that hi = Hash(pi | hi+1). Here | is the concatenation operator and H is a cryptographically strong hash, e.g., SHA.
  • Meta information, m (e.g., suite size), is sent with h0 and a signature computed over m and h0.
    Image showing Hash chain cnstruction
  • The receiving SPOT verifies the signature on the meta-information and a successful check guarantees the authenticity of its sender.
  • As each subsequent chunk is received, the recipient computes its hash and compares it against the expected value received with the previous chunk. A successful match indicates that the new chunk was sent by the same sender that sent the previous chunk.
  • Since the authenticity of each chunk can be established as it arrives, not only can the chunk be relocated and written to flash immediately, it can also be forwarded to other SPOTs down the line with full assurance.

Replacing standard signatures with signed hash chains is, therefore, the second critical step towards supporting epidemic deployment.

I'm pleased to announce the release of a patch that implements both these features. It is largely the work of Robert Taylor, a Ph.D. student at the Univ of Manchester who interned with us. Much work still remains in order to support full epidemic code deployment. For example, this patch only takes care of verifying chunks as they come in but still waits until the entire suite is received before performing relocation. The unrelocated suite must be held in memory -- a problem for large suites like the library. Hence, this patch applies the modified deployment scheme only to application suites which are typically much smaller. The start of a suite contains all the information needed for relocation so incorporating this capability is simply a matter of writing additional code. When another SPOT down the line requests new code, an already updated SPOT must be able to recreate and send the same stream that first originated at the host computer. This involves undoing the relocation operation and interleaving the unrelocated suite with the appropriate hashes. So the hash chain must also be stored in Flash along with the suite -- something the current patch doesn't do. Lastly, this version of the patch still deploys code from a host computer to a SPOT (one-SPOT-at-a-time). Instead, what's needed is a protocol for propagating the code stream from SPOT-to-SPOT in a pipelined fashion (e.g. via a cascading broadcast).

Nevertheless, this patch represents a significant step towards full epidemic deployment. Several members of the Sun SPOT community have already started thinking about this issue (see here and here) so we decided to get the patch out now even though it isn't as clean as I'd like it to be. If you try out the patch (see instructions in the README.txt file), I'd love to get your feedback.


Vipul Gupta


« February 2015