Meeting minutes
Ted: aggregate, queries...
… @@
Glenn: I had similar thought, NHTSA is looking at accident recreation and safety features
… a particular OEM is working with them in providing that aggregate data
… it could be on a use case by use case basis where the data and insights are provided
… there is clear overlap in this NSF proposal as well as intersection with SmartCities and multi-modal transportation
… it could include other modes of transportation and external data sets
Ted: parallels with industry issues@@
Glenn: the types of aggregate data sets...
Isaac: agree it makes sense to explore
@@
Proxy reencryption
Isaac shares screen with diagram of key holder and other parties
[scribe was having technical/laptop problems]
Isaac: everything signed on the car would be encrypted with public key provded by owner
Rudi: this problem common in content protection such as DRM for restricting content
… handling different viewer's subscriptions
… I would suggest looking at best practices being used there. PKI is slow versus symetric key
… the symetric key is rotated. entitlement messages might be encrypted with PKI
… separate from the symetric content key
Isaac: that is a different approach with more complex key management. proxy reencryption also requires key managmenent but fewer just initial key pair per entity
[slide 2]
Isaac: NuCypher is trying to avoid single entity in the cloud, you can instead have multiple nodes which makes you more resilient to attacks as well
… owner will create a specific key pair, provide the car with public key. the car can use this key to sign additional keys and use them to encrypt the data
… in parallel the individual or third party on their behalf and can provide a reencryption key. next the user can share with the network the reencryption key along with policy
… the nodes enforcing the policy don't know anything about the data, unable to read
[slide 3 diagram]
… data consumer can request reencryption key and separately request data from the shared storage
Rudi: doesn't this require sharing private keys as well?
Isaac: no. proxy allows you to reencrypt data without knowing anything about it
Adnan: qualified applications each require a policy?
Isaac: one key is used to encrypt all the data, separately you sign reencryption keys and send to separate, trusted entity than the data storer
Rudi: in order to reencrypt don't you need the data in the clear?
Isaac: no, not with these types of resigned keys
… this scheme was initially used for encrypting email
… it allowed someone to take over, temporarily, use of a mail account while on vacation
Ted attempts to give a physical lock analogy
Isaac: better would be changing envelopes for mail
… everything in car encrypted with initial public key. for lock analogy, you can change lock without opening the door
… it is one mathematical operation
Rudi: to do so, you need some information about the initial private key that the public one is derived from
… that private key needs to be available somewhere
… leave the owner (Alice) possession
Isaac: Bob and Alice each provide their public key
Rudi: then the generated private key to reencrypt at risk of being cracked
Arman: shared key/secret
Ashish: so reencryption key created at start?
Isaac: no, at any time for additional data consumer
[Alice's private key and Bob's public key used to generate reencryption]
Arman: Alice gives Bob permission to decrypt. any information decrypted can be done based on his public key?
Isaac: no, needs the reencryption key
… there are other schemes that provide more protection
Arman: how do you restrict what data on the shared sever that Bob can access?
[continue this in two weeks and Isaac will send materials]