AWS is excited to announce new and updated architectural guidance and design patterns for securing modern Connected Vehicle platforms with AWS IoT. You can find updated guidance for modernization in the complementary blog, Building and Modernizing Connected Vehicle Platforms with AWS IoT.

Connected Vehicle platforms provide connectivity to cloud resources, enabling the automotive industry and manufacturers to unlock new customer experiences. Features like remote commands to vehicles, driver profile and comfort settings, infotainment features, and advanced navigation are changing the automotive experience. Customers are prioritizing the security and monitoring of their Connected Vehicle platforms to help mitigate the security risks of these features. Customers want to manage the identities of their vehicles throughout the vehicle lifecycle, encrypt their data, and monitor and respond to anomalous behaviors based on vehicle data.

We are sharing reference architectures for securing modern connected vehicle platforms with AWS IoT and other AWS services. The reference architectures focus on managing the lifecycle of operational certificates, implementing encryption, and monitoring connected vehicles at scale.

Managing the lifecycle of operational certificates

Figure 1: AWS Connected Vehicle Reference Architecture – Operational certificate lifecycle management. This reference architecture provides an overview of how to manage operational certificates at scale. For details on the numbered steps see the following link.

The operational certificate lifecycle reference architecture focuses on provisioning and managing operational certificates for the identity of a vehicle’s electronic control units (ECUs). A vehicle may have several ECUs, and many of these will connect to services in the cloud to provide vehicle features. Each ECU connecting to the cloud needs a unique identity that is used to authenticate and authorize services to enable these features. A commonly used ECU identity is an asymmetric private key, usually stored in a secure software or hardware module such as a Trusted Platform Module (TPM) or a Hardware Security Module (HSM), and an X.509 certificate corresponding to that private key issued by a trusted Certificate Authority (CA). These certificates must be securely managed throughout their lifecycle as described in this reference architecture.

The certificate provisioning process starts on the factory floor where the ECU manufacturer provisions an attestation certificate (sometimes called a birth certificate). This step can use on-board mechanisms such as generating the private key on the ECU securely in a TPM or HSM installed in the ECU, or off-board mechanisms such as generating the key in an HSM outside the ECU. The result of this step is that the private key material and attestation certificate are stored securely on the ECU. After the attestation certificate is provisioned, you can provision operational certificates by using AWS services, enabling connectivity to the cloud in a secure, scalable, and automated fashion.

A private key and the certificate signing request (CSR) of the operational certificate is generated on the centralized gateway ECU, and the attestation certificate is used to authenticate and authorize a request to a certificate broker. The certificate broker calls AWS Private Certificate Authority (AWS Private CA) to issue an operational certificate that is returned to the ECU. AWS Private CA enables creation of private certificate authority (CA) hierarchies, including root and subordinate CAs, without the investment and maintenance costs of operating an on-premises CA. AWS Private CA also provides APIs for you to revoke certificates and provides mechanisms to check for revocation via certificate revocation lists (CRLs) or Online Certificate Status Protocol (OCSP).

The ECU can now use the operational certificate to connect to cloud services such as AWS IoT Core using TLS client authentication. AWS IoT Core provides several mechanisms to register X.509 certificates for devices that are detailed in the white-paper Device Manufacturing and Provisioning with X.509 Certificates in AWS IoT Core. Our recommendation for vehicle ECUs is just-in-time registration (JITR) that registers the ECU’s operational certificate with AWS IoT Core the first time it connects. AWS IoT Core publishes a JITR message to a reserved MQTT topic that allows you to perform additional checks before registering the certificate. The reference architecture uses an AWS IoT rule on the reserved MQTT topic to invoke a Lambda function that verifies that the certificate is not revoked using OCSP, activates the certificate, creates and attaches a policy to the certificate, and creates a thing to represent the ECU in AWS IoT Core.

With millions of vehicles, each with several ECUs connected to the cloud, it can be challenging to monitor the registered certificates and policies. AWS IoT Device Defender can help by performing audit checks such as identifying overly permissive policies, devices sharing an identity, revoked and expiring certificates, and more.

AWS IoT Device Defender sends these audit findings to AWS Security Hub which aggregates security findings across accounts, AWS services, and supported third-party partner providers. Amazon EventBridge allows you to create custom rules where you can define automatic actions for specific findings in Security Hub. For example, an Amazon EventBridge rule can trigger AWS Step Functions workflows to automate actions to rotate certificates, correct overly permissive policies, send alert notifications, and create tickets.

Encryption and monitoring

Figure 2: AWS Connected Vehicle Reference Architecture  – Encryption and monitoring. This reference architecture provides an overview of encrypting and monitor vehicle data. For details on the numbered steps see the following link.

The encryption and monitoring reference architecture focuses on the use case of sending remote commands (such as remote start, locate vehicle, door lock/unlock, windows up/down) from a mobile app to the vehicle, illustrating the encryption and monitoring options available to you on AWS. A user authenticates to a mobile app using an identity service such as Amazon Cognito and uses the app to send a remote command request to an API in Amazon API Gateway. The API request is authorized by a Lambda authorizer that validates the user’s identity token and checks that the user has the permissions to perform the remote command. Once the API is authenticated and authorized, API Gateway invokes a Lambda function to generate the remote command message. The remote command message from the cloud may need to be signed (to prove authenticity) and encrypted (to ensure confidentiality) as it passes through intermediate services in the cloud such as AWS IoT Core. The Lambda function calls AWS Key Management Service (AWS KMS) to sign the message using an RSA or ECC private key stored in AWS KMS. Additionally, the function calls AWS KMS to encrypt the message using a symmetric key stored in AWS KMS. The Lambda function sends the encrypted and signed message to the ECU using an MQTT topic in AWS IoT Core.

The ECU receives the remote command message from the MQTT topic and needs to decrypt the message by calling AWS KMS. The ECU requests temporary AWS credentials from the AWS IoT Core credential provider and uses the credentials to sign and authenticate the decrypt call to AWS KMS. The ECU then validates the signature on the decrypted remote command message using a public key corresponding to the private key used to sign the message. The ECU responds with sensitive telemetry data (such as vehicle status or geolocation) to the cloud after the remote command is successful. It can use AWS KMS to encrypt the sensitive data client-side before sending it via an MQTT topic to AWS IoT Core. The data remains encrypted as it flows through AWS IoT Core and any intermediate services in the cloud until it arrives at a Lambda function with the permissions to invoke AWS KMS to decrypt the data. The function stores the telemetry data encrypted at rest using AWS KMS in Amazon DynamoDB.

AWS IoT Device Defender Detect detects unusual behavior that might indicate a compromised device by monitoring the behavior of your connected ECUs. You can configure rule-based or machine learning (ML)-based detections for anomalous behavior based on connected ECU data. For example, AWS IoT Device Defender can generate a finding when it detects abnormal rates of authorization failures (cloud-side metric) or anomalous traffic flow (device-side metrics) for an ECU. AWS IoT Device Defender sends findings to Security Hub that can trigger remediation actions. For example, you can use a Step Functions workflow to automate actions such as limiting an ECU’s permissions by attaching its thing to a thing group with no permissions, or by inactivating the certificate in AWS IoT Core to disconnect existing connections and deny future connection attempts.

Conclusion

In this post, we covered two new AWS reference architectures for automotive customers to use when securing their Connected Vehicle platforms. The architectures are not intended to cover all aspects of vehicle security, but to focus on how you can use AWS services to secure vehicle to cloud communication, protect and monitor data, and detect anomalous behavior based on vehicle data. We encourage you to use these reference architectures as starting points as you design and secure your Connected Vehicle platforms on AWS. Visit AWS for Automotive, AWS Security, and IoT Security blogs to learn more.