[f2f] minutes - Security Day - 26 April 2016

available at:
  https://www.w3.org/2016/04/26-auto-minutes.html

also as text below.

Thanks a lot for scribing, Ted!

Kazuyuki

---
    [1]W3C

      [1] http://www.w3.org/

                               - DRAFT -

                      Automotive WG - Security Day

26 Apr 2016

   See also: [2]IRC log

      [2] http://www.w3.org/2016/04/26-auto-irc

Attendees

   Present
          Kaz_Ashimura(W3C), Tatsuhiko_Hirabayashi(KDDI),
          Junichi_Hashimoto(KDDI), Paul_Boyes(INRIX),
          Osamu_Nakamura(W3C), Powell_Kinney(Vinli),
          Magnus_Gunnarson(Melco), Peter_Winzell(Melco),
          Yasuyuki_Komatsu(Honda), Shinjira_Urata(Access),
          Hirokazu_Hayashi(Sony), Wonsuk_Lee(ETRI),
          Ted_Guild(W3C), Rudolf_Streif(JLR), Adam_Crofts(JLR;
          remote), Kevin_Gavigan(JLR; remote)

   Regrets
   Chair
          Paul

   Scribe
          kaz, ted

Contents

     * [3]Topics
         1. [4]Introduction
         2. [5]Security Consideration (Hashimoto-san)
         3. [6]Mitsubishi presentation
     * [7]Summary of Action Items
     * [8]Summary of Resolutions
     __________________________________________________________

   <inserted> scribenick: kaz

Introduction

   around the table

Security Consideration (Hashimoto-san)

   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:
   [9]http://sou3ilow.github.io/autosec/index.html

      [9] 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>
   [10]https://docs.google.com/spreadsheets/d/14ij-2I-H4HbilVQ_muC
   mUayVqmVfdbkoke690MA0kdo/edit#gid=0

     [10]
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> [11]https://www.w3.org/respec/

     [11] 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

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

     [12]
https://lists.w3.org/Archives/Public/public-automotive/2016Apr/att-0022/20160425-paris-security-privacy.pdf

   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 ]
   [13]architecture diagram on the flipchart

     [13] https://www.w3.org/auto-f2f/26/DSC_0063.JPG

   Architecture diagram on the flipchart

   [ break ]

   <ted> scribenick: ted

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

     [14] http://sou3ilow.github.io/autosec/index.html

   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 in gotomeeting and will be shared later)

   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

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

     [15] 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> [16]http://sou3ilow.github.io/autosec

     [16] http://sou3ilow.github.io/autosec

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

     [17] https://github.com/sou3ilow/autosec

   <kaz> [18]Security repo on the W3C GitHub

     [18]
https://github.com/w3c/automotive/tree/gh-pages/vehicle_data/security

Summary of Action Items

Summary of Resolutions

   [End of minutes]
     __________________________________________________________


    Minutes formatted by David Booth's [19]scribe.perl version
    1.144 ([20]CVS log)
    $Date: 2016/04/26 15:49:18 $

     [19] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [20] http://dev.w3.org/cvsweb/2002/scribe/



-- 
Kaz Ashimura, W3C Staff Contact for Auto, WoT, TV, MMI and Geo
Tel: +81 3 3516 2504