Security by Design: End-to-End Encryption and Identity for Robotics Systems

Adapted from a piece I wrote while Head of Engineering at Formant. The principles still hold for any team deploying robots to the field.

At Formant we treated security as a first-class feature, and evaluated every engineering decision with the security of our stack and our customers' data in mind. Security covers data transport and storage, user/robot authentication and authorization, network protocols, and API design. This piece covers how to secure end-to-end encryption and identity throughout a robotics stack.

Traditional application security for robotics systems

The classic implementation leverages a VPN to provide a private network, a "crunchy outer shell," or perimeter-based security. It makes it easy for robot applications and cloud APIs to talk inside a private network, but the design is immediately in jeopardy the moment any VPN key is compromised or an attacker gets behind the perimeter. Imagine an attacker inside your VPN connecting to any robot's ROS Master. You also routinely see non-encrypted traffic between services and robots (APIs on http, not https).

VPNs are also hard to manage: rules for key expiration and rotation, and logs made available for audits to check for anomalous access.

End-to-end security and identity for robotics systems

A modern, cloud-native approach provides end-to-end encryption and identity across all robots, networks, operators, and APIs.

Provisioning tokens

Starting at the robot, the agent uses a one-time, short-lived provisioning token to generate the Robot Private Key. That private key is never sent to the cloud. The corresponding Robot Public Key is stored on the backend to verify signed requests from robots.

Load balancers, WAFs, and public vs. private subnets

The first layer is a public-facing load balancer with a Web Application Firewall (DDoS protection, IP blacklisting, security rules). The entire API layer runs in private subnets: no external access to compute instances or databases.

Enforcing identity of robots, users, and services

Authenticate and authorize every API call with the caller's robot, user, or service identity, in contrast to an "API token" pattern that supports anonymous clients. Identity on every call enables fine-grained access control, permission revocation, and auditing. Robot and user private keys are never sent on the wire; service tokens use symmetric encryption and rotate frequently. Each call proves identity with a short-lived JSON Web Token, so a permanent private key never crosses the wire.

TLS end-to-end

Many public-cloud apps stop at TLS termination at the load balancer and run plain-text HTTP behind it. Instead, use mutual TLS everywhere: between the ingress controller and APIs, and between APIs. Running APIs in Kubernetes lets you deploy Istio (a service mesh) and enable mTLS across all internal traffic, plus layer-7 policy rules as a second line of defense against misbehaving apps or bad actors.

Customizations for LANs: encryption via gRPC

For on-site LANs where the agent runs on a separate host, encrypt gRPC traffic between the robot application and the agent. When both run on the same host, plain text is acceptable, but security-conscious teams should consider encrypting it.

Designing for security, not bolting it on

The recurring failure is treating security as a bolt-on feature, which leaves holes (crunchy outer shells, permanent API keys). If you're improving a robot security model or preparing for an audit, that's exactly the kind of review I do.