17:56:57 RRSAgent has joined #auto 17:56:57 logging to https://www.w3.org/2021/01/25-auto-irc 17:56:59 RRSAgent, make logs Public 17:57:00 Meeting: Automotive Working Group Teleconference 17:57:16 Meeting: In-Vehicle Best Practices 17:57:27 Agenda+ Proxy Re-encryption continued 17:57:47 agenda+ Privacy considerations in VISS spec and Best Practices 17:57:55 zakim, drop agendum 2 17:57:55 agendum 2, Path to FPWD for VISSv2, dropped 17:58:01 scribenick: ted 17:58:03 Present+ Ted 18:04:44 zakim, next agendum 18:04:44 agendum 3 -- Proxy Re-encryption continued -- taken up [from ted] 18:05:12 Present+ Ulf, Gunnar, Isaac, Peter, Glenn, Ashish, MagnusG 18:05:35 Isaac: for the car, setup is simple. you just need to install the public key in the car 18:05:58 … this key is use for encrypting the data. the car only needs to keep track of one public key 18:06:55 … the data owner (could be driver, oem, car owner, ?) would have the private key and can enable a third party to consume this data 18:07:27 … the proxy will reencrypt the data based on third party key and data owners. the car doesn't need to know about use of this arrangement, this is a good part 18:07:39 … pause and ask questions 18:08:23 Glenn: to understand the diagram, on number 4 fetches encrypted data, does that mean all the data encrypted could be retrieved 18:09:22 Isaac: proxy has ability to re-encrypt data without seeing it but can also enforce a policy of what can be shared without seeing it 18:11:06 Gunnar: if you cannot see the encrypted data then the structure needs to be known to separate which signals can be shared 18:11:39 Isaac: yes, of the different PRE schemes it is doable. it is not straight forward and you need to know the data being stored 18:12:18 … you could store different keys on the vehicle and manage it that way, from the source 18:16:28 Ted: @@multiple keys 18:17:02 … how about key provisioning and distribution? how does the key get generated, where and sent to the vehicle + proxy service? 18:17:38 Isaac: it can be done a number of ways. some signals will be encrypted twice, once with a master key and again with user key 18:18:15 Gunnar: that is a general problem 18:18:42 … Alice can revoke the key? 18:19:14 Isaac: revokation is tricky with proxy, you need to inform the proxy to remove it. another model is rolling public keys 18:19:32 Gunnar: you need to entrust the vehicle to change keys 18:19:40 Isaac: correct 18:20:19 Gunnar: since the vehicle is involved in providing the scheme and Alice is vehicle owner 18:20:34 Ted: not necessarily, other possible authority roles 18:21:40 Isaac: we would need some trusted element in the car to keep the key safe 18:22:28 Ulf: I have a question. in VISS the data is packaged into a structure that contains the path and the data point which is one or more values 18:22:48 … would we encrypt only the actual data or the entire message? 18:23:37 Isaac: good point, I don't have a definitive answer. both approaches could be beneficial. if we want finer grained control, encrypting only the actual data it would be helpful but then the data structure/metadata exposed to the data provider 18:25:27 … the metadata will make subsequent decisions easier but only *if* we are comfortable with that information being known (by data provider) 18:26:10 Ted: or maybe a scheme with another key for structure and provide data provider key to decrypt the data to be able to be granular in what gets PRE 18:26:26 Isaac: yes, there are also searchable schemes 18:27:38 … some of these schemes get more complicated to implement 18:27:57 … there are a number of searchable encryption paradigms 18:28:22 Present+ Arman 18:28:44 MagnusG: any idea on handling deprecation of keys? the data is not stored at the proxy but by data provider 18:29:32 Isaac: the proxy will never know anything about the data. all it does is provide re-encryption keys 18:29:58 … the session key can have a time out at which point the key expires 18:31:34 Ashish: does the vehicle encrypt all of the data or does it depend on a policy? 18:32:11 … if Bob is allowed to access the data and all data was sent off, how do we prevent sensitive information from being included? 18:32:31 Isaac: keyword or metadata can be added to the data for generating different re-encryption keys 18:33:11 … you can have keys for owner, oem and mechanic for example. I can then send Bob a key that can access specific data 18:33:33 … the proxy has the last say on what can be reencrypted and enforce policies without seeing the data 18:36:42 Ted trying to balance policy and PRE, how to have third party (eg mechanic) to send to a fourth party (another mechanic being subcontracted or consulted) 18:37:07 Isaac: the mechanic (Bob) can reencrypt as well and send to the consulting mechanic, that could work 18:39:11 Ted: we need to focus on how easy this can be for the end user, layperson 18:39:22 … browser @@CA 18:39:41 Isaac: yes a wallet of sorts will be needed 18:39:54 … there is risk of loosing keys and funds/data associated with 18:40:15 … you can have a passphrase to be able to recover or revoke and regenerate 18:40:44 … the management of keys needs to be separate from the proxy to avoid some collaboration attacks 18:41:01 … proxy needs to handle policies and reencryption key generation 18:41:16 … Alice can store her key elsewhere (phone or in cloud) 18:42:06 Gunnar: unless you are savvy you will need a wallet service which is some risk 18:42:30 q+ to ask about reencrypt of revokation 18:42:55 Isaac: the wallet could be in the car (although perhaps not best from security perspective) 18:45:22 ted, you wanted to ask about reencrypt of revokation 18:46:02 Isaac: you can have a trusted set of CAs and in case you loose the key, you can create a key to reencrypt but you really have to trust that CA 18:46:16 … we have a paper on that 18:46:45 … there are ways 18:47:02 Present+ Joakim 18:47:47 … you can create a special reencryption key at the outset that can reencrypt the data 18:47:55 … to handle recovery scenarios 18:49:00 Gunnar: that would require another service 18:49:03 Isaac: yes 18:49:12 Gunnar: again could exist in the vehicle 18:49:40 Isaac: it could be good for that role indeed 18:49:54 Gunnar: then it would need to process all the reencryption 18:50:02 Isaac: no, not necessarily 18:54:01 Ted asks for reactions from data providers, oems on call - noncommittal 18:54:32 mitigate some of your risk liability and reward in being able to generate revenue but also cost@@ 18:55:12 Ulf: this isn't the current reality. more common is an OEM sandboxed cloud and OEM believe they can transmit data securely to this cloud 18:55:36 … for them in that scenario this would be overkill. [it also puts limitations on them] 18:56:20 … this idea has merit but more advanced architecture than they are now. maybe it can be simplified (with an upgrade path) 18:57:25 Gunnar: I have thoughts but believe Ted wanted to hear from OEM 18:57:40 Joakim: I am not an expert in this area, Peter might be better suited to answer 18:57:45 … he and I can talk 18:58:15 Peter: I am trying to fully understand the flow and controls. I need to finish reading but what Ulf said is correct 18:58:21 … it seems like a wise idea 19:00:35 Joakim: in parallel to protected OEM environments, perhaps this is well suited to send data to third parties from the vehicle 19:01:15 Gunnar: we delve into this some with the GENIVI/W3C CCS project 19:01:54 … this may apply within the ISO neutral server arena. I think we should do more analysis 19:02:11 … some may prefer to send all data to OEM cloud but there are other flows and advantages 19:02:46 https://www.w3.org/community/autowebplatform/wiki/Best_Practices 19:04:17 Arman: suggest we expand on use cases to explore 19:15:20 Ted: definitely, I will start a section in wiki on PRE 19:15:21 I have made the request to generate https://www.w3.org/2021/01/25-auto-minutes.html ted 19:15:23 leaving. As of this point the attendees have been Peter, Ted, Ulf, Gunnar, MagnusF, Arman, Daniel, Isaac, Glenn, Ashish, MagnusG, Joakim 19:15:23 Zakim has left #auto 19:15:24 I see no action items