Securing vehicle identification numbers with Virtual IDs in connected vehicle platforms with AWS IoT

With over 470 million connected cars expected by end of 2025, protecting sensitive vehicle data, particularly Vehicle Identification Numbers (VINs), has become crucial for automakers. VINs serve as unique identifiers in automotive processes from manufacturing to maintenance, making them attractive targets for cybercriminals. This post explores how automakers can help securing VINs in connected vehicle platforms using AWS IoT helping ensure both data protection and system functionality.

This solution introduces virtual IDs as pseudonyms for VINs, helping enable secure vehicle data interactions without exposing actual VINs. Using AWS IoT services, we’ll demonstrate how this architecture helps automakers protect sensitive data while maintaining full functionality across automotive use cases.

Introduction

The solution uses a virtual ID system where each vehicle receives a unique identifier during provisioning, acting as a VIN proxy in all platform interactions. A vehicle ledger database stores both hashed and encrypted versions of VINs, mapped to their virtual IDs. When clients present a VIN, the system hashes it to retrieve the corresponding virtual ID, enabling secure integration with existing processes.

The encrypted VIN is added as a fail-safe measure, encrypted during provisioning using a secure AWS Key Management Service (AWS KMS). In cases where the plain text value of the VIN needs to be retrieved, it can be done by decrypting this value, ensuring that the actual VIN is accessible when absolutely necessary while maintaining strong security measures.

VINs contain critical vehicle information (manufacturer, model, year) and can be linked to personal data. Unprotected VINs in cloud environments risk identity theft, vehicle theft, insurance fraud, privacy violations, and regulatory non-compliance (GDPR, CCPA).

By implementing a virtual ID system for VIN protection in cloud-based connected vehicle platforms, automakers can help enhance data security while maintaining the functionality and efficiency required for modern automotive operations:

• They act as proxies for VINs, enhancing security and data minimization
• Support compliance with data protection regulations
• Provide flexible access control and improved auditability
• Offer scalability for large vehicle fleets and easier system interoperability
• Allow for revocation without changing the underlying VIN
• Enable detailed auditing and logging of VIN access and transformations, providing visibility into who/what has authorization to convert between Virtual IDs and VINs

Architecture walkthrough

1. Virtual ID

A virtual ID is a UUID generated during vehicle provisioning that serves as a VIN proxy throughout the vehicle’s lifecycle, creating an abstraction layer that protects sensitive VIN data.

2. Vehicle ledger database

The vehicle ledger database serves as a centralized repository for vehicle information throughout its platform lifetime. Key features include:

• Virtual ID to hashed VIN mapping
• Encrypted VIN storage
• Vehicle provisioning and state change tracking
• TCU change history
• Vehicle attributes and configurations

VIN hashing enables secure verification without exposing actual values. This centralized approach provides a single source of truth while enabling secure remote diagnostics and over-the-air updates.

Note: tcuId and hashedVin being Global Secondary Indexes enables querying vehicle details by either field.

3. Vehicle provisioning

Vehicle provisioning establishes secure vehicle management and implements the virtual ID system through data validation, secure storage, and AWS IoT integration.

Let’s walk through the key steps of this process to understand how it safeguards vehicle information while enabling seamless connectivity and management:

3.1 Data validation:

1. The provisioning infrastructure hashes the VIN and queries the vehicle ledger DB to check if it’s a first-time provisioning.
2. For new vehicles, TCU ID can be validated against existing data made available by the TCU Manufacturer.
3. It also checks if the TCU is already attached to another vehicle by querying the vehicle ledger DB with TCU ID.

3.2 Virtual ID generation:

1. A query is performed against the vehicle ledger DB to validate if vehicle is already provisioned using hashed VIN.
2. If vehicle is not provisioned already, a new UUID is generated as the virtual ID.
3. The virtual ID, hashed VIN and encrypted VIN (via KMS) are stored in the vehicle ledger DB along with other vehicle information. In the rare event of a UUID collision, the request can be re-tried to generate a new UUID as virtual ID.
4. A final query is performed by Virtual ID in the vehicle ledger DB to ensure uniqueness. If UUID collision is detected, a new UUID is generated.
5. For previously provisioned vehicles, the incoming payload is simply validated against the ledger DB entry.

3.3 Certificate generation:

• Certificates are generated using ACM PCA with Common Name = Virtual ID.

3.4 AWS IoT integration:

1. An AWS IoT Thing is created with Thing name = Virtual ID.
2. An AWS IoT FleetWise Vehicle is created with Vehicle Name = Virtual ID.

3.5 Response payload:

1. After successful provisioning the vehicle is provided with Certificates and Virtual ID.
2. The vehicle can connect to AWS IoT FleetWise using the returned certificates and ClientId = VirtualID.

This process helps ensure secure provisioning of vehicles while protecting sensitive VIN information using virtual IDs, leveraging AWS services for robust identity and access management. The vehicle can provide a Certificate Signing Request (CSR), which the provisioning infrastructure uses to generate the certificate.

4. Data collection and storage

Data collection and storage is an essential component where virtual IDs ensure secure handling of vehicle data throughout its lifecycle – from transmission to storage and retrieval. This system helps protect VIN information while enabling efficient data operations.

4.1 Vehicle to AWS IoT FleetWise:

1. Vehicle connects to AWS IoT FleetWise using the virtual ID as the client ID.
2. All data sent from the vehicle is associated with the virtual ID, as the vehicle name in AWS IoT FleetWise = virtual ID.

4.2 AWS IoT FleetWise to data platform:

• Data flowing from AWS IoT FleetWise is enriched with the vehicle name (virtual ID).

4.3 Data storage and retrieval:

1. Data in the data platform is stored using the virtual ID as the identifier.
2. Mobile app queries the data platform via the API Platform using the virtual ID to retrieve vehicle data.

The pseudonymous virtual ID contains no vehicle-specific information and serves as the primary identifier across AWS IoT Core, AWS IoT FleetWise, and associated data stores. This information-neutral approach helps ensure VIN protection while enabling seamless data operations across the platform.

5. Client application interactions:

Client applications, such as Customer Relationship Management (CRM) systems or platforms managing user-to-VIN mappings, typically deal with plain text VIN numbers. To maintain the security benefits of this system while accommodating these applications, a streamlined process for client interactions is implemented with the connected vehicles platform.

5.1 VIN to virtual ID conversion:

1. The client application, after verifying vehicle ownership, makes an API call to the platform to convert between hashed VIN and virtual ID.
2. The API queries the vehicle ledger DB to retrieve the corresponding virtual ID.
3. The virtual ID is then returned to the client application.

Security considerations:

• Access to this conversion API must be strictly controlled through robust authentication and authorization.
• All conversion requests should be logged for audit purposes and monitored for suspicious patterns.
• Implementation should include rate limiting and other security measures to protect against DoS/DDoS attacks and unauthorized bulk conversion attempts.
• Since this API enables re-identification of vehicle data, access should be limited to authorized applications with legitimate business needs.

5.2 Once the client application has obtained the virtual ID corresponding to the VIN, it can:

1. Retrieve data from the data platform using the virtual ID.
2. Perform operations directly on the vehicle by passing the virtual ID such as remote commands.

This approach helps enhance platform security by eliminating VIN usage in API calls and maintaining separation between VINs and virtual IDs. The system helps enable secure client application interactions while providing a robust framework for cloud-based vehicle management.

6. Telematics control unit change:

The TCU (Telematics Control Unit) change flow is a critical process in the connected vehicle platform, addressing scenarios where a vehicle’s TCU needs to be updated or replaced. This can occur either before the vehicle leaves the manufacturing facility or after a user has taken ownership and an issue with the TCU is discovered, requiring replacement at a service center.

The TCU Change flow can be made available as an API call with one of 2 functions:

1. Update the TCU ID in the vehicle ledger DB to a new TCU ID.
2. Simply delete the TCU ID in the vehicle ledger DB entry of the vehicle i.e. mark it as NULL.

6.1 TCU update:

1. Inputs: hashed VIN (or virtual ID), existing TCU ID, new TCU ID.
2. The API:
   • Verifies hashed VIN exists and matches existing TCU ID in ledger database
   • Checks new TCU ID is not associated with another vehicle.
   • Updates TCU ID in ledger database.
   • Revokes and deletes the vehicle’s existing certificates (issued during provisioning and registered in AWS IoT Core) since the private keys are stored within the TCU hardware itself, requiring new certificates for the replacement TCU.
3. New TCU goes through provisioning process to connect to cloud.

6.2 TCU delete:

1. Inputs: hashed VIN (or virtual ID), existing TCU ID.
2. The API:
   1. Verifies hashed VIN exists and matches TCU ID in ledger database.
   2. Removes TCU ID from ledger database entry.
   3. Revokes and deletes the vehicle’s existing certificates (issued during provisioning and registered in AWS IoT Core) since the private keys are stored within the TCU hardware itself, requiring new certificates for the replacement TCU.
3. New TCU goes through provisioning process to connect to cloud.

Note: Either hashed VIN or virtual ID can be used to identify the vehicle. Using hashed VIN is acceptable due to SHA256’s extremely low collision probability.

Both flows help ensure a secure and trackable TCU change process, with the ledger database maintaining a history of TCU changes for each vehicle. This approach maintains the integrity of the system while accommodating necessary hardware updates in the vehicle fleet

Security, performance, and scalability considerations

The virtual ID system enhances VIN protection by minimizing VIN exposure in daily operations. The vehicle ledger DB stores only hashed and encrypted VINs, while virtual IDs handle all platform interactions. Security is further enhanced through AWS KMS encryption and strict access control policies. For optimal performance and scalability, the system uses efficient UUID generation and global secondary indexes from DynamoDB for rapid queries.

Looking to the future, this VIN management system has the potential to integrate with emerging technologies such as blockchain or distributed ledger technology for tamper-proof VIN records, further enhancing security and traceability. The wealth of data automakers can collect through this system also opens possibilities for advanced analytics and machine learning applications, potentially offering insights into vehicle performance, maintenance needs, and user behavior patterns.

To assist with ongoing compliance with evolving data protection regulations like GDPR and CCPA, it is recommended to employ the latest hashing and encryption algorithms, implement granular access controls, and regularly audit your data handling practices.

This comprehensive approach not only helps safeguard VIN data but also positions the platform for future innovations in connected vehicle management.

Conclusion

This post demonstrated how virtual IDs can help automakers enhance VIN security in connected vehicle platforms on AWS. This architecture helps protect sensitive vehicle data while maintaining full functionality across automotive use cases. By leveraging AWS services like AWS IoT Core and Amazon DynamoDB, this solution scales efficiently for large vehicle fleets.

As the number of connected vehicles grows, robust security measures become crucial for automakers. This virtual ID system not only helps automakers safeguard VINs but also helps them meet compliance standards for data protection regulations. It provides a flexible framework for managing vehicle identity throughout its lifecycle, including scenarios like TCU changes.

You’re encouraged to explore how this approach can be adapted to your connected vehicle solutions. For more information on AWS IoT services and connected vehicle best practices, visit the AWS IoT FleetWise documentation and related blog posts

About the authors