IRC log of auto on 2021-01-25

Timestamps are in UTC.

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