vincent-grenoble
commented
4 years ago Thank you Janik for your long message and suggestions. I think it’s not sufficient to say we use an ID in an encrypted message that gets decrypted on the other end, by an edge server, and handed to the authority. Even with rotated IDs, it won’t provide privacy guarantees. It’s a matter of protocol design, not encryption.
Regarding the notion of edge servers, if those edge servers are in charge of decrypting sensitive data (what I understand from your 2nd paragraph), I don’t know where’s the security/privacy benefit. It’s not just a matter of trust towards the edge srver. The design should minimize data manipulated by edge server / central server.
Finally, I agree that having a dedicated device could be useful to those who don’t own a smartphone. Would the benefit of having a virtual app for that lies in the fact it could make these dedicated devices even simpler by offloading some of their functionalities? Why not.
Dear folks!
Already some time ago, we drafted the STTEP-Protocol for the privacy-preserving contact data exchange ourselves. With a slightly different use case and less advanced, I've realised some similarities in both our core concepts. Due to a lack of resources, STTEP never left the draft status. Therefore we would be happy to share our own ideas, bring one or another idea over here to ROBERT and give some impulses on the further protocol development.
STTEP was designed to enable a decentralised exchange of personal contact data with a special focus on privacy in mind. The initial idea was to encrypt those data into a transmission medium (initially QR codes, later on evolved to also enable bluetooth, NFC or other technologies) and this encrypted data together with an unique ID similar to your pseudonym would have been sent to the other party, where it could have been stored together with a timestamp. In our draft, those other party would have been any service provider for public life, for example grocery stores, public transportation or restaurants. For the encryption to happen, a public-private-key-set was generated on an edge server together with the issued ID. While the device would have encrypted the sensitive data using the public key, the edge server securely stores the private key together with the ID while never coming into contact with the sensitive data in first instance. Encrypting a nonce into the data set and requesting a new ID e.g. periodically prevents tracking single individuals and app instances throughout different contact points. Once a user gets diagnosed suffering on a Covid-19 infection, his app would have sent all his contact points together with their timestamps to the server, where they would have been decrypted using the private keys. With the decrypted contacts, the infection chain could have been followed and all contacts being at the same place at the same time could have been resolved and other users might get informed about potential infectious contacts. So far to our own concepts, that are as you may see very similar to yours.
For decoupling the servers and load-balancing maybe a lot of requests, we introduced our so called "Edge Servers" that are in fact different servers possibly operated and maintained by different providers. We would have structured these servers in different zones and hierarchies like DNS does. This way, our IDs might have get similar to e-mail addresses or FQDN with subdomains to enforce uniqueness throughout the network and always being able to resolve an ID back to the issuing edge server holding the private key. Also this way having different providers in place operating the edge servers, users might select the operator they have most trust in while simultaneously splitting responsibility across the network.
Another concept I want to set the spot on are our "virtual apps". Not only are we enforcing to use smartphone apps but our only requirement for an app to comply with STTEP was the possibility to interact with the protocol. We introduced this with a special focus on local stores and people not having a smartphone to use. For local stores, their ID would have been generated by a server (that could have been operated based on open source by any trustful provider) while the data exchange could take place using any hardware, e.g. tablets, printed out QR codes, bluetooth beacons or raspberry pis. For people without having a smartphone in possession, a virtual app running on a server could generate a "deferred" ID, meaning that not the actual data but a link to a virtual account on this server could have been encrypted there. This might be the most sensitive part of our protocol as it is the only point where a service provider gets into direct contact with personal data without having an infection case. In our concept, those deferred IDs might have been distributed as business cards containing a QR code and then they might have got activated by scanning the code and entering related contact data. In the resolution of infection chains these deferred IDs are the single point where local health authorities would have been in the need to take manual action by giving those people a phone call. For ROBERT we might leverage those virtual apps with some low cost devices like simple battery powered bluetooth receivers to solve the problem of chain tracking for people without a smartphone. Additionally, using ROBERT in first place as the protocol itself and separating it from the used technology might spread the possibilities for the use of alternatives maybe in surprising ways.
I hope I have inspired you with some new ideas, however I'm quite not sure how new our impulses actually are. I would be happy for your feedback and own thoughts, so we could further evolve the mission to Covid-19 tracking! Best, Janik
P.S.: The rest of our repository is not relevant, as we had not yet enough time to implement a prototype of our protocol.