Automotive WG - Security Day

<inserted> scribenick: kaz

Introduction

around the table

Security Consideration (Hashimoto-san)

Slides

junichi: background
... creating vehicle api
... 2 specs: vehicle information access api + vehicle data
... many stakeholders who have various concerns
... esp. in Europe concern on privacy
... data integrity
... OEM most interested in safety
... so need for security considerations
... p3: Security and Privacy TF
... revising the section 3 of the spec
... during the f2f in Sapporo
... there was discussion
... we need to describe access control
... how OEMs restrict restrict access
... 2 specs on the left side: access API and data
... on the right side, security and privacy consideration
... informative at the moment, and normative recommendation in the future
... p4: Drafting Note
... draft includes both English and Japanese
... can be switched by pushing "t" button
... how to prevent malicious codes from the outside

<wonsuk> Security and Privacy Consideration on Vehicle APIs: http://sou3ilow.github.io/autosec/index.html

junichi: there should be some exception on privacy
... would like to discuss discuss the key points today
... and would like to put into the GitHub by May 11
... p5: Key points
... Scope of Note
... vehicle apis for IVI
... web runtime and its environment
... Protection agains malicious codes
... protecting I/F between IVI and Internet plus the one between IVI and CAN
... basic tech of web security
... system updatability
... Access control
... market, white list, proxy, etc.

paul: will create a wiki?

junichi: would like to have discussion on the GitHub

paul: ok
... we'll put this on the GitHub

kaz: so Hashimoto-san, you want to hold the discussion with the HTML as the starting point?

junichi: yes

kaz: so we'll move the HTML from Junichi's repo to the W3C repo
... and start the actual discussion

junichi: please give your comments

peter: we should present a document based on the HTML?
... separate document?

junichi: a separate document including security/privacy and architecture

wonsuk: how to handle different scenarios for security?

junichi: didn't include use cases in this draft yet
... do you think we should include use cases as well?

peter: would be better to include general description

wonsuk: would be better to include different architecture variations and scenarios
... in case of current use cases
... we could briefly describe them
... some of the vehicle apis cover them
... different possible architectures
... e.g., application talks with the gateway
... we can think about possible variety of connection

paul: we had discussions using Google spreadsheet before

wonsuk: some of the security use cases could be different from general IVI use cases

paul: he started use case discussion for security

<Paul> https://docs.google.com/spreadsheets/d/14ij-2I-H4HbilVQ_muCmUayVqmVfdbkoke690MA0kdo/edit#gid=0

hira: we came up with 50 of use cases for security
... and he categorized them into 5-6 categories
... he can document them

kaz: within the HTML on the GitHub?

junichi: wondering how to put the Google spreadsheet things into the HTML

paul: some possible tools including respec.js

kaz: you can talk about the concrete method later

<Paul> https://www.w3.org/respec/

junichi: another comment?

wonsuk: the scope of this note is focused on webruntime-based apis
... but in the WG, we're discussion JS api and RESTful API
... so wondering about the security for the RESTful discussion part

junichi: would like to support both the cases

kaz: probably you should start with the JS api first
... and extend the scope later

wonsuk: TAG suggested RESTful api would fit the Web ecosystem better
... so wondering how to handle it
... maybe we could start with the RESTful I/F first

-> https://lists.w3.org/Archives/Public/public-automotive/2016Apr/att-0022/20160425-paris-security-privacy.pdf Hashimoto-san's slides

paul: we have to have discussion to figure out how to handle the REST I/F

wonsuk: in case of security consideration
... the current scope is focused on JS api

paul: we have to talk about security consideration
... we've been discussing the vehicle api spec

kaz: we'll have a session about the REST I/F after this, won't we?

paul: also that is the main topic for Thursday
... Kevin showed architecture design
... Philippe Colliot also showed an architecture design

peter: what is the deliverable?
... security consideration for JS API? or REST I/F?
... the style of the API
... the data format could be JSON in the both cases, though

paul: implementers have implemented systems using websocket and some protocols

rudi: transport and services
... what kind of services are exposed?

kaz: we've started architecture discussion already
... we can see what the differences between JS API and REST API are like based on that discussion
... and after that we can tell what need to be added for RESTful API

junichi: p7: Overall Architectures
... combinations of API formats and APY types
... 1. WebIDLxDOM
... 2. RESTxDOM
... 3. RESTxWeb(local)
... 4. RESTxWeb(cloud)
... applications are downloaded from some server
... Web browser requires HTTPS for that connection
... so the local server needs to have HTTPS capability
... and we need to handle certification on the local side

rudi: the 4th one have disadvantage

paul: also privacy issue

rudi: people need to have datamodel

paul: difference between 2 and 3?

wonsuk: the 1st case (1) is our vehicle api
... (2) is websocket i/f
... endpoint description
... data for the websocket connection
... we don't need to add any additional information

junichi: 2 uses dedicated apis

paul: so variation of 1?
... build on the top of browser?

urata: dedicated websocket api is 2

paul: to me 3 seems to be #81 proposal

urata: the difference between 2 and 3 is native vs. pollyfill

wonsuk: in case of 2, websocket api for browser
... and send request to the server

[ discussion on security architecture ]

Architecture diagram on the flipchart

[ break ]

<ted> scribenick: ted

-> http://sou3ilow.github.io/autosec/index.html Junichi's note

junichi: section 3 on web security
... use t to toggle language between japanese and english
... it describes basic techniques
... section 4 goes into privacy protection, ability to invalidate old data, see what is sent and collected
... section 5 is on best practices for access control
... including proxy, oauth and cors

[agreement to provide feedback offline in github or mailing list]

Mitsubishi presentation

Slides

magnus: looking at integrity
... inter-process communication, inter-ECU communication, internet communication are the three main use cases
... leaving authentication out of scope for the moment

(for ECU)

magnus: the web socket solution can support all three of these depending on the architecture used
... the main difference between wss is no http beyond the initial handshake at which point you can keep an open connection in both directions
... CIA security model. confidentiality, integrity and availability
... IPC - you want availability and integrity. you want to protect against spoofed data
... IEC - same concerns if you have access to the car, ability to replay or send faked signal data
... internet UC, the problem is that someone can try to intercept and modify off vehicle network traffic
... encrypting with a private key helps
... big problem is ssl hijacking techniques
... i wanted to bring up certificate pinning
... pinning prevents various mitm techniques
... you should always pin in an untrusted network
... certificates do expire, you need an update mechanism anyway
... I recommend the RFC and OWASP for reading further
... we do not know the scope for the API yet, how much you want to consider in the specification

https://www.w3.org/2016/04/guidelines-article.html

<kaz> ted: generating a guideline article on "Securing Connected Vehicles on the Web"

<kaz> ... SSL certificate maintained by some packaging system

<kaz> ... what each application does

<kaz> ... trying to pull Web security people to the Automotive discussion

<kaz> powell: why don't we simply use a whitelist of secure servers?

powell: there is a strong chance that the server certificate will need to be changed out

magnus: you will need some sort of update option for maintaining that

rudi: you can have certificates updates from ota updates

magnus: (earlier) a WAF might be processor intensive

paul: you wanted to bring something up about protecting the json as well?

peter: we could have payload signing of the json itself

powell: ssl should be enough
... you need confirmation you are talking to the right remote system though
... hawk does the same thing but is meant for things that can't be signed or encrypted any other way

ted: for off vehicle data sources you might still want it
... number of ways to do it including w3c webcrypto api and it provides a 2fa style confirmation - harder to steal both in a mitm

[summary: clear need for guidelines, best to start regular security calls to further that, start with junichi's document, number seem in favor of socket approach for security benefits over webidl approach]

[discussion of decisions to be reached this week, websocket vs webidl approach and mapping data spec to genivi rvi model or adopt it]

<kaz> kaz: want to remind that we should think about the architecture diagram whenever we discuss security and APIs, because sometimes some people think about this area and others think about another area

<kaz> paul: right. so Kevin will send his diagram out on Thursday

<kaz> [discussion on the BG report during the GENIVI AMM tomorrow morning]

<junichi-hashimoto> http://sou3ilow.github.io/autosec

<junichi-hashimoto> repository https://github.com/sou3ilow/autosec

<kaz> Security repo on the W3C GitHub