Best Practices: Difference between revisions

From Automotive and Web Platform Business Group
Torakun (talk | contribs)
Torakun (talk | contribs)
Line 336: Line 336:
* [https://www.w3.org/blog/TAG/2019/09/11/security-and-privacy-for-our-times/ security and privacy for our times article]
* [https://www.w3.org/blog/TAG/2019/09/11/security-and-privacy-for-our-times/ security and privacy for our times article]
* [https://e-estonia.com/solutions/security-and-safety/ Security and privacy in e-Estonia]
* [https://e-estonia.com/solutions/security-and-safety/ Security and privacy in e-Estonia]
* [https://guardtime.com/en] Data reliability using the blockchain
* [https://www.verizon.com/business/products/security/managed-detection-response-services/machine-state-integrity/ Machine and Data State Integrity]
* [https://www.verizon.com/business/products/security/managed-detection-response-services/machine-state-integrity/ Machine and Data State Integrity]
* [https://w3c.github.io/deviceorientation/#security-and-privacy device orientation privacy]
* [https://w3c.github.io/deviceorientation/#security-and-privacy device orientation privacy]

Revision as of 16:49, 8 March 2021

In-Vehicle Application Best Practices

Organizing space for best practices for in-vehicle services VISS, 'Gen2' and RPC. Applicable to OEM specific in-vehicle APIs.

Problem statement

Standard and proprietary APIs exist for allowing application to reside and operate in the vehicle accessing and potentially setting various underlying signals and calling functions. These API act as an enabler for interoperability but even with security and privacy considerations as part of their design, do not sufficiently address the range of concerns raised by various stakeholders nor define constraints beyond scope of the given API. As such expectations are not properly set, adequate protections not provided nor are underlying computing resources appropriately regulated. The purpose in creating an in-vehicle application best practice document would be to facilitate conversations with prospective partners and application creators, defining reasonable behavior and clearly providing enforceable parameters of what they can do.

We hope to define practices taking into account the perspectives of different stakeholders in connected vehicle space. We feel many of the concerns from these sometimes opposing sides can be addressed, enabling tremendous innovation and interoperability opportunities.

W3C+GENIVI Common Vehicle Interface Initiative activity includes a common data model and standard API that resides on vehicles. Where possible these Best Practices are generalized and not specific to this standard so these conventions can be used more broadly. This data model and API can be used multiple ways and is but a component in a wider telematics ecosystem. This document will address some concerns for this larger landscape. Where appropriate, certain topics covered by other initiatives will be referenced and leveraged instead of creating and maintaining separate practices.

This document is expected to evolve as the conversation continues. Feedback welcome @@link to github issue.

Constraint Areas

Areas where constraints (information, system, connectivity) can be clearly defined and in most cases enforced by underlying systems. Deviation deems an application suspect of being compromised and part of criteria for disabling, incident reporting app to marketplace security administrators.

Hardware

Topic editors: Primarily leverage and point to external resources


Hardened enclave apps run on, see Ben's doc@@

Host OS

Topic editors: Primarily leverage and point to external resources

These should be covered elsewhere but worth stressing some and linking to good security hygiene practices.

Ensure libraries are current wrt security updates

Do not permit applications to maintain their own dependencies, eg perhaps don't allow Docker/DLL model although some argue in favor of containerization. #TG to talk to NYU researcher

Signal Access

Topic editors: Isaac, Ulf

Permitting an application to reside on a vehicle should not allow it to read much less write arbitrary signals. The reason to have granular access control for individual signal read and write is a matter of safety from mechanical and cybersecurity perspectives. A rogue application should not be able to deploy airbags for instance when a vehicle is in motion. Having the set of signals a given application would be allowed to read and which if any can be written should be clearly established in advance before installation, reviewed and approved by the automotive manufacturer or provider operating on its behalf. The reasons to restrict access range from operational safety, personal privacy and may include business decisions or legal concerns of the auto manufacturer.

Polling Frequency

Topic editors: Ted, Ulf

The frequency information is accessed on a vehicle or sampled and made available from the cloud can have privacy, safety, reliability and efficiency ramifications.

An application residing in-vehicle permitted to request specific signals should not necessarily be permitted to do so whenever it wants. Requesting signals too frequently, incessantly may overtax and interfere with the operation of the underlying control units involved, inhibiting their ability to perform their primary designated tasks. This is particularly concerning when critical operating functionality is at stake. It may also result in premature unit failure and subsequent warranty issue. The second version of VISS API specification, the service residing in the vehicle, makes clear the service may limit frequency of information availability to prevent these issues. VISS also has a number of mechanisms for subscribing to information streams based on time interval, delta differences and so forth**. Application developers should take a minimalist approach and be clear in their needs and expectations. Configuration can accompany an application governing the rate it is permitted to access signals in addition to the service following any internal policies governing rate information is made available.

As with many of the considerations in this best practices document, deviation from expected and expressed behavior should be detectable by monitors and factored into basis of a decision whether or not to suspend the application, flagging it as having a potential bug or perhaps being manipulated maliciously as part of an attack.


Lower degree of precision of specific data points, frequency or timeliness can affect the sensitivity of the information as well. Location information for example can be less sensitive if providing general vicinity, province or country instead of actual location. Delayed or lower number of data points can reduce or eliminate real-time tracking.

Sampling and off-boarding data at fixed intervals can be inefficient, needlessly sending the same or similar information that has not changed meaningfully enough for a given use case. More intelligent sampling for given purposes reduces bandwidth consumption, local and cloud storage needs and associated costs.

Computing Resources

Topic editors: Ted

Computing resources (CPU, memory, storage) available within the vehicle is confined. There will be interest in OEM and partners to run applications within this shared computing space. Applications can and should be benchmarked in the computing environments they will operate on in order to be able to observe resources used and define limits for what they can consume. In turn this will provide approximations on number and size of applications that can run concurrently and prevent creating too much load which would bog down the system and adversely affect other applications. In Linux and UNIX operating systems for example this can be achieved with ulimits and other mechanisms.

@@rework or strike following paragraph

This best practices document focuses on the technical issues and steers clear of political, financial and business topics. That said, there are third parties trying to insist on being permitted to run applications in vehicles at no cost when there are obvious capital investment, opportunity costs that translate to potential lost revenue and incremental operational costs.

The computing resources themselves are capital investments OEMs need to make in the production of their vehicles. Allowing third party applications to run in this environment presents an opportunity cost for the OEM of being able to run their own applications. While outside the scope of this best practices document, following a cloud computing business model charging reasonable and non-discriminatory operational fees would help not only recoup the investment cost but potentially provide revenue incentive for permitting third party applications to operate.

Architecturally, the in-vehicle service exposing signals should reside on a separate virtual or physical host than the applications. The service as well will want to govern the number and which signals an application can sample and frequency utilizing access control and rate limiting as is widely employed by servers on the web. A separate, paired device such as a smartphone may be permitted to connect to the vehicle service can manage its own computing resources but still needs to be aware of service resource consumption.

System Resources

@@fold in Host OS into this topic

Is an application allowed to use memcache or local filesystem storage. What system libraries can be called or any local system files accessed.

  • other interactions within the host system
  • how to instruct underlying systems to subscribe to specific signals and sampling requirements at boot for eg maintenance apps

feel free to add to list and/or take one and expand on it below

Discourage code porting of applications and libraries or at least architecture reconsideration, removing unneeded functionality.

@@libraries should be configured to compile with only the features desired to be exposed and not kitchen sink as those added but unused features provide misuse opportunities.

should be "Automotive Grade" applications

@@reiterate application behavior monitoring for bugs and abuse, probably needs its own chapter.

Network Connectivity

Topic editors: Ted, others

Allowing an application to make a connection to the outside world presents a potential attack vector and information being sent off potential personal privacy and data usage concerns.

If an application is allowed to make internet connection at all should be established in advance. When it is, to who should be known explicitly. This can be used by firewalls or other system restrictions. DNS zone files or advanced caching local name servers can be used to not only avoid the lookup overhead but prevent various related attacks and provide IP addresses for firewall rules.

All network connections should be encrypted via TLS or stronger encryption. Defer to @@@ Another optimization similar to having predefined DNS zone files for external parties' servers would be to have locally installed public key certificates. This would again prevent various common and emerging attacks and negate need for external certificate authority verification, saving time and minor reduction in network traffic. It would be worthwhile to do network based verification to ensure host isn't compromised and eg /etc/hosts isn't modified.

(see if people agree with any of these example ideas or have alternatives)

    • make environments unique, not just certs per vehicle, checksums, mac addresses of other components can be used as seeds

Push vs Pull

Scope considering likely out of scope initially, can steer towards gh issues

Current industry and better practices, contrast benefits

  • SMS wake-up
  • Open port on vehicle an attack vector
  • Port firewalling or VPN increases cellular cost
  • Cellular provider setup compromise exposes full connected fleet
  • Workarounds for full duplex communication
  • Reduce polling of offline vehicles

Bandwidth

"Every Byte Counts"

Vehicles have sporadic connectivity due to cellular reception coverage. Bandwidth has incremental operational costs based on usage. Similar to computing resources there is again the opportunity cost of trying to transmit other data and expect parties involved to be able to negotiate reasonable terms for cost recovery or even generate moderate revenue based on prioritizing data transmission, based on timeliness, volume etc.

The W3C Automotive Working Group is discussing and will evaluate various serialization, compression, sampling methodologies and other means to make data transmission more efficient.

Leverage previous presentations to group and seek specific contributors

May need multiple strategies and scale down based on connectivity, dropping data points less relevant when stale or if not needed realtime to batch for when connectivity is improved or connected to office/mechanic/home wifi.

Serialization & Compression

  • Protobuf from VSS
  • Ulf's mapping
  • EXI
  • Larger datasets can compress considerably better if sending batches

Privacy

Privacy is a prevailing topic throughout, worth making some high level statements as well as having internal anchors to privacy subtopics addressed elsewhere


Off-boarding Data

Topic editors: Ulf, Ted plus subtopic editors

In addition to privacy considerations, there are other legitimate reasons for restricting what data can be off-boarded. What can be sent off may be a subset of what an application can evaluate within the vehicle. Sometimes assessments have more meaning and value. Data can be both an asset and liability for OEM and independent parties collecting it.

A Web Application Firewall for example could be employed to inspect and ensure what data is being sent off the vehicle.

Securing backend, once off the vehicle in the cloud how to prevent data breaches


Providing data to 3rd parties

Topic editors: Glenn, Ashish, Isaac

The area of data usage and privacy is of broader concern than just automotive. For a best practices document we will want to leverage, reference or defer to other resources such as the W3C Spatial Data on the Web Responsible Use of Location Data, regulations in EU, NA (such as GDPR and CCPA) and elsewhere and make some broad suggestions, encouraging capturing explicit consent on what data can be shared with which parties for what purposes.

Either from vehicle directly or give directive to telematics provider in the cloud

See also @@LPL discussions from past.


Explicit use cases:

  • EV2grid
  • independent garages
  • insured driver evaluation
  • data access edge cases
    • data provider and/or trust authority needs to provide access for subpoena
    • user may be open to defining some criteria and conditions for sharing information, enough for trust authority to make decisions instead of specific requests (onerous for user)
    • need for realtime data sharing with no-store policy - eg report road warning

Proposals

Sticky Policy

Topic editors: Ashish

User data flows across organizational boundaries, service providers (SPs), third parties, etc. It is important to ensure that the privacy rights and preferences of a User/Data Subject are maintained even when the data is shared with the other third parties, especially since the implementation of GDPR in Europe and other such laws around the world. To do this effectively, having a machine-readable policy that can stick to data at all times can be a good practice to follow. The sticky policy defines allowed usage and obligations as it travels across multiple parties, enabling the user to improve control over their personal information [1].

A sticky policy could specify the following:

(a.) proposed use of data

(b.) obligations and prohibitions

(c.) blacklists

(d.) a list of trusted authorities (TAs)

Note: A trusted authority is an organization that provides assurance to the "Data Subject" by keeping track of promises that involved parties make to access data, along with controlling access to such data. [2]

Data security

Need for encrypting data in transmission or directly including how it will be stored in the cloud and redistributed. PRE is one way of doing so to expand as a potential solution.

Proxy Re-encryption

Topic editors: Isaac

Proxy Re-encryption (PRE)

Materials Isaac shared on PRE

minutes 2021-01-11 minutes 2021-01-12 minutes 2021-01-25


Some feel PRE may be 'overkill' in protecting sensitive information, however at present they tend to be the soul holders of the data and tend to not make raw data available to third parties. PRE provides the data provider considerable protection again compromises and exfiltration of personal, sensitive information which is a financial and reputation risk, notable GDPR fines have been imposed for inadequate protection. PRE also provides the data owner (vehicle owner, fleet operator, etc) with ability to share data with designated third parties, securely after it is collected. Clear consent and ability to impose policies with technical mechanisms will facilitate establishing marketplaces and uses of otherwise encumbered data.

PRE Use cases
  • share data with owner's insurance company
  • share data with owner's mechanic
    • allow mechanic to subcontract or seek consultation necessitating resharing data
    • allow re-sharing data with vehicle manufacturer
  • share data with servicing company (annual test of vehicle safety, roadworthiness aspects and emissions)
  • share data with vehicle manufacturer

Commercial vehicle

  • share data with third party company using the fleet?

Data Verification

Topic editors: Arman

How reliable is the data and why it matters? If we take the case of post-incident forensics, the reconciliation of various data inputs, and the verification of the data integrity (that it has not been manipulated afterwards) is the most costly and time consuming. So having a single version of the truth, with an independently verifiable data set, can offer a tremendous cost efficient value.

The data coming out of the vehicle can only bring value if it is reliable. Unfortunately, key management makes it very difficult and costly to encrypt all the data, and does not prevent false data injection. A zero trust approach means that any one should be able to independently verify the data, without compromising the privacy of that data. A keyless signature allows a hash to be created and added to a blockchain, providing a cryptographic integrity verification that would guarantee the authenticity and immutability of that data. This would allow anyone to validate the reliability of the data without releasing its content.

This cryptographic integrity can be augmented with an additional layer of security: provenance and compliance. If each component or software providing data is signed as well (digital twin), and if the component or software is compliant, then both provenance and compliance can be included in the data hash. If you define policies, these can potentially be checked in real-time and become cryptographically enforced. For exemple, if an “unsigned” equipment is installed during a repair, the owner would be notified about the implication of using a third-party equipment that can’t be verified (with the risks that it implies). This would also prevent the owner from unwillingly installing a “counterfeit” part.

Using such a dynamic attestation of compliance could potentially reduce the time to detect issues, decrease drastically the operational costs (fleet owners or car manufacturers can narrow down the vehicles at risk), and provide accountability with auditable compliance. A cost efficient risk management that would not be possible without a verifiable data reliability.

IoT interactions

Topic editors: defer initially, reach out to WoT, BMW others at later document stage


Question arose in call if IoT should be in scope for BP document? If so, worth coordinating with Adnan and/or Daniel plus perhaps Sebastian Seimens / WoT chair. Probably worth checking out if they are including any constraints in addition to enabling interaction beyond mere authentication/authorization.

Whether and how a vehicle could/should interact with other IoT devices.

In-vehicle aftermarket devices

Topic editors: Ted to try to enlist eg RJ from US DOT and/or someone from Geotab, external resources

Will largely reference and defer to external resources but need some high level framing on topic.

This is likely a political issue, OEM may not want to allow for replacement and additional parts to be able to produce signals that can be aggregated and exposed for in-vehicle or off-board purposes via VSS/VISS although the architecture should be able to accommodate. There are clearly advantages to using same structure and mechanism for exposing additional data alongside VSS.

Example TPMS with microphone in addition to pressure sensor. Considerable road safety, fuel efficiency advantages (detect alignment, balance etc issues), preventive maintenance can be achieved if tire manufacturers were able to access existing signals in VSS (eg assess tires after hard braking event or major bump registered via shock absorbers above certain speed threshold) if permitted to run logic in vehicles.

  • dashcams
  • tpms
  • other sensors - road/weather conditions

Application Certification

Topic editors: Isaac?, Ted, Arman?


@@cybersecurity and manufacturer liability angles cf Deborah, Christos and Danny

Given the serious security ramifications and corresponding safety implications, we would like to see independent application evaluation and certification including code inspection.

Ted to talk to US DOT on RATES and related projects, maybe enlist RJ to contribute directly**

One of the advantages to a standards based solution is that applications will be written to a common API instead of manufacturer proprietary ones. With the potential to run applications across multiple brands of vehicles, those applications will be subject to wider review. In addition to automotive manufacturers' cybersecurity teams evaluating applications being considered to run on their, it is advisable to seek independent review. With explicit and evolving evaluation criteria, independent reviewers can assert compliance of applications handling known concerns. Certification of this compliance provides automotive manufacturers and the application marketplace operators if outsourced, provides assurances to augment their own cybersecurity evaluations, will prompt reevaluation and ongoing compliance as additional concerns are identified and added to the certification process. Certification costs would likely be offset by lower cybersecurity insurance premium discounts. Application runtime environments can be similarly audited, reviewed and certified.

Independent entities can be entrusted under NDA to view code being run in addition to penetration testing. Application developers could receive reports, advice on rectifying issues and given the opportunity to address and submit for reevaluation.

Accessibility (A11y)

Topic editors: Ted to enlist W3C WAI contributions

Promote overall awareness of accessibility needs and use cases, independent a11y testing should be part of any application review if it has any direct human interaction be it on the head unit (IVI system), smartphone, web or other.

https://github.com/schemaorg/schemaorg/issues/254

collect links to WCAG, other applicable WAI guidelines, resources

nearby: Linked Data for Accessibility Community Group (LDA CG) monitor, see what they produce and request their review of BP doc

Policy Language

Consider viability of aligning in-vehicle best practices with a policy language to define machine enforceable details on how an application can behave in a given vehicle. There may be policy variation by manufacturer, computing and bandwidth capabilities and other factors such as party the app is being called by (owner, driver, mechanic).

Deviating behavior outside of the established boundaries of an application's policy would be monitored, reported and result in disabling application until further forensics can take place. Reporting an incident from a single vehicle back to OEM or service providers they utilize can be used to detect potentially compromised applications. This can be used to temporarily disable the application across their entire fleet to prevent widespread vehicle compromises.

An application's policy would be part of its package manifest along with additional configuration for the given vehicle platform, the code itself (no code should not be retrieved imho at run time), content such as images, dependencies, firewall (regular network and Web Application Firewall) rules, rules for SELinux, AppArmor and Smack.

If there were more continuity across manufacturers, simpler configuration files could be utilized instead of somewhat more complex policy language representations. The policy language pertaining to a given application will likely be translated into multiple configuration files or interpreted and directives given to different enforcement systems at install time.

A policy language is not only machine interpretable and therefore enforceable but understandable by humans and even translatable to legally binding contracts between OEMs and third party application providers. This can apply to the data being off-boarded, including limitations to the data's use and redistribution by third parties.

Reading list

Some suggested readings, relevant contributions welcome

Several of these likely to be referenced in our best practices document

Coordination

Groups and individuals to seek input from

  • W3C Spatial Data on the Web group will be producing Responsible Use of Location Data Best Practices
  • University of Memphis, Christos Papadopoulos
  • University of Maine - Nicholas Giudice, Tiffany Rad
  • W3C MiniApps CG
  • US DOT Volpe - Kevin Harnett, Graham Watson, RJ Rittmuller
  • NMFTA - Ben Gardiner
  • UL - RATES project
  • Colorado State University - Jeremy Daily (CyberTruck challenge)
  • University of Passau, Armin Gerl & Ashish Ashutosh
  • NIST
  • Ford - Mike Westra
  • Auto ISAC