Meeting minutes
Proxy Re-encryption continued
Isaac: for the car, setup is simple. you just need to install the public key in the car
… this key is use for encrypting the data. the car only needs to keep track of one public key
… the data owner (could be driver, oem, car owner, ?) would have the private key and can enable a third party to consume this data
… 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
… pause and ask questions
Glenn: to understand the diagram, on number 4 fetches encrypted data, does that mean all the data encrypted could be retrieved
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
Gunnar: if you cannot see the encrypted data then the structure needs to be known to separate which signals can be shared
Isaac: yes, of the different PRE schemes it is doable. it is not straight forward and you need to know the data being stored
… you could store different keys on the vehicle and manage it that way, from the source
Ted: @@multiple keys
… how about key provisioning and distribution? how does the key get generated, where and sent to the vehicle + proxy service?
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
Gunnar: that is a general problem
… Alice can revoke the key?
Isaac: revokation is tricky with proxy, you need to inform the proxy to remove it. another model is rolling public keys
Gunnar: you need to entrust the vehicle to change keys
Isaac: correct
Gunnar: since the vehicle is involved in providing the scheme and Alice is vehicle owner
Ted: not necessarily, other possible authority roles
Isaac: we would need some trusted element in the car to keep the key safe
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
… would we encrypt only the actual data or the entire message?
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
… the metadata will make subsequent decisions easier but only *if* we are comfortable with that information being known (by data provider)
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
Isaac: yes, there are also searchable schemes
… some of these schemes get more complicated to implement
… there are a number of searchable encryption paradigms
MagnusG: any idea on handling deprecation of keys? the data is not stored at the proxy but by data provider
Isaac: the proxy will never know anything about the data. all it does is provide re-encryption keys
… the session key can have a time out at which point the key expires
Ashish: does the vehicle encrypt all of the data or does it depend on a policy?
… if Bob is allowed to access the data and all data was sent off, how do we prevent sensitive information from being included?
Isaac: keyword or metadata can be added to the data for generating different re-encryption keys
… you can have keys for owner, oem and mechanic for example. I can then send Bob a key that can access specific data
… the proxy has the last say on what can be reencrypted and enforce policies without seeing the data
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)
Isaac: the mechanic (Bob) can reencrypt as well and send to the consulting mechanic, that could work
Ted: we need to focus on how easy this can be for the end user, layperson
… browser @@CA
Isaac: yes a wallet of sorts will be needed
… there is risk of loosing keys and funds/data associated with
… you can have a passphrase to be able to recover or revoke and regenerate
… the management of keys needs to be separate from the proxy to avoid some collaboration attacks
… proxy needs to handle policies and reencryption key generation
… Alice can store her key elsewhere (phone or in cloud)
Gunnar: unless you are savvy you will need a wallet service which is some risk
Isaac: the wallet could be in the car (although perhaps not best from security perspective)
<Zakim> ted, you wanted to ask about reencrypt of revokation
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
… we have a paper on that
… there are ways
… you can create a special reencryption key at the outset that can reencrypt the data
… to handle recovery scenarios
Gunnar: that would require another service
Isaac: yes
Gunnar: again could exist in the vehicle
Isaac: it could be good for that role indeed
Gunnar: then it would need to process all the reencryption
Isaac: no, not necessarily
Ted asks for reactions from data providers, oems on call - noncommittal
mitigate some of your risk liability and reward in being able to generate revenue but also cost@@
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
… for them in that scenario this would be overkill. [it also puts limitations on them]
… this idea has merit but more advanced architecture than they are now. maybe it can be simplified (with an upgrade path)
Gunnar: I have thoughts but believe Ted wanted to hear from OEM
Joakim: I am not an expert in this area, Peter might be better suited to answer
… he and I can talk
Peter: I am trying to fully understand the flow and controls. I need to finish reading but what Ulf said is correct
… it seems like a wise idea
Joakim: in parallel to protected OEM environments, perhaps this is well suited to send data to third parties from the vehicle
Gunnar: we delve into this some with the GENIVI/W3C CCS project
… this may apply within the ISO neutral server arena. I think we should do more analysis
… some may prefer to send all data to OEM cloud but there are other flows and advantages
https://
Arman: suggest we expand on use cases to explore
Ted: definitely, I will start a section in wiki on PRE