Summary

• With this week’s eero firmware update (3.8) we’ve added a public key infrastructure—a new innovative technological architecture that allows eeros to communicate locally and directly with each other and with the devices in your home without relying on the global “internet.”
• This firmware update lays the foundation to build a truly independent and isolated home network infrastructure while maintaining our rigorous security standards. This ultimately ensures eero networks will be more secure, more private, and more reliable.
• We will be releasing even more updates that build on this technological foundation to make every network more autonomous and more reliable. With our sophisticated automatic over-the-air update process, eeros continue to get better and better.

Your home network is not “the internet”

At eero, our goal is to provide the perfect network experience, whether that’s connecting to the internet or using the local network in your home. We’re interested in providing our customers with reliable and secure internet but also in improving the way software on your home network functions. We want to give our customers the ability to be less dependent on the broader internet so they can rely on their own autonomous local network as much as possible. It’s more secure, and it gives our customers more control and more privacy protection. With our newest firmware update (3.8) and recent app releases, we’ve taken significant steps to make this even better for our customers.

It might seem odd that we’re thinking about local area networks when people are excited about the Internet of Things and globally distributed ledgers. But, it’s exactly this growing enthusiasm that raises important questions about how to be responsible leaders of a totally connected landscape. At eero, we have a unique view into the future of the internet and the connected home, which is only becoming more important as users continue to bring connected devices online.

Our networks link devices together with reliable, low latency, high bandwidth communication channels. But these benefits often disappear when traffic leaves your local network for the broader internet. When devices are all connected on a local network, users are typically comfortable allowing software services—like streaming media centers and network file sharing (e.g., AirDrop)—to securely access and exchange private information. As a router, an eero is responsible for forwarding packets to the correct destination, wherever it sits. And, as a member of the digital home, we are also responsible for maintaining the intimacy of our users’ personal information and devices.

Our challenge was to figure out how to fulfill both goals at the same time and to do so while still putting privacy and security at the forefront. We did this by creating a mesh of trust—an entirely new trust model that ensures each customer’s network can be private and secure, yet still reliably connected to the global Internet when necessary.

Evolving our trust model

From eero’s founding, we deeply believed that customers deserved better than the “security optional” offerings available from other vendors. We committed to doing hard work for our users and guarantee that eero networks truly operate securely. We did this by designing a chain of trust, linking both users and eero nodes to our cloud. When a network is provisioned, a trusted user is associated with a corresponding trusted set of nodes, thus forming their network. When the user wants to update a network setting or view information, our cloud leverages the relationships to broker the deal.

As we’ve grown, we’ve also realized that we can adapt our trust model to not only be incredibly secure but also more autonomous—and so, we decided to complete the chain.

Doing this allows us to:

1. Enable independent management of our hardware directly from the app without needing to consult our remote cloud service.
2. Leverage the beneficial properties of local networks (low latency, high bandwidth, intimate & private) to enable features that enhance the product experience beyond what we’ve been able (or willing) to deliver with a cloud service.
3. Include users and their hardware, formally, as trust authorities to underscore the fact that they are the true owners of their home network and the data that flows across it.

With these three principles in mind, we set out to introduce trust relationships between the LAN software components that comprise an eero system.

Selecting a trust authority

As most things go, we started with the foundational question of identity. If two peers are to communicate securely with each other, then they must be able to verify that they are talking to the correct entity. To do this, each peer must first actually have an identity. We already employ industry grade asymmetric transport layer security (TLS) between eero nodes and our cloud, so we decided to do the same between our app and eero nodes, and also between eero nodes—giving every eero node and every mobile app a cryptographic identity.

Cryptographic identities exist in the form of X.509 digital certificates. Global entities called certificate authorities (CAs) underwrite trust for the public internet by issuing certificates to the hosts with global addresses and domain names. The problem is, these CAs don’t have access to your private networks—therefore we needed a local trust authority.

One option is to have the user be the trust authority. This would give users agency within the trust model but fails plenty of usability tests. Phones become lost. Apps get accidentally uninstalled. And, with the current state of mobile operating systems, phones are really designed to be “client OS platforms.” They only work well when a user is interacting with them, and they aren’t always available or awake. Paving over these issues for a user is one of the big advantages of something like a cloud service.

Maybe your network, then, can be the trust authority? It turns out this isn’t a great idea either. In a traditional router model where the only piece of network infrastructure is the single WiFi router, it might work. But eero is a mesh WiFi system—each eero unit participates independently and equally. Conversely, maintaining a single network authority means it has to either live on only one eero unit, or all eero units have to share secret keys. The former is not very usable, and the latter is obviously poor SecOps but also complicated to implement since the network needs to be rekeyed when a node is removed.

If we think about the scope of a local network, it’s certainly not “web scale.” We don’t suffer from the same logistical problems of the global internet (where giving every host an independent identity becomes both a technical and social burden), and our integrated system can automate identity management on behalf of our users. It’s plausible for us to maintain lists of trusted authorities for networks since the distribution is localized. In a true mesh fashion, we decided to make all eero nodes independent authorities on the network.

What about the mobile app? If we don’t allow the user to be an authority, then some service layer has to exist that allows the technical authorities (eero nodes) to extend tokens of trust to their “users.” We don’t want to reinvent a cloud services platform, that’s a little much; and, recall our 3rd guiding principle: we see users as first-class participants. So we made the entire model technically egalitarian. Users and eeros are all trust authorities.

Doing so allows us to get the best of both worlds. We avoid the usability issues of keeping the trust authority solely on a user’s phone, and it’s still easy to add and remove nodes and new mobile devices to the circle of trust.

TLS for your local network

Now that everyone is an authority, the problem is actually relatively simple. Instead of long trust chains and certificate revocation list synchronization, we simply need to manage the list of trusted certificate authorities itself and make sure that the app and our nodes only communicate with peer nodes authorized by an entity on the list. This list can be plugged directly into TLS (SSL) engines as the trust anchors, and things tend to just work. In fact, why wouldn’t they? Nothing in any standard limits TLS to a global internet context.

This also means that mutual TLS becomes simple. Everyone can issue themselves a TLS certificate, even things that traditionally only ever initiate connections like the mobile clients. Not only do clients verify “servers” but servers also verify inbound connections. Every peer is authenticated—security level 11.

A convenient property of our layer 2 mesh is that everything connected to an eero network is considered on link. Two on link devices can communicate using their IPv6 link-local addresses. Modern phones and all eero nodes are configured to support IPv6 which means their interfaces are assigned link-local addresses regardless of whether further IPv6 provisioning is enabled on the network. TLS allows for IP addresses (and in fact many other types of identifiers besides domain names) to appear as entries in the Subject Alternate Name extension used during hostname verification. We made sure each node includes its link-local address as an IP SAN entry when issuing itself a TLS certificate, so that hostname verification works.

If you’ve been following closely, you’ll notice I’ve skipped over a critical component: compiling the initial trust list. The list does not appear out of thin air. Just like physical chains, we build it one link at a time. We leverage our existing trust relationships between our cloud and users and our cloud and nodes to bootstrap the trust list during initial network provisioning. Afterward, the list can be freely updated by any trusted peer. We are not required to start with our cloud, either. In the future users and nodes might agree on a list early in the provisioning process and then complete the rest of the chain when online services become available.

eero PKI

To recap, we’ve added a public key infrastructure to every eero network capable of operating in isolation from the global internet’s TLS system. This addition to our identity model lays the technical foundation required to build out truly independent and isolated home network infrastructure without sacrificing security. Enabling our systems to operate independently reduces the impact of internet outages and failures on users. And, perhaps most importantly, it empowers users and reinforces their position as the true arbiters of their home infrastructure.

Using our newly minted PKI to enable TLS for secure local network management is a good first step, but having enterprise-grade security infrastructure at hand means we can also start exploring certificate-friendly protocols like EAP-TLS, DNSSEC/DNSCrypt, ACME, and LDAP. Imagine never needing to enter a network password, unspoofable DNS queries, automatically issuing and updating TLS certificates for all hosts on your private network, and cryptographically managing access to your network resources. Conveniences like these are usually only available to enterprise IT customers with a budget for integrated solutions or to power users who have the time and knowhow to deck out their networks for fun. Perhaps eero can begin to fill the gap.

Written by David Cowden, Engineer working on eero’s local network management infrastructure.