Atlas: Enabling Cross-Vendor Authentication for IoT

TL;DR

Atlas addresses trust fragmentation in IoT by enabling cross-vendor device-to-device authentication through a federated PKI design that extends ACME and a vendor-controlled DNS namespace to IoT devices. It binds each device to a globally unique, subdomain-based identity and uses the vendor cloud as the ACME client to issue X.509 certificates rooted in a global trust anchor, enabling direct mutual TLS across administrations without cloud mediation. The authors implement a full prototype across constrained hardware and a cloud stack, demonstrating sub-6-second provisioning, around 17 ms per-session latency, and scalable revocation, with experiments showing substantial latency reductions over cloud-based baselines and immediate deployability for ACME-enabled vendors. This work offers a practical pathway toward interoperable, low-latency, and secure cross-vendor IoT deployments, potentially improving resilience during cloud outages and enabling scalable multi-tenant smart-city and smart-home ecosystems.

Abstract

Cloud-mediated IoT architectures fragment authentication across vendor silos and create latency and availability bottlenecks for cross-vendor device-to-device (D2D) interactions. We present Atlas, a framework that extends the Web public-key infrastructure to IoT by issuing X.509 certificates to devices via vendor-operated ACME clients and vendor-controlled DNS namespaces. Devices obtain globally verifiable identities without hardware changes and establish mutual TLS channels directly across administrative domains, decoupling runtime authentication from cloud reachability. We prototype Atlas on ESP32 and Raspberry Pi, integrate it with an MQTT-based IoT stack and an Atlas-aware cloud, and evaluate it in smart-home and smart-city workloads. Certificate provisioning completes in under 6s per device, mTLS adds only about 17ms of latency and modest CPU overhead, and Atlas-based applications sustain low, predictable latency compared to cloud-mediated baselines. Because many major vendors already rely on ACME-compatible CAs for their web services, Atlas is immediately deployable with minimal infrastructure changes.

Figures (12)

• Figure 1: Cloud-mediated IoT architectures introduce single points of failure and heavy-tailed latency (b), rendering them unsuitable for real-time cross-vendor applications.
• Figure 2: Deployment of Atlas in vendor infrastructure: Atlas integrates with existing IoT Cloud setups, leveraging ACME for certificate issuance.
• Figure 3: Atlas Binding and Enrollment: Atlas performs DNS binding and ACME-based certificate enrollment during manufacturing. Device key pairs are generated for each device, injected once, and never stored persistently on the Atlas backend; any transient copies are discarded immediately after provisioning.
• Figure 4: Atlas Client runs alongside existing vendor software to perform certificate validity checks and automated renewal. Renewal requests reuse the device's existing public key while private key never leaves the device. When a new key pair must be issued (e.g., after firmware refresh), the full enrollment protocol in Figure \ref{['fig:device-enrollment']} is re-executed.
• Figure 5: Impact of mTLS on Resource-Constrained Devices: Atlas introduces negligible latency ($\sim$17ms) and CPU overhead (<9%), demonstrating feasibility even on microcontrollers (ESP32).