Security Architecture & Concepts

Nexus SDV implements a Zero Trust architecture for vehicle connectivity. In this model, identity is never assumed based on network location; instead, every connection is explicitly authenticated and authorized using a multi-stage cryptographic process.

---

Security Pillars

The framework relies on three fundamental technical pillars to ensure end-to-end trust:

• Mutual TLS (mTLS) Authentication relies entirely on X.509 Certificates. The server validates the car, and the car validates the server—passwords are never used.

• Identity Lifecycle Vehicles evolve from a Factory “Birth Certificate” to a short-lived Operational Certificate dedicated to connectivity interaction as they move from production to operation.

• Token Exchange Heavy X.509 identities are exchanged for lightweight OIDC Access Tokens (JWT) for high-performance messaging and session management.

---

System Components

The following components collaborate to manage the bootstrapping and authorization process:

Component	Role in the Security Lifecycle
Factory CA	Generates the Bootstrap Certificates and establishes initial offline trust.
Registration Server	Verifies initial certificates and signs incoming CSRs via the Registration CA.
Keycloak (IdP)	The central Identity Provider. It validates Operational Certificates and issues JWTs via mTLS.
NATS Auth Callout	A specialized service that validates JWTs in real-time before allowing NATS connectivity.

---

The 4-Step Trust Evolution

The transition from a manufactured device to a connected vehicle follows a strict four-step process.

1. The Factory Process (Birth)

Before a vehicle leaves the production line, it requires an initial identity.

• Private Key Generation: A unique RSA key is generated locally on the vehicle and never leaves the device.
• Factory Signing: A local Factory CA signs a Certificate Signing Request (CSR).
• Outcome: The vehicle receives a Bootstrap/Factory Certificate. This serves as its “Birth Certificate” for the initial cloud handshake.

2. The Registration Process

The vehicle transitions from an offline “Factory State” to an “Operational State”.

• Handshake: The vehicle connects to the Registration Server using its Factory Certificate for mTLS.
• Verification: The server validates the certificate against the trusted Factory CA and verifies the vehicle’s Metadata (e.g., VIN).
• Outcome: The server issues an Operational Certificate, signed by the platform’s internal Registration CA.

3. The Authentication Process (Login)

To access cloud services, the vehicle must obtain a short-lived session token.

• Keycloak Exchange: The vehicle connects to Keycloak via mTLS using its Operational Certificate.
• X.509 Mapping: Keycloak identifies the vehicle based on the Certificate’s Subject DN (e.g., CN=VIN:1234...) and validates the issuing Registration CA.
• Outcome: Keycloak issues an OIDC Access Token (JWT), which the connectivity layer accepts as proof that this vehicle holds a valid platform identity.

4. The Authorization Process (Data Flow)

Finally, the vehicle establishes its data stream to the Connectivity Layer.

• NATS Connection: The vehicle presents the JWT to the NATS Cluster.
• Auth Callout: NATS delegates the validation to the Auth-Callout Service, which checks the JWT’s signature and expiration.
• Outcome: The vehicle is admitted to the messaging layer and starts publishing its telemetry.

The following sequence diagram provides a comprehensive technical overview of the end-to-end lifecycle—mapping how factory provisioning, registration, authentication, and authorization interact to establish a verified Chain of Trust from the assembly line to the cloud.

Where this is heading

The chain above establishes who a vehicle is, from the assembly line to the cloud. The next step is what it may do on the messaging layer: a hierarchical subject space per vehicle, so that each one is confined to its own data. That work is being done together with the in-vehicle integration for platforms such as Android Automotive OS, where the vehicle side of the connection is part of the SDV runtime itself.

---

Getting the trust anchors without a Google Cloud account

A client that has never seen this platform still has to decide whether to trust it. Its certificates come from the platform’s own authorities, which no public root vouches for, so the trust anchors have to reach the client somehow.

Nexus publishes them to a public, read-only bucket in the platform’s own project:

https://storage.googleapis.com/<PROJECT_ID>-nexus-sdv-public/pki

These are public certificates with no private key, so fetching them needs no Google Cloud credential at all — which is the point. A vehicle, a partner or a test bench can obtain the trust anchor over ordinary HTTPS, protected by the public certificate of storage.googleapis.com, without being granted access to Secret Manager or to the project.

This is what makes the self-service factory path credential-free end to end: the client fetches the anchors from the bucket, authenticates to the Factory Helper with a Keycloak client secret, and never touches Google Cloud IAM.

Fetch them fresh

The platform’s service certificates are re-issued periodically. A cached copy can be stale, or belong to a different environment altogether — the sample client launchers download them on every run for exactly that reason.

---

Credential Lifetimes

Each credential in the chain is derived from one that outlives it. That ordering is what makes renewal possible: a vehicle proves itself with the longer-lived credential to obtain the shorter-lived one.

Credential	Default	Set with
Factory certificate	730 days	FACTORY_HELPER_CERT_VALIDITY_DAYS
Operational certificate	90 days	OPERATIONAL_CERT_VALIDITY
Access token (JWT)	12 hours	Keycloak realm setting

The defaults suit a reference platform. The factory certificate in particular is an OEM decision — it is the vehicle’s way back to a defined state, so it is normally measured in years and must comfortably exceed the operational certificates issued against it.

Both certificate values are configured per platform in the .bootstrap_env. A malformed value stops the registration server at startup rather than falling back to a default, because a certificate lifetime that silently becomes something else is worse than a service that refuses to start.

Shorten the operational certificate deliberately

Nothing renews a vehicle’s certificate while it is running: the sample clients check theirs at startup. A short operational lifetime therefore needs a client that re-registers on its own — worth testing before lowering the default.

---

Key Takeaways for OEMs

• Separation of Concerns: The “Factory” logic is completely decoupled from the “Cloud” logic. The cloud platform only needs to trust the public root of the Factory CA, not its private infrastructure.
• Identity at Connection Time: Nothing about a vehicle is configured into the messaging layer in advance. Every connection is evaluated on the identity the vehicle presents, which is what allows a fleet to grow without touching the platform’s configuration.
• Renewable Identity: Operational certificates are renewed by repeating step 2, so a compromised certificate can be replaced without a visit to the factory.

---

Reference Implementation

You can see this entire flow in action within our Reference SDKs. The logic for mTLS handshakes and Token Exchange is implemented in the Python Client and our Go Client.