That wasn’t what we expected.
Afero was a few months old, and we had started down the path of building our first product. It wasn’t the Afero you know today.
We had started Afero in May of 2014, and began building not a platform but rather a new kind of consumer IoT device.
By July we had built a working prototype (hardware and software), but to get the security and connectivity experience just right we had needed to build a lot of infrastructure pieces ourselves. We planned to reuse that infrastructure for future products, so we had designed it in a tightly integrated but modular way. It was an investment, one that would make future product development easier and faster.
We were excited about our device concept, but found ourselves getting more excited about the framework we were building the device on. We had developed what we saw as elegant solutions for common problems that most IoT developers encounter.
That was when we realized that the Afero infrastructure was the truly remarkable part. By December of 2015 we launched the Afero IoT platform.
Welcome to our first blog post! We built Afero to let connected device developers focus on the fun stuff -- building those parts of their products that excite, delight, and differentiate.
Afero is an end-to-end secure connectivity platform for the Internet of Things, or IoT. There are many different kinds of IoT products, but all of them share a common need for secure and reliable connectivity to the Internet.
Afero tackles 3 of the big challenges in IoT:
• Rapid Development
Using the Afero platform to build an IoT device automates many complex tasks that would normally be done manually by multiple engineering teams.
In the sections that follow I will describe the common challenges facing IoT product developers, the Afero approach to tackling those problems, and some anecdotes about how we came up with the solutions.
The IoT universe is in its infancy. Building connected devices requires the harmonious integration of multiple complex technologies. Before Afero, this had to be done by hand, and was clumsy work.
Think back to the state of the internet in the early 90s with dial-up connections, PPP, FTP servers as the main tool for sharing files, and Archie for finding what you were looking for. It all worked well, and was an exciting time.
Now fast forward a decade, and think about the early 2000s. For computer users, it was a heady time! Email and chat programs were being used by everyone from kids to grandparents, and the content we consume every day was shifting to the World Wide Web.
We had cell phones, but it would take many more years of experimentation (and some false starts, like WAP browsers) to usher in our modern world of mobile computing and communication.
In a few years we will look back on this as a similar early time for IoT.
In engineering, it is useful to identify “design patterns,” or appropriate designs/solutions for common problems. These accelerate development, by providing a kind of best practices structure to address those problems. This also lets us focus more on the new problems to solve.
As happened for the internet and mobile computing, the developers and user communities will identify and refine IoT design patterns. Each new one will accelerate the development and evolution of IoT.
Before we know it, we will have gone from the IoT equivalent of stone knives and bearskins to lasers and spaceships.
Part of what makes the IoT difficult to grapple with is the broad spectrum of product capabilities.
At one end of that spectrum, we find simple IoT devices: motion sensors, temperature sensors, lights, locks, etc. -- all small devices with modest computing resources. They commonly use simple microcontrollers with tens to hundreds of kilobytes (not megabytes or gigabytes!) of memory.
At the other end, we find things like jet engines, automobiles, and medical equipment -- large, complex devices, often with substantial computing resources and sophisticated software.
Compare this with computers or phones. At a given point in time, or say for a given generation of machine, they generally have the same order of magnitude of performance and generally the same collection of peripherals.
The concept of an “Operating System” is to abstract the hardware details away, making it easier to write software. When the hardware details vary substantially, providing that abstraction can be impractical.
This is why the traditional idea of an Operating System doesn’t work for IoT devices. They have too much variation in their capabilities.
Connected devices span a broad range of complexity. Some devices, like motion detectors, door locks, and lights are very simple. Others are very complex -- devices like cars, aircraft engines, and medical equipment incorporate sophisticated hardware and software performing complicated tasks. Regardless of whether it is simple or complex, creating a connected device requires three different software development efforts to integrate harmoniously:
• Embedded Software
• Mobile Software (for multiple platforms)
• Cloud Software
It’s all software development, so what’s the big deal? The hardware resources provided to each effort vary substantially, and this directly impacts the software development best practices. Designs that are appropriate for cloud software don’t work at all on many embedded systems due to lack of processing power, memory, or other resources. Embedded development is often like a sport, trying to squeeze as much out of cost-constrained hardware as possible.
Getting all three software efforts to work well together can be tricky. The engineers building each of those pieces have to work hard to ensure that each piece communicates with each other piece securely, reliably, and quickly.
During the formative IoT device development months at Afero, we found that there were no tools that pulled all of the pieces together in the ways we wanted. Within each software discipline there are many well-known design patterns and tools, but few that span and tie together the different efforts.
In studying how many existing IoT devices were constructed, we often came across the dreaded “Frankenstein” approach. Bits and pieces were lifted from each discipline and cobbled together. Compressed development schedules and limited expertise in some of the critical areas led others to compromised design performance, security, or both.
Many of the original Afero team had worked together at other connected device companies -- but well before the term “IoT” was coined. Places like Catapult (X-BAND), WebTV, and Danger, known for lightweight devices imbued with capabilities beyond what their hardware could do, by virtue of a powerful cloud service. Many also came from well-known cloud companies like Twitter, Netflix, Amazon Lab126, and Google.
With that experience, we thought about how we, as IoT developers, would want these core software components to work:
• Out-of-box setup (onboarding)
• Hubs / Gateways
• Device management, sharing, choreography
• Mobile integration
• Cloud APIs
We then built the tools we, as developers, wanted. We wanted Afero to handle, in the default case, all of those things as automatically as possible.
When building an IoT product with Afero, you start by creating a simple model for what data you want to share between your device and a set of secure RESTful APIs. We call these pieces of data attributes. You can imagine them as special variables that automatically and securely reflect between the device and the cloud service.
For a product like a door lock, the attribute could be simply the lock’s state. You can read or write it from the Afero Cloud using RESTful APIs. For a more complex device like an air conditioner, there could be attributes for the current humidity reading, room temperature, target temperature, and fan speed.
A web-based tool called the Afero Profile Editor (or APE) walks you through building that data model.
APE also lets you define a mobile user interface for your design. This UI is presented in the Android and iOS versions of the Afero mobile app, but you can also build your own app(s).
Once the model and UI are defined, APE is used to deploy your design. Remember the three different software development efforts needed to build an IoT device? APE generates the core pieces for you and deploys them over the internet:
• Device Profile, a data structure loaded into a device which includes the Afero embedded stack (such as the ASR-1 secure Bluetooth® Smart radio module).
• UI Profile, which is a JSON object that is used by the Afero mobile app to render your user interface.
• Cloud Profile, which defines the RESTful APIs used to communicate with your device, which are derived from the model you defined.
All of those components are machine-generated, based on descriptions given to APE. They are all in sync and are secure (more on that below).
For designs which use the built-in embedded I/O capabilities of the ASR-1, it is possible to build complete, end-to-end secure IoT devices with a mobile experience and cloud APIs without writing any software.
Of course, we realized that many developers will want to write software! By building APE, we greatly reduce the time and headache needed to get a design up and running. Experienced developers can go faster, and can extend the automatically generated pieces. At the same time we enable less experienced and even non-technical developers to build products they could not have otherwise!
As we studied how many existing IoT devices had been built, we also quickly realized that security, if present at all, typically looked like a band-aid that had been tacked on late in development.
Vulnerabilities in embedded Linux distributions, replay attack vulnerabilities in smaller embedded systems, and plain lack of any security were common discoveries.
It isn’t too hard to understand why this is. The needed kind of security work is specialized, and most companies don’t have those resources on staff. There is always a lot of pressure to ship, get the product out, and start making revenue.
Sometimes the product function (say, a step tracker or smart water filter) can seem frivolous enough to not warrant security. That’s a slippery slope. Attackers can sometimes take advantage of a device for unexpected reasons -- for example, observing the presence or absence of understandable transmissions to figure out whether or not there are people in a particular place.
We realized that security would be a vital part of any successful IoT platform, and what we were seeing was an artifact of the early days of the industry. We had to get this right. The best way to do that would be to design secure communication as a foundational element, then build everything else on top of that.
We started by adopting best practices from the computer security world, and architected Afero to use them even though the devices might have modest computing resources. Afero uses public key cryptography, with unique key material stored only in hardware security modules in the devices and the Afero Cloud. Each device has its own unique keys, which are provisioned at the factory. We use these to generate a session key using the ECDH-256 algorithm. Once generated, that session key is used to encrypt and decrypt all traffic between the device and the Afero Cloud traffic using AES-GCM.
Some IoT devices need an intermediary device, a hub, to reach the internet. With this security approach, we don’t need to store any credentials on those hubs. In fact, this makes the Hub design very simple, as it just passes messages between the internet and whatever local communication technology is used by the IoT device.
Our first generation Afero Secure Radio, the ASR-1, uses this functionality. This enables Afero Dynamic Hub capability, which allows devices to freely roam between hubs (even at multiple physical sites) without the user doing anything. It also lets Afero devices use smartphones and tablets as hubs.
Atop the cryptographic security measures, we added additional measures to make IoT device traffic characterization difficult.
We realized that many IoT devices are simple, and many also have mechanical subsystems that often take the same amounts of time when operated. Those offer would-be attackers a vector by characterizing the timing of encrypted messages relative to some mechanical operation.
For example, imagine a connected door lock. Even with encrypted control and status messages, it may be possible for an attacker to take advantage of mechanism-specific timing characteristics to form some confidence about the presence or state of the lock by observing the relative timing of encrypted messages as they are transmitted.
Afero makes such characterization difficult. Within each encrypted message, there is a programmable “response jitter” parameter. This parameter instructs the Afero stack to wait some amount of time before sending any response to the message. This allows the Afero Cloud to control (and randomize) the timing between commands and responses, masking timing artifacts created by deterministic parts of the IoT device.
Finally, all IoT device data is stored encrypted at rest in the Afero Cloud database. That data belongs to the IoT device owners, so only they are able to inspect it.
Remember how I said that embedded development is like a sport? Often it is a sport you have to play with really old equipment. Like sometimes over a decade old.
Sometimes products are built as “Greenfield” development. This means that the developer has a clean sheet of paper -- new hardware, new embedded software, and free choice of development tools. Other IoT platforms are built purely for this kind of development, because the platform prescribes a particular level of processor performance, a certain amount of memory, or a specific OS.
Most of the time, though, products are built as “Brownfield” development. This means that the developer inherits some or all of the hardware, embedded software, and tool decisions. Sometimes those decisions are very old!
So why not just ask the developer to upgrade to modern stuff? Well, those inherited decisions also usually come with some good and valuable aspects: hardware cost advantages, organizational familiarity (how fast can the team turn an old product into a new product), and sometimes many years of testing/QA.
Consider an air conditioner manufacturer. Most have been around for a long time, and have developed internal platforms (or chassis) for building air conditioners. When they decide to build a new model, they rarely start from scratch. Rather, they select a legacy chassis that is close to what is desired for the new model, and they modify it. That enables them to build a new product quickly and with less risk than if they started from scratch.
We designed Afero specifically to be respectful of both development approaches. The ASR-1 hardware interfaces contemplate both standalone use for simple devices like locks, sensor, lights, etc. as well as integrated uses where it is connected to a more complex system.
If you’ve read this far, thanks -- we had a lot to cover, and we’re almost done.
From the preceding sections, you can see that Afero covers a lot of ground for IoT development, security, and connectivity.
As I mentioned, we wanted Afero to let developers focus on the exciting and differentiating parts of their products. We wanted security and connectivity to fade into the background.
To do this, we felt it was important to require the developer to learn as little new stuff as possible. Learning new things is fun, but we think it’s more fun when you can choose what things are most important to learn.
With APE, the Afero Profile Editor, we give developers a graphical UI that walks them through defining Attributes (and so RESTful interfaces), defining a mobile experience (for iOS and Android), and deploying it the device, the Afero mobile app, and the Afero Cloud.
At that point, the developer has a fully working end-to-end secure IoT device, with a mobile experience and cloud APIs. The choice is the developer’s, then, as far as how much or how little to customize or extend.
This approach accelerates the development process, covers a broad spectrum of developers, and minimizes the potential for errors by letting a machine (rather than groups of people) handle the core integration.
Again, we want to help developers focus on the fun stuff -- the differentiating features and technology that set their products and services apart. Secure and reliable connectivity is something that everyone needs, and getting it shouldn’t require reinventing the wheel.
We believe that product developers, service providers, and users will appreciate the way Afero lets the how of connecting to the internet fade into the background so the focus can be on the why.
We’ve built Afero to be accessible to a broad range of developers, from novice to expert, and invite them all to try Afero and see how it can accelerate and improve product development. Our development boards enable experimentation within minutes of unwrapping them.
There are many ways to connect the things that matter. Afero lets you connect them better.
We’re looking forward to hearing from you, and hearing about what you build!back to all blog posts