11:07:24 RRSAgent has joined #auto 11:07:24 logging to http://www.w3.org/2016/04/26-auto-irc 11:07:52 Meeting: Automotive WG - Security Day 11:07:58 topic: Introduction 11:08:02 wonsuk has joined #auto 11:08:04 around the table 11:12:50 hira has joined #auto 11:16:00 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), Adam_Crofts(JLR), Kevin_Gavigan(JLR) 11:17:07 AdamC has joined #auto 11:17:52 Present+ Rudolf_Streif(JLR) 11:18:46 present+ Kevin_Gavigan(JLR;remote), Adam_Crofts(JLR;remote) 11:19:31 PowellKinney has joined #auto 11:19:40 topic: Security Consideration (Hashimoto-san) 11:20:06 junichi: background 11:20:11 ... creating vehicle api 11:20:33 ... 2 specs: vehicle information access api + vehicle data 11:20:34 Paul has joined #auto 11:20:59 ... many stakeholders who have various concerns 11:21:15 ... esp. in Europe concern on privacy 11:21:21 ... data integrity 11:21:33 ... OEM most interested in safety 11:21:49 ... so need for security considerations 11:22:02 ... by Security TF 11:22:15 s/Security/Security and Privacy/ 11:22:24 ... revising the section 3 of the spec 11:22:43 ... during the f2f in Sapporo 11:22:47 ... there was discussion 11:23:07 ... we need to describe access control 11:23:18 ... how OEMs restrict restrict access 11:23:36 ... 2 specs on the left side: access API and data 11:23:54 ... on the right side, security and privacy consideration 11:24:16 ... informative at the moment, and normative recommendation in the future 11:24:24 ... p4: Drafting Note 11:24:37 s/by/p3: 11:25:06 ... draft includes both English and Japanese 11:25:16 ... can be switched by pushing "t" button 11:25:37 ... how to prevent malicious codes from the outside 11:25:44 Security and Privacy Consideration on Vehicle APIs: http://sou3ilow.github.io/autosec/index.html 11:26:15 junichi: there should be some exception on privacy 11:26:28 ... would like to discuss discuss the key points today 11:26:45 ... and would like to put into the GitHub by May 11 11:26:52 ... p5: Key points 11:26:57 ... Scope of Note 11:27:08 ... vehicle apis for IVI 11:27:53 ... web runtime and its environment 11:28:15 ... Protection agains malicious codes 11:29:03 ... protecting I/F between IVI and Internet plus the one between IVI and CAN 11:29:09 ... basic tech of web security 11:29:16 ... system updatability 11:29:24 ... Access control 11:29:38 ... market, white list, proxy, etc. 11:29:48 paul: will create a wiki? 11:30:06 junichi: would like to have discussion on the GitHub 11:30:11 paul: ok 11:30:19 ... we'll put this on the GitHub 11:31:23 kaz: so Hashimoto-san, you want to hold the discussion with the HTML as the starting point? 11:31:26 junichi: yes 11:32:17 urata_access has joined #auto 11:32:30 kaz: so we'll move the HTML from Junichi's repo to the W3C repo 11:32:35 ... and start the actual discussion 11:32:43 junichi: please give your comments 11:32:59 peter: we should present a document based on the HTML? 11:33:19 ... separate document? 11:33:32 junichi: a separate document including security/privacy and architecture 11:33:51 wonsuk: how to handle different scenarios for security? 11:34:10 junichi: didn't include use cases in this draft yet 11:34:21 ... do you think we should include use cases as well? 11:34:39 peter: would be better to include general description 11:35:10 wonsuk: would be better to include different architecture variations and scenarios 11:35:23 ... in case of current use cases 11:35:31 ... we could briefly describe them 11:35:47 ... some of the vehicle apis cover them 11:36:06 ... different possible architectures 11:36:15 ... e.g., application talks with the gateway 11:36:35 ... we can think about possible variety of connection 11:36:54 paul: we had discussions using Google spreadsheet before 11:37:22 wonsuk: some of the security use cases could be different from general IVI use cases 11:37:41 paul: he started use case discussion for security 11:37:53 https://docs.google.com/spreadsheets/d/14ij-2I-H4HbilVQ_muCmUayVqmVfdbkoke690MA0kdo/edit#gid=0 11:38:08 hira: we came up with 50 of use cases for security 11:38:21 ... and he categorized them into 5-6 categories 11:38:33 ... he can document them 11:38:42 kaz: within the HTML on the GitHub? 11:39:07 osamu has joined #auto 11:39:26 junichi: wondering how to put the Google spreadsheet things into the HTML 11:40:09 paul: some possible tools including respec.js 11:41:14 kaz: you can talk about the concrete later 11:41:20 https://www.w3.org/respec/ 11:41:25 s/later/method later/ 11:41:34 junichi: another comment? 11:41:49 wonsuk: the scope of this note is focused on webruntime-based apis 11:42:09 ... but in the WG, we're discussion JS api and RESTful API 11:42:25 ... so wondering about the security for the RESTful discussion part 11:42:35 junichi: would like to support both the cases 11:43:00 kaz: probably you should start with the JS api first 11:43:07 ... and extend the scope later 11:43:37 wonsuk: TAG suggested RESTful api would fit the Web ecosystem better 11:44:06 ... so wondering how to handle it 11:44:18 ... maybe we could start with the RESTful I/F first 11:44:57 -> https://lists.w3.org/Archives/Public/public-automotive/2016Apr/att-0022/20160425-paris-security-privacy.pdf Hashimoto-san's slides 11:45:44 paul: we have to have discussion to figure out how to handle the REST I/F 11:46:07 wonsuk: in case of security consideration 11:46:43 ... the current scope is focused on JS api 11:47:24 paul: we have to talk about security consideration 11:47:40 ... we've been discussing the vehicle api spec 11:48:15 kaz: we'll have a session about the REST I/F after this, won't we? 11:48:25 paul: also that is the main topic for Thursday 11:48:55 ... Kevin, you showed architecture design 11:49:12 ... Philippe Colliot also showed an architecture design 11:49:19 s/Kevin, you/Kevin/ 11:49:25 peter: what is the deliverable? 11:49:52 ... security consideration for JS API? or REST I/F? 11:50:27 ... the style of the API 11:50:37 ... the data format could be JSON in the both cases 11:50:42 s/cases/cases, though/ 11:51:13 paul: implementers have implemented systems using websocket and some protocols 11:52:31 rudi: transport and services 11:52:40 ... what kind of services are exposed? 11:53:35 kaz: we've started architecture discussion already 11:54:00 ... we can see what the differences between JS API and REST API are like based on that discussion 11:54:21 ... and after that we can tell what need to be added for RESTful API 11:54:41 junichi: p7: Overall Architectures 11:55:49 ... combinations of API formats and APY types 11:56:06 ... 1. WebIDLxDOM 11:56:09 ... 2. RESTxDOM 11:56:20 ... 3. RESTxWeb(local) 11:56:28 ... 4. RESTxWeb(cloud) 11:56:49 ... applications are downloaded from some server 11:57:13 ... Web browser requires HTTPS for that connection 11:57:34 ... so the local server needs to have HTTPS capability 11:57:49 ... and we need to handle certification on the local side 11:58:08 rudi: the 4th one have disadvantage 11:58:31 paul: also privacy issue 11:59:15 rudi: people need to have datamodel 11:59:58 paul: difference between 2 and 3? 12:00:16 wonsuk: the 1st case (1) is our vehicle api 12:00:26 ... (2) is websocket i/f 12:00:32 ... endpoint description 12:00:40 ... data for the websocket connection 12:01:06 ... we don't need to add any additional information 12:01:39 junichi: 2 uses dedicated apis 12:01:48 paul: so variation of 1? 12:02:10 ... build on the top of browser? 12:02:22 urata: dedicated websocket api is 2 12:03:07 paul: to me 3 is #81 proposal 12:03:10 s/is/seems to be/ 12:03:40 urata: the difference between 2 and 3 is native vs. pollyfill 12:04:29 wonsuk: in case of 2, websocket api for browser 12:04:36 ... and send request to the server 12:24:43 hira has joined #auto 12:51:36 scribenick: ted 12:52:17 sam has joined #auto 12:53:24 -> http://sou3ilow.github.io/autosec/index.html Junichi's note 12:56:44 junichi: section 3 on web security 12:56:53 … use t to toggle language between japanese and english 12:57:10 … it describes basic techniques 12:59:04 osamu has joined #auto 12:59:45 … section 4 goes into privacy protection, ability to invalidate old data, see what is sent and collected 13:00:04 … section 5 is on best practices for access control 13:01:09 … including proxy, oauth and cors 13:01:41 [agreement to provide feedback offline in github or mailing list] 13:01:52 Topic: Mitsubishi presentation 13:02:50 junichi-hashimoto has joined #auto 13:04:45 kaz has joined #auto 13:04:57 (slides in gotomeeting and will be shared later) 13:05:23 magnus: looking at integrity 13:05:42 rrsagent, make log public 13:05:47 rrsagent, draft minutes 13:05:47 I have made the request to generate http://www.w3.org/2016/04/26-auto-minutes.html kaz 13:05:48 … inter-process communication, inter-ECU communication, internet communication are the three main use cases 13:06:09 … leaving authentication out of scope for the moment 13:06:15 (for ECU) 13:06:44 magnus: the web socket solution can support all three of these depending on the architecture used 13:07:34 … the main difference between wss is no http beyond the initial handshake at which point you can keep an open connection in both directions 13:07:56 … CIA security model. confidentiality, integrity and availability 13:08:44 … IPC - you want availability and integrity. you want to protect against spoofed data 13:09:07 … IEC - same concerns if you have access to the car, ability to replay or send faked signal data 13:10:00 … internet UC, the problem is that someone can try to intercept and modify off vehicle network traffic 13:10:23 … encrypting with a private key helps 13:11:05 … big problem is ssl hijacking techniques 13:11:25 … i wanted to bring up certificate pinning 13:11:59 … pinning prevents various mitm techniques 13:12:47 … you should always pin in an untrusted network 13:13:26 i/Introduction/scribenick: kaz/ 13:13:28 rrsagent, draft minutes 13:13:28 I have made the request to generate http://www.w3.org/2016/04/26-auto-minutes.html kaz 13:13:41 … certificates do expire, you need an update mechanism anyway 13:14:00 … I recommend the RFC and OWASP for reading further 13:14:20 … we do not know the scope for the API yet, how much you want to consider in the specification 13:14:41 i|Junichi's note|diagram on the flipchart| 13:14:44 rrsagent, draft minutes 13:14:44 I have made the request to generate http://www.w3.org/2016/04/26-auto-minutes.html kaz 13:14:58 https://www.w3.org/2016/04/guidelines-article.html 13:16:44 ted: generating a guideline article on "Securing Connected Vehicles on the Web" 13:17:53 ... SSL certificate maintained by some packaging system 13:18:24 ... what each application does 13:19:03 ... trying to pull Web security people to the Automotive discussion 13:20:00 powell: why don't we use a whitelist of secure servers? 13:20:09 s/use/simply use/ 13:21:02 powell: there is a strong chance that the server certificate will need to be changed out 13:21:21 magnus: you will need some sort of update option for maintaining that 13:21:41 rudi: you can have certificates updates from ota updates 13:24:47 magnus: (earlier) a WAF might be processor intensive 13:25:08 rrsagent, draft minutes 13:25:08 I have made the request to generate http://www.w3.org/2016/04/26-auto-minutes.html kaz 13:25:17 paul: you wanted to bring something up about protecting the json as well? 13:25:23 peter: we could have payload signing of the json itself 13:25:54 powell: ssl should be enough 13:26:20 … you need confirmation you are talking to the right remote system though 13:26:37 … hawk does the same thing but is meant for things that can't be signed or encrypted any other way 13:27:34 ted: for off vehicle data sources you might still want it 13:28:45 … number of ways to do it including w3c webcrypto api and it provides a 2fa style confirmation - harder to steal both in a mitm 13:29:33 Zakim has left #auto 13:34:10 [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] 13:42:47 [discussion of decisions to be reached this week, websocket vs webidl approach and mapping data spec to genivi rvi model or adopt it] 13:47:50 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 13:48:06 paul: right. so Kevin will send his diagram out on Thursday 13:54:16 [discussion on the BG report tomorrow morning] 13:54:30 s/report/report during the GENIVI AMM/ 13:54:36 rrsagent, draft minutes 13:54:36 I have made the request to generate http://www.w3.org/2016/04/26-auto-minutes.html kaz 14:10:08 http://sou3ilow.github.io/autosec 14:10:48 repository https://github.com/sou3ilow/autosec 14:21:11 ahaller2 has joined #auto 14:22:24 rrsagent, draft minutes 14:22:24 I have made the request to generate http://www.w3.org/2016/04/26-auto-minutes.html kaz 14:22:29 Chair: Paul 14:22:30 rrsagent, draft minutes 14:22:30 I have made the request to generate http://www.w3.org/2016/04/26-auto-minutes.html kaz 14:27:51 -> https://github.com/w3c/automotive/tree/gh-pages/vehicle_data/security Security repo on the W3C GitHub 14:27:53 rrsagent, draft minutes 14:27:53 I have made the request to generate http://www.w3.org/2016/04/26-auto-minutes.html kaz 15:24:37 kaz has joined #auto