Securing Vehicle Identification Number (VIN) with Reference ID 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 Reference 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 Reference ID system where each vehicle receives a unique identifier during provisioning, acting as a VIN proxy in all platform interactions. A vehicle registry database stores both hashed and encrypted versions of VINs, mapped to their Reference IDs. When clients present a VIN, the system hashes it to retrieve the corresponding Reference 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 Reference 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 audit-ability
• 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 Reference IDs and VINs

Architecture walkthrough

1. Reference ID

A Reference 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 registry database

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

• Reference ID to hashed VIN mapping
• Encrypted VIN storage
• Vehicle provisioning and state change tracking
• Device 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: deviceId 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 reference 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 registry DB to check if it’s a first-time provisioning.
2. For new vehicles, DEVICE ID can be validated against existing data made available by the TCU Manufacturer.
3. It also checks if the DEVICE is already attached to another vehicle by querying the vehicle registry DB with DEVICE ID.

3.2 Reference ID generation:

1. A query is performed against the vehicle registry 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 Reference ID.
3. The Reference ID, hashed VIN and encrypted VIN (via KMS) are stored in the vehicle registry 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 Reference ID.
4. A final query is performed by Reference ID in the vehicle registry 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 registry DB entry.

3.3 Certificate generation:

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

3.4 AWS IoT integration:

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

3.5 Response payload:

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

This process helps ensure secure provisioning of vehicles while protecting sensitive VIN information using Reference 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 Reference 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 Reference ID as the client ID.
2. All data sent from the vehicle is associated with the Reference ID, as the vehicle name in AWS IoT FleetWise = Reference ID.

4.2 AWS IoT FleetWise to data platform:

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

4.3 Data storage and retrieval:

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

The pseudonymous Reference 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 Reference ID conversion:

1. The client application, after verifying vehicle ownership, makes an API call to the platform to convert between hashed VIN and Reference ID.
2. The API queries the vehicle registry DB to retrieve the corresponding Reference ID.
3. The Reference 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 Reference ID corresponding to the VIN, it can:

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

This approach helps enhance platform security by eliminating VIN usage in API calls and maintaining separation between VINs and Reference 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 DEVICE ID in the vehicle registry DB to a new DEVICE ID.
2. Simply delete the DEVICE ID in the vehicle registry DB entry of the vehicle i.e. mark it as NULL.

6.1 TCU update:

1. Inputs: hashed VIN (or Reference ID), existing DEVICE ID, new DEVICE ID.
2. The API:
   • Verifies hashed VIN exists and matches existing DEVICE ID in registry database
   • Checks new DEVICE ID is not associated with another vehicle.
   • Updates DEVICE ID in registry 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 Reference ID), existing DEVICE ID.
2. The API:
   1. Verifies hashed VIN exists and matches DEVICE ID in registry database.
   2. Removes DEVICE ID from registry database entry.
   3. Revokes and deletes the vehicle’s existing certificates (issued during provisioning and registered in AWS IoT Core)

Note: Either hashed VIN or Reference 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 registry 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 Reference ID system enhances VIN protection by minimizing VIN exposure in daily operations. The vehicle registry DB stores only hashed and encrypted VINs, while Reference 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 registry 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 Reference 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 Reference 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