AWS is thrilled to announce the release of new architectural guidance and design patterns for securing modern Connected Vehicle platforms with AWS IoT. You can find the updated guidance in the accompanying blog post titled “Building and Modernizing Connected Vehicle Platforms with AWS IoT.” Connected Vehicle platforms play a crucial role in providing connectivity to cloud resources, allowing the automotive industry and manufacturers to create new and enhanced customer experiences. These platforms enable features such as remote commands for vehicles, driver profiles and comfort settings, infotainment capabilities, and advanced navigation, all of which are transforming the automotive landscape. However, ensuring the security and monitoring of these platforms is of utmost importance to customers, as it helps mitigate the potential security risks associated with these features. Customers are seeking ways to manage the identities of their vehicles throughout the lifecycle, encrypt their data, and monitor and respond to any anomalous behaviors based on vehicle data. To address these needs, we are sharing reference architectures that focus on securing modern connected vehicle platforms using AWS IoT and other AWS services. These reference architectures specifically cover the management of operational certificates, encryption implementation, and monitoring of connected vehicles at scale. The first reference architecture discusses the management of operational certificates. It provides an overview of how to manage these certificates at scale. The certificate lifecycle reference architecture focuses on the provisioning and management of operational certificates for a vehicle’s electronic control units (ECUs). A vehicle may have multiple ECUs, and many of these ECUs connect to cloud services to provide various vehicle features. Each ECU requires a unique identity to authenticate and authorize services enabling these features. Typically, an ECU identity consists of an asymmetric private key, stored securely in a Trusted Platform Module (TPM) or Hardware Security Module (HSM), and an X.509 certificate issued by a trusted Certificate Authority (CA) corresponding to that private key. The reference architecture details the secure management of these certificates throughout their lifecycle. The certificate provisioning process begins on the factory floor, where the ECU manufacturer provisions an attestation certificate (also known as a birth certificate). This step involves generating the private key on the ECU securely within a TPM or HSM installed in the ECU, or generating the key outside the ECU in an HSM. The result is that the private key and attestation certificate are securely stored on the ECU. Once the attestation certificate is provisioned, operational certificates can be provisioned using AWS services to establish secure, scalable, and automated connectivity to the cloud. A private key and certificate signing request (CSR) for the operational certificate are 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 interacts with AWS Private Certificate Authority (AWS Private CA) to issue an operational certificate, which is then returned to the ECU. AWS Private CA allows the creation of private certificate authority hierarchies, including root and subordinate CAs, without the cost and maintenance associated with operating an on-premises CA. AWS Private CA also provides APIs to revoke certificates and mechanisms to check for revocation using certificate revocation lists (CRLs) or the Online Certificate Status Protocol (OCSP). With the operational certificate in hand, the ECU can now connect to cloud services like AWS IoT Core using TLS client authentication. AWS IoT Core offers various methods to register X.509 certificates for devices, as explained in the whitepaper “Device Manufacturing and Provisioning with X.509 Certificates in AWS IoT Core.” For vehicle ECUs, the recommended approach is just-in-time registration (JITR), which registers the ECU’s operational certificate with AWS IoT Core the first time it connects. AWS IoT Core publishes a JITR message to a predefined MQTT topic, allowing additional checks to be performed before registering the certificate. The reference architecture employs an AWS IoT rule on the predefined MQTT topic to invoke a Lambda function that verifies certificate revocation 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. Monitoring the registered certificates and policies for millions of vehicles, each with several ECUs connected to the cloud, presents a challenge. To address this challenge, AWS IoT Device Defender can be utilized to perform audit checks, such as identifying overly permissive policies, devices sharing an identity, revoked or 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 providers. Amazon EventBridge enables the creation of custom rules, allowing automatic actions to be defined for specific findings in Security Hub. For instance, an Amazon EventBridge rule can trigger AWS Step Functions workflows to automate actions such as certificate rotation, resolution of overly permissive policies, generation of alert notifications, and creation of tickets. The second reference architecture focuses on encryption and monitoring of vehicle data. It specifically addresses the use case of sending remote commands (e.g., remote start, vehicle location, door lock/unlock, window control) from a mobile app to the vehicle. The architecture demonstrates the available options for encryption and monitoring on AWS. The process begins with a user authenticating themselves to a mobile app using an identity service like Amazon Cognito. The user then utilizes the app to send a remote command request to an API hosted in Amazon API Gateway. The API request is authorized by a Lambda authorizer, which validates the user’s identity token and verifies that the user has the necessary permissions to execute the remote command. Once the API is authenticated and authorized, API Gateway triggers a Lambda function to generate the remote command message. As the message travels through intermediate services in the cloud, such as AWS IoT Core, it may need to be signed for authenticity and encrypted for confidentiality. To achieve this, the Lambda function leverages AWS Key Management Service (AWS KMS) to sign the message using an RSA or ECC private key stored in AWS KMS. Additionally, the function employs AWS KMS to encrypt the message using a symmetric key also stored in AWS KMS. The encrypted and signed message is then sent to the ECU using an MQTT topic in AWS IoT Core. The ECU receives the remote command message from the MQTT topic and proceeds to decrypt it by making a call to AWS KMS. The ECU obtains temporary AWS credentials from the AWS IoT Core credential provider and leverages these credentials to sign and authenticate the decrypt call to AWS KMS. Next, the ECU validates the signature on the decrypted remote command message using a public key corresponding to the private key used to sign the message. Once the remote command is successfully executed, the ECU responds with sensitive telemetry data (e.g., vehicle status, geolocation), which is sent back to the cloud. Before transit, the ECU leverages AWS KMS to encrypt the sensitive data client-side. The encrypted data flows through AWS IoT Core and other intermediate cloud services until it reaches a Lambda function with the necessary permissions to invoke AWS KMS and decrypt the data. Finally, the function stores the decrypted telemetry data at rest using AWS KMS in Amazon DynamoDB. To ensure the security of connected ECUs, AWS IoT Device Defender Detect can monitor their behavior and identify any unusual activities that may indicate a compromised device. Rule-based or machine learning (ML)-based detections can be configured in AWS IoT Device Defender, allowing the detection of anomalous behaviors based on connected ECU data. For example, AWS IoT Device Defender can generate a finding when it detects abnormal rates of authorization failures (a cloud-side metric) or unusual traffic flow (device-side metric) for a particular ECU. These findings are sent to Security Hub, which can then trigger remediation actions. For instance, a Step Functions workflow can be implemented to automate actions such as limiting an ECU’s permissions by attaching it to a thing group with no permissions or deactivating the certificate in AWS IoT Core, thereby disconnecting existing connections and denying future connection attempts. In summary, AWS has introduced two new reference architectures to assist customers in securing modern connected vehicle platforms. The first reference architecture focuses on managing the lifecycle of operational certificates, while the second addresses encryption and monitoring of vehicle data. By following these frameworks, customers can enhance the security of their connected vehicle platforms on AWS.
