Chapter 5. Data Security and Privacy Protection

One of the primary issues related to technology based methods of collecting data required for RUC is that data about personal VMT are accurate and secure at all times. The two primary data points that are required to establish an in State RUC are position data and distance traveled data. State pilots determined that designing a secure RUC system would need to consider:

• Data source availability and integrity: This defines the degree to which RUC data can be trusted and, therefore, to which VMT are accurately taxed.
• Cybersecurity: Relates to the protection of information confidentiality, integrity, authenticity, non-repudiation, and availability.
• Data storage, transmission, and access: Pilots conducted to date demonstrate that raw data may be stored in various locations and systems, specifically the smartphone MRD, which is used in the smartphone approaches, the dongle MRD, account manager web service and database and systems, and States’ RUC applications.

Pilot sites determined that maintaining and ensuring privacy of the data collected from participants may involve several factors:

• The type and quantity of raw data being collected.
• How the raw data are treated (i.e., sanitized) and where in the system.
• The intractability of performing “tracking” of drivers (requiring collection point and account manager system anonymization and sanitization practices).
• The cybersecurity posture of the system and its endpoints.

This chapter presents the preliminary and high-level findings of Phase Ⅰ sites in the process of examining data security and privacy protections of proposed mileage recording approaches.

Key Cross-Cutting Findings

Data Security

The recipients of the STSFA Phase Ⅰ grant are generally early in their development of security-related objectives, design, and deployment; therefore, security is not yet a principal focus. Architecturally, each STSFA grant recipient employs the following systems:

• Mileage collection and reporting systems/devices.
• Centralized systems.

Mileage and location(s) of miles driven are collected in mileage collection reporting systems and fed to the centralized systems for account update and RUC billing purposes. The security design of the central systems generally leans on State-mandated “conventional cybersecurity requirements,” with little to no program-specific augmentation. Security or privacy needs in the central systems were addressed using today’s best practices in network security, application/host security, data management, and privacy management typically found in most enterprises. Table 8 summarizes potential security issues on the commonly explored mileage reporting methods by Phase Ⅰ sites.

Table 8. Summary of potential security issues based on mileage reporting method.

Mileage reporting method	Description	Security summary
Vehicle telematics using a dongle attached to the vehicle’s onboard diagnostic standard II (OBD-II) port	The standardized OBD-II port obtains the vehicle’s speed, which is then integrated to produce distance traveled information. This solution can either use a Global Positioning System (GPS) receiver built into the mileage recording device to obtain location data, or obtain it from another source such as an external GPS receiver (e.g., from a smartphone application), or by entering it manually.	Vehicle telematics systems can be thwarted through “man-in-the-middle” attacks between the vehicle’s data bus (connecting the electronic control units) and the OBD-II port, or between the OBD-II port and the connected dongle. Today, there is no secure, standardized vehicle data access technology in use; therefore, access control problems raise potential data integrity and privacy problems.
Smartphone with beacon	This approach uses a smartphone application to obtain location and/or distance traveled information using the smartphone platform’s GPS. A significant technical challenge of this approach is the need to associate a phone to a given vehicle.	Two significant security issues are present with this approach: The system inherits all of the security problems of the smartphone platform—some are generally more secure than others; some are easier to “root” and compromise. The beacon is necessary to correlate position/distance information with a given vehicle. Today, there is no phone/vehicle pairing technique that is reliable, secure, and convenient. Additionally, any mandate to use Bluetooth beaconing effectively translates to privacy losses due to traceability of static addresses.
Manual mileage reporting	This approach is characterized by road usage charge program participants either taking vehicle odometer pictures via a smartphone application, or uploading to an account manager, or having a recording of their odometer readings at regularly scheduled vehicle inspections.	This method is subject to integrity problems at the source, if the manual reporting is made by the driver. If the manual reporting is made by a licensed technician or other third party, this method is likely the most secure.

Driver Privacy

Both perceived and real privacy are important factors in an RUC program, given the public’s

potential for pushback to the program based on perceptions about privacy properties and the potential for actual privacy breaches.

One of the principal challenges identified with respect to privacy is a lack of standardization concerning the data each State will collect, and what different commercial account managers may collect with regard to value-added telematics offerings. States that implement RUC systems should be prepared to address and clarify potential privacy misunderstandings between the commercial account managers and State RUC systems elements.

Maintaining data privacy in an RUC system is tied to the following aspects of collecting and handling participants’ or drivers’ data and RUC system design:

• The type and quantity of raw data being collected: Assessing the RUC pilots showed that, except in the cases of account manager value-added services, only minimal data were collected across interfaces. Data retention periods were minimized, and retention‑related requirements were generally specific and unambiguous.
• How the raw data are treated (i.e., sanitized), and where they are stored in the system: Specific methods of sanitizing and scrubbing privacy-sensitive data were generally lacking in RUC pilot documentation. In addition, data aggregation rules were not clarified or standardized. This is anticipated at this early stage of pilot planning and execution with relatively smaller participant pools. However, left unmitigated, aggregation of large amounts of raw or high-resolution data may lead to privacy losses, especially if comingled with identifying information. Higher resolution, position-time data collection may necessitate careful examination of data aggregation in conjunction with allowed data retention periods, especially as RUC programs begin to institute subregional, demand-based RUC designed to influence driver behavior.
• The intractability of performing geo-temporal driver “tracking”: As RUC systems mature and more elaborate RUC scenarios are developed, more fine-grained location and distance information collection may become necessary. Collecting too much of these data may introduce retroactive privacy breaches (i.e., tracking one’s location history). In addition to data collected, the confidentiality protections afforded the data become paramount.

Significant Phase Ⅰ Efforts Exploring Data Security and Privacy

Eastern Corridor Coalition’s Approach to Participant Data Privacy

Personally identifiable information (PII). High-level, access-control requirements were indicated with regard to PII data collection and storage. Specific policies are included in the participant agreement and in the account management specifications.

Mileage data. The I-95 pilot implemented best practices, including limiting data retention periods and destroying data at the conclusion of those retention periods. However, methods of data destruction were not specified. The Coalition developed a Technical Memorandum containing a review of potential privacy issues and solutions (see Table 9.)

Table 9. Privacy approaches and potential solutions for user control over information.

Summary of Key Privacy-Related Issues and Considerations for a Mileage-Based User (MBUF) Fee System
Choice: Providing choices for mileage reporting, thereby providing drivers with a range of options. Options would include at least one approach that does not involve any sort of mileage reporting (e.g., a time-based system), as well as not requiring a location-based approach, including specific origins or destinations or travel patterns.
Control and consent: Providing drivers with control in terms of how their data are collected (i.e., “choice” as noted above) and used. Consent means an unambiguous identification by the user signifying agreement to their personal data being collected and shared. Consent includes the ability to opt-in or opt-out of approaches that involve location information, data-sharing with other entities, and/or long-term retention of the data.
Purpose Limitation: The collection of data must have a specific and defined purpose.
Transparency: Developing an education and outreach program focusing on how information will be used and how privacy will be protected.
Data retention: Defining how long the collected data may be retained, with the goal that data should not be stored any longer than necessary.
Other use of data-sharing: Defining the extent and circumstance under which private-sector providers and account managers share (i.e., “sell”) collected data to other entities. Definition of data-sharing also includes protections and notifications should a government entity request detailed data (e.g., routes by time of day) from a private-sector MBUF provider.
Data anonymizing: Defining the extent to which data should be anonymized (i.e., removing personally identifiable information [PII]) and/or aggregated before providing the information to others.
Integrity and security: Defining PII and ensuring PII and other collected data are secure from unauthorized or unlawful processing. Security includes both technical and organizational safeguards (e.g., adoption of data security standards, encryption of personal data, and notification requirements should a data breach occur).

Data Security and Privacy Enhancements in the Oregon Pilot

The Oregon pilot’s Market Cycle Evaluation Final Report indicated that:

Oregon’s best practices towards enhancing data security and privacy, explored as part of STSFA Phase Ⅰ, are briefly summarized below:

• Account manager compliance: As part of their account manager compliance activity, Oregon redefined system requirements to enhance the security and reliability of technologies offered and systems used. Refinements included, but were not limited to: encryption of level 3 data (contains PII) in transit and at rest, authentication between systems prior to transmitting data, and quality controlled data validations in each subsystem.
• Volunteer agreement: The Oregon pilot provided a volunteer agreement and RUC privacy policy to clarify the rules governing the type, collection, treatment, and use of pilot participants’ data. Additionally, Oregon’s RUC Business Requirements documentation delineated the contractor (i.e., account manager or MRD provider) roles and responsibilities concerning privacy agreements for any value-added services or other business practices extending beyond RUC. The account manager was free to include value-added telematics offerings, consistent with its State mandate to implement and socialize its privacy policy.
• Data/privacy management and data security in the MRD: The Oregon pilot instituted a policy requiring no more than 30-days retention of raw mileage/location data to reduce the exposure of driver location data in the event of component or account manager server compromise. Additionally, data-at-rest and data-in-transit encryption were employed to protect the data storage and collection processes with respect to the dongle.
• Data/privacy management at the account manager and State RUC reporting systems: The State of Oregon does not collect raw data, only processed, interface‑defined data associated with a vehicle’s distance traveled and in what State it was traveled in a given time interval. The Oregon RUC participant privacy agreement indicates adequate policies regarding the type of information that will be collected by the State. Raw data collection is collected by the commercial account manager and is, therefore, differentiated from the State’s RUC system.