search

internet-sicherheit / eco-blockchain-governance

Working repo for the eco Blockchain Governance Framework
Apache License 2.0
5 stars 3 forks source link

Right to be forgotten vs. Right to never forget #4

Open cre8 opened 4 years ago

cre8 commented 4 years ago

Good article about the blockchain and GDPR Problem: https://www.finextra.com/blogposting/16102/blockchain-versus-gdpr-and-who-should-adjust-most

Some interesting open questions:

Encrypted data

The article says that throwing keys for encrypted on-chain data away is not 100% compatible with GDRP (it's lost data, but not anonym), but it's the way evidenz is doing it: https://www.evidenz.io/framework.html

Linker exploit

The sovrin approach let us store the data off-chain and only link it. But what happens if someone stores personal data in the linker: E.g. IPFS uses the SHA algorithm to identify a file. There is no way to manipulate the output since it is calculated on the servers independently because each node has the files. For the sovrin network the DID can be generated by you and has to follow this pattern: ^did:sov:[1-9A-HJ-NP-Za-km-z]{21,22}(?<namespace>(?::\w[-\w]*)*)$, so storing kevinwittek in the uuid of a public did is no problem. Same thing goes for storing file hashes on the blockchain as a reference. If the files are stored in a public ipfs every node can check the availability of the file before accepting the transaction (to make sure it's not a compromised hash value). But if the file is self sovereign, nodes can not validate the hash and storing kevinwittek is a possible attack vector.

kiview commented 4 years ago

I should check the Sovrin docs, but I think they try to solve this on a governance level by requiring each transaction endorser to act according to GDPR. This means e.g. blocking/filtering transactions that would violate GDPR. Of course, the 100% technical feasibility of this is debatable.

cre8 commented 4 years ago

Yeah, Kudra says that you have to agree with the terms of service not to store personal data. If you do they can deny the access to the network or reject new transaction. But the damage is already in there. There were two parts how to deal with the right to be forgotten:

  1. delete the data
  2. if you can not delete it, restrict the access to it. For example you have to mark a deletion for backups if you want to use them: restore -> run all delete request -> done

Kudra talked about the Gravestone: some kind of blacklist that is used as a middleware: when the user wan'ts to get access to the data but the id is blacklisted, the request is denied. I see some problem here:

This scenario is only relevant when someone acts as a "bad guy" and since there are no GDPR rules in terms of blockchain we should be really careful with this and mention the potential risk to take a network down (some kind of law exploit^^). This was also some statement of the meeting in Berlin last year "blockchain and GDPR are not in a good relationship yet, so use cases with IOT devices will be faster".

kiview commented 4 years ago

The concept you mean are Tombstones (as defined in the Sovrin glossar, but implemented in Indy):

A mark associated with a Transaction to suggest that the Transaction should no longer be returned in response to requests for read access. In the Sovrin Ledger, a Tombstone may be either a Node-Specific Tombstone or a Ledger-Wide Tombstone. Tombstones do not modify the Sovrin Ledger—only the behavior of a Node that serves data from the Ledger and that wishes to honor the Tombstone’s semantics. In the general context of Self-Sovereign Identity, Tombstones are undesirable, as they represent a vector for censorship. However, they may be used by a specific Steward that is forced to comply with a legal demand to stop returning a specific Transaction, such as a Transaction containing data that is locally considered Personal Data or that is illegal or violates the Transaction Author Agreement in some other way. In such a case, other Stewards may not face the same legal demands and may take different action.

In addition, they distinguish between ledger-wide and node-specific tombstones. So this is basically filtering on output, the data is still physically there.

The latter is potentially not even implemented yet in Indy, but interestingly, this is used to comply to law differences based on node location, so the idea is clever. Further info in JIRA: https://jira.hyperledger.org/browse/INDY-2082

kiview commented 3 years ago

After being more involved with Sovrin I found out, that the whole tombstone concept is not implemented in Indy. These are just concepts, something we need to be aware of.

cre8 commented 3 years ago

So how to deal with this subject:

kiview commented 3 years ago

mention, that tombstone exists as a suggestion, but it's JUST a non verified suggestion

Sounds ideal to me.

cre8 commented 3 years ago

Found some sources for the preferred approach:

kiview commented 3 years ago

Here the quote from the linked master thesis:

Although Sovrin acknowledges that tombstones would be useful in some situations, currently such functionality is not implemented. Consequently, out-of-date data stored on Sovrin’s ledger remain accessible to anyone.

cre8 commented 3 years ago

maybe it's possible to implement the tombstone functionality like a middleware that can be added to the current system (if some of use wants to go the partial way). implementation options: