Saturday Oct 09, 2010

The Web of Things and Sun SPOTs

You've probably heard about energy meters that can tweet your electrcity consumption, digital picture frames that can download photos from Flickr, phones that let you track their location on the Internet, and weighing scales that can post your weight on the Web! Clearly, the Internet isn't just a network of computers any more. It is quickly evolving into the Internet of Things.

For the first time ever, more devices than new human subscribers came online with AT&T and Verizon last quarter. This is just the latest data point to validate what many have predicted -- the number of Internet-connected "things" will soon be orders of magnitude larger than the number of users and traditional computers.

Internet enabled things

"The main idea of REST is to design applications which implement their functionality completely as a set of URI-addressable resources, with HTTP being the [uniform] access method for interacting with them. In such an application, there is no need for any special interface, the application fully blends into the Web ..."

-- Erik Wilde, Putting things to REST

The Web of Things is a vision where such everyday objects are seamlessly integrated into the World Wide Web (WWW) using its well-known standards and blueprints, e.g. URIs, HTTP and REST. My colleague,David Simmons, and I offered a hands-on lab titled "Building the Web of Things with Sun SPOTs" at the recently concluded JavaOne 2010 conference. It presents the motivation, key concepts and relevant technologies behind this vision. All of the lab material -- introductory slides (see below), coding exercises and accompanying instructions -- is now available publicly. You may browse it online or download it as a ZIP file.

Tuesday Dec 01, 2009

Update: Next-Generation Security for the Apache Web Server

[Read the original article at http://blogs.sun.com/vipul. Other sites that carry this content may have trouble displaying it in its intended format.]

One of my previous blog posts talked about Elliptic Curve Cryptography, why it is being endorsed by the National Security Agency and how a small team of researchers at Sun Labs has had a big hand in promoting its wide-spread industry adoption.

A few days ago, I received notification that the development team behind Apache has finally integrated the patch that makes this next-generation security technology available to the users and administrators of the world's most popular web server. It has been a long, slow journey -- we demonstrated the first version of ECC-enabled Apache at a Sun Labs Open House in 2004 (and you thought high tech moves fast!) -- but I'm excited to see this final chip fall in place. It is a significant milestone in overhauling the cryptographic underpinnings of the World Wide Web.

The timing couldn't be better. NIST guidelines (see pages 63, 66) recommend that key sizes used with RSA (the currently popular incumbent technology) be doubled from 1024- to 2048-bits after 2010 to guarantee adequate protection of sensitive information -- think online banking and e-commerce. The big advantage of ECC is it can provide equivalent security using much smaller keys. More specifically, corresponding ECC key sizes only need to increase from 160- to 224-bits. Since the computational cost of public-key operations grows roughly as the cube of the key-size, the performance advantage of ECC over RSA increases as security needs increase over time:

Security
lifetime
RSAECCSpeed-up with
ECC
keysizeops/s keysizeops/s
Through 20101024738.91601783.62.41
(i.e. 1783.6/738.9)
Through 20302048113.4224711.4 6.27
(i.e. 711.4/113.4)

Table 1: Comparison of server-side cryptographic operations needed to establish a secure connection. These numbers were obtained with OpenSSL 1.0.0-beta2 on a MacBook Pro laptop with a 2.5GHz Intel Core 2 Duo processor and 4GB of SDRAM using the command "openssl speed rsa1024 rsa2048 ecdhp160 ecdhp224".

Table 1 compares the speed of doing an RSA decryption against the speed of an ECDH computation. These are the main cryptographic operations a web server needs to perform for establishing an HTTPS connection. As shown, ECC operations are faster by a factor of more than six for key sizes needed beyond 2010. I wouldn't expect an ECC-based HTTPS server to perform six times better than an RSA-based server because there are other operations in processing an HTTPS request that are common to both. One needs HTTPS-level testing with a tool like httpperf to determine the actual speedup. We did such a study back in 2004 and found that an ECC-based HTTPS server can handle between two to four times as many connections as an RSA-based server (for key sizes needed beyond 2010). I'd love to repeat that experiment with the latest software running on contemporary hardware when I can find some time. Stay tuned.

"More times than we can count, we've made history, without history even knowing we were there."
- Keith Alexander, Director NSA/Chief CSS, speaking at the NSA's 55th Anniversary.
  (For many years, the U.S. government did not acknowledge the existence of the
  NSA earning it the nickname "No Such Agency")

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

Tuesday Jun 16, 2009

Next-Generation Security for the Apache Web Server

Elliptic Curve Cryptography (ECC) is a next-generation public-key cryptographic technology that is more resource efficient than RSA (learn why) and was recently endorsed by the NSA for protecting sensitive US Government Information (see The Case for ECC and Suite B).

Sun Labs has played a major role in promoting wide-spread industry adoption of this technology by:

  1. Leading the standardization of ECC within SSL/TLS, the dominant security protocol used on the Internet (see RFC 4492 and its earlier versions).
  2. Contributing ECC technology to OpenSSL (version 0.9.8 and later) and NSS/Mozilla (version 3.8 and later) -- two cryptographic libraries that power the world's most popular open source web server (Apache) and browser (Firefox), respectively.
  3. Initiating and leading a cross-vendor ECC Interoperability Forum (with participants from Apache, Certicom, Microsoft, Mozilla, OpenSSL, Red Hat, RSA, Sun and Verisign) to ensure seamless interoperability between ECC-enabled offerings from different companies.

ECC has been part of Firefox since October 2006 when version 2.0 was released but isn't yet included in the default build of the Apache web server (see Bug 40132). I recently updated the patch and corresponding instructions to create an ECC-enabled version of Apache 2.2.11 with OpenSSL 1.0.0-beta2. If you happen to try out the patch, I'd love to get your feedback.

In case you are wondering "why should I care?", think of this as another step in reducing the computational cost of security so service providers like Amazon, Facebook, Google and Yahoo can turn on HTTPS by default for all user interactions (not just the login phase), thereby boosting privacy on the Internet.

Wednesday Mar 25, 2009

This, Jen, is the Internet

If you are a fan of the British sitcom The IT Crowd, you probably recognize the reference (if not, check out this hilarious video clip at YouTube).

Well ... the "Internet in a box" is a joke no more. The Internet Archive's Wayback Machine has been collecting "snapshots" of the web since 1996, allowing visitors to freely access archived versions of Web pages across time. Now, the entire archive is housed in a Sun Modular Datacenter shown on the left. Admittedly, it is somewhat bigger than the box Jen was introduced to but it's pretty cool to think this two petabyte archive (growing at over a petabyte per year) still fits inside a box.

Want to see what Yahoo! looked like in 1996? Simply enter http://www.yahoo.com in the search box and hit the "Take Me Back" button.

Here is a press release with additional information and the announcement from Brewster Kahle, Co-Founder of Internet Archive.

Sunday Mar 15, 2009

One and a Half Million Seconds Off the Grid

My previous post described an initial experiment on collecting data from a solar-powered Sun SPOT. That experiment helped uncover and fix several bugs that caused disruptions in data collection. I repeated the experiment again last month using the red-090113 release of the Sun SPOT SDK to test those fixes.

This time around, the SPOT stayed off the power grid from Feb 12 until Mar 3 -- slightly over 19 days (that's more than 1.6 million seconds) -- reporting light, temperature and other readings every 10 minutes. Unlike last time, there were no occasions when the SPOT failed to enter deep sleep. There was just one disruption and it was caused by a mySQL table crash (still not sure about the cause), but the SPOT stayed up throughout. Its reported up time as well as the time spent in deep and shallow sleep kept rising at a regular clip throughout the experiment (see plot below). Overall, the SPOT spent nearly 95% of the total time in deep sleep, around 4.5% in shallow sleep and about 0.5% in active computation. The large gap from late Feb 22 to noon Feb 23 marks the disruption due to the table crash.

It rained frequently during this experiment (click here for the local weather and look in the "Events" column under "Observations"). The SPOT did not have any special weather-proof casing so I kept it indoors -- by the window in my office -- for the most part and only occasionally took it outdoors when dry. Direct Sun light recharged the SPOT's battery more efficiently. The second plot shows variations in the USB voltage supplied by the solar panel (in light blue), the output voltage measured at the SPOT's battery (in dark blue) and the estimated remaining battery level (in red). Spikes in the light blue plot indicate periods when the solar panel circuitry charged the SPOT's battery and caused an increase in its remaining capacity (red).

The normal discharge rate for the SPOT's built-in battery (rated at 700mAh) was nearly 12% per day and a full charge would have lasted about 8 days. However, the solar panel was able to replenish about 15-18% of the battery whenever it was sunny and I suspect that this figure could be bumped up to 25-30% with some simple optimization of its orientation.

The next plots show changes in light and temperature readings as measured by the built-in sensors on the eDemoBoard. The significant dip in temperature on the early morning of Feb 20 marks the only night the SPOT was left outdoors.


We collected 2559 samples during the experiment when we should have collected 2747; 82 were lost due to the table crash and the rest (106 or 4% of the total) can be attributed to the unreliable nature of the SPOT's UDP-like radiogram communication mechanism. The distribution of lost samples is shown below and does not include losses due to the table crash. It would be interesting to study whether packet loss is correlated to humidity.

The SPOT still had about 10% of its battery remaining when the experiment ended. So what terminated the experiment? Accidental exposure to Dihydrogen Monoxide aka water! On the evening of Mar 3, the SPOT was outdoors when it started to drizzle. I was attending a meeting in a windowless conference room at that time. By the time I became aware of the change in weather outside, it was too late. The rain had caused the SPOT to stop working (see picture below).

Picture of a SPOT with rain drops.

I was able to revive the main board subsequently simply by letting it dry out. The eDemoBoard, however, appears to have been damaged. Nevertheless, it was gratifying to note that it was human error, rather than a software or hardware bug, that brought the experiment to an end this time around.

NOTE: The plots above were generated using Gnuplot. An interactive, and way cooler, version (based on Simile timeplot from MIT) can be accessed here. One can look at individual sample readings by moving the mouse over these "live" plots.

Saturday Feb 28, 2009

Experiments with a Solar-powered Sun SPOT

Environmental monitoring is proving to be a popular application for Sun SPOTs (see here, here and here). This and other similar applications require a Sun SPOT device to operate for long periods (months) using a combination of renewable energy sources (e.g. a solar panel) and duty cycling -- having the device wake up only occasionally to record and/or transmit sensor readings and sleeping for the most part.

A few months ago, I conducted an experiment that collected sensor readings from a solar-powered SPOT into a mySQL database for almost four weeks. A write-up describing the results is now available as a Sun Labs Technical Report and featured in this week's spotlight on the Labs' home page.

This experiment helped us uncover and fix several issues that caused disruptions in data collection -- the occasional inability of the device to enter deep sleep, the resulting clock reset due to premature battery exhaustion, and loss of connectivity to the database after long periods of inactivity. The report offers important lessons in the design of sensor data collection frameworks and lists both recommended best practices and potential pitfalls to avoid.

As I type this, another Solar-powered SPOT running a new version of our software has been collecting and reporting sensor readings. It has already been up for more than two weeks without any of the disruptions we saw previously leading me to believe that the fixes we incorporated in response to lessons learnt are working well. Watch this space for a follow-on post describing the latest experiment.

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.

Saturday Mar 31, 2007

Program the World: Sun SPOTs available for purchase!

Ever wondered what might be next in the ongoing evolution of computing devices from mainframes to workstations to laptops to smart phones? Did you know that the introduction of network-enabled phones more than doubled the number of computing devices connected to the World Wide Web?

This trend towards smaller and simpler is likely to continue and the next wave of computing devices is expected to bring about another dramatic increase in the size of the Web. Several research labs, both industrial and academic, have been studying tiny, battery-powered, wireless devices with the ability to autonomically sense and respond to their environments. Potential applications for these "wireless sensor devices" range from environmental monitoring to asset tracking to proactive healthcare to intelligent agriculture to ... well ... pretty much anything you can imagine!

At Sun Labs, our research team has created a small, wireless, battery-powered device, called a Sun SPOT (Small programmable Object Technology) that provides a versatile, Java technology-based platform for developing embedded applications. Each Sun SPOT is equipped with a 32-bit ARM processor and an IEEE 802.15.4 radio. Stackable boards include application-specific sensors and actuators such as accelerometers, light detectors, temperature sensors, LEDs, push buttons and general I/O pins. These devices can be duty cycled to run for months on a single charge of their rechargeable battery. Sun SPOTs have the ability to self-organize into self-healing, multi-hop network topologies and they can be reprogrammed over-the-air (securely, of course).

Sun spotsSun SPOT device
Sunspot: Hot!Sun SPOT: Cool!

Over the last few months, Sun SPOTs have been used in several university courses -- at the Art Center College of Design (e.g., in their flocking blimps), North Carolina State University, and the University of Essex --- and have earned some very positive reviews (e.g. here and here). Other high-profile projects using Sun SPOTs have covered the gamut of applications from the expected (asset tracking/monitoring, proactive healthcare) to the unexpected (innovative art exhibits) and that is precisely the point. With current state-of-the-art, developing applications for most other embedded devices is a tedious chore -- often involving learning unfamiliar languages/tools with little or no debugging support. By supporting application development and debugging via standard IDEs such as Netbeans, our platform opens up the exciting world of embedded programming to a much broader class of developers.

After several delays (caused by legal/administrative items and some other issues that we, as researchers, don't normally have to deal with :-)), the Sun SPOTs are finally available for purchase within the US. Click here to buy a kit and check out our official web site to learn more.

Today, there are over a billion Java-enabled mobile phones world-wide but it all started out almost ten years ago as a small Sun Labs project exploring Java virtual machines for the Palm PDA. Who knows what exciting developments lie ahead for Project Sun SPOT. Join us and we'll find out together.

Program the World!

Technorati Tags: ,

Sunday Oct 29, 2006

A week to cherish

In case you hadn't noticed, Firefox 2.0 was officially released this past Tuesday. As far as I know, this marks the first instance of a product targeted at the mass market with ECC capabilities. By that, I don't mean "error correcting codes" or even "early childhood caries" but a next generation public-key cryptographic technology called Elliptic Curve Cryptography. The ECC code in Firefox was contributed by our research team as part of the Sun Labs' Next Gen Crypto project. Major technology vendors are embracing ECC and 2007 promises to be the tipping point for its ubiquitous adoption. Compared to alternatives like RSA, ECC provides equivalent security using fewer computational resources.

In an interesting coincidence, it was around this time 30 years ago that Whit Diffie and Marty Hellman published their seminal paper New Directions in Cryptography that marks the birth of public-key crypto (PKC) -- at least in the open world outside top secret military agencies. Last Thursday, the Computer History Museum hosted a special event to celebrate the 30th Anniversary. It featured a panel discussion moderated by Steven Levy, author of Crypto. Panelists included Whit Diffie, Marty Hellman, Brian Snow (he was at the NSA during those years), Jim Bidzos (founder of RSA and later Verisign), Ray Ozzie (now Chief Software Architect at Microsoft and the creator of Lotus Notes, the first widely used product to include RSA cryptography) and Dan Boneh (Stanford Professor, well known cryptographer, inventor of Identity Based Encryption). The panelists were introduced by John Markoff, Senior Writer for the New York Times.

In his introduction, John Markoff claimed that no other technology, with the possible exception of nuclear technology, has had a bigger impact on our lives. Dan Boneh made a brief presentation outlining the history of public-key cryptography. If you've heard him speak, you already know how brilliant this guy is. Dan and I did our student internship together at NEC Research Institute, Princeton and I just wish some of his brilliance had rubbed off on me (where was proximity communication when I really needed it :-)). SSL, especially how it revolutionized the web by making strong cryptography transparent to end-users, featured prominently. Elliptic Curve Cryptography was also mentioned several times during Dan's presentation and he was pleased to learn about ECC in Firefox (he already knew about our ECC contribution to OpenSSL).

For me, the best part of the evening was listening to fascinating stories of how the British equivalent of the NSA had discovered PKC (which they called "non secret encryption") a few years before the outside world. If this interests you but you only have a few minutes to spare, I highly recommend reading Steven Levy's article in Wired magazine.

They were selling Levy's "Crypto" at the event and I am now the proud owner of a copy autographed by the author and the two inventors -- Diffie and Hellman. It is gripping ... I only got five hours of sleep that night but I haven't had this much fun in a while. I suppose that's a sad commentary on my geeky life :-).

This event was one of those occasions when I can't believe how fortunate I am. Growing up on the opposite side of the world (India), I never imagined that I'd get to work in silicon valley, the source of so many influential innovations, let alone be in the presence of crypto royalty -- folks of whom I'd only read about in books. WOW!!!

About

Vipul Gupta

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today