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) containing the vehicle’s specific roles and permissions.

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 granted access to specific NATS subjects (e.g., telemetry.prod.{VIN}).

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.

---

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.
• Dynamic Permissions: Permissions are not hardcoded. A vehicle’s access to specific data topics is calculated dynamically at connection time based on its Keycloak identity.
• Seamless Rotation: Operational Certificates are short-lived. They can be rotated automatically by repeating Step 2, ensuring that a compromised certificate only has a limited window of utility without requiring a factory visit.

---

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.