Permissions about ipfs HOT 19 CLOSED

Encryption to manage permission is a very bad idea. It works well in optimistic scenarios but does not hold itself very well in reality.

For instance, assuming that an encrypted file gets distributed across multiple nodes and reach someone with malicious intentions, then they could put some effort into decrypting the file. In an optimistic world, they fail, and everyone is happy. Yeah!

In the real world, if the file has been created a while back, it is possible that a flaw in the encryption algorithm has been found since then. Or, it is possible that new special decryption hardware becomes widely available. This would drastically reduce the complexity of the decryption process. Because nobody truly owns the file, there is no way to pull the existing file and replace it with a new version that is encrypted with a new and safer algorithm. Even if you could do something like this, what tells you the malicious node will not keep the previous version of the file anyway.

In the end, nothing beats preventing the file from leaving the network when it comes to security and privacy.

Instead of file permissions, I think it would be more meaningful to do it on a node level. Basically, a node should be able to refuse connections from other nodes based on a whitelist/blacklist paradigm. This would let people create a private IPFS network, a little bit like private bit torrent trackers, to share sensitive data while avoiding leaking to a malicious node.

Maybe we could even consider a globally distributed blacklist of nodes, stored on IPFS itself, to automatically block known malicious nodes. Though, I don't know how useful this would be considering a node identity can be simply re-generated through a new key pair.

from ipfs.

You'd be better off using capabilities instead. Naive example: encrypt the file with some secret, and share the secret with the people who have "read permission".

from ipfs.

The Private Networks feature was build on a concept of complete trust of your PNet peers.

Next step could be capability system where you can allow some nodes access to some files. Malicious actor in that schema would be able to leak only data he has capability for, given that other nodes that have capability for given file are well behaved.

@nueverest as @jcgruenhage said, once user has access to a file and can decrypt it he can copy it to USB stick and just publish it somewhere else.

from ipfs.

On further investigation, I think the only thing that is missing is ownership of a blob (possibly none) and read permissions based on a list (or several) controlled by the owner (if not none). This can be built on top of IPFS without modifying the underlying fs.

from ipfs.

@ekg The difference is that if there is a flaw in how a node is secured, or in the whitelist system itself, then it can be updated because "you are in control" of all the affected nodes in your network. If you choose to trust a node, then it's up to you to ensure that it is safe. If a flaw appears, it doesn't mean that you leaked data, just that you should fix it ASAP. You cannot do this when it comes to encryption in a distributed file system. If a file uses broken encryption, you do not have that second chance.

from ipfs.

Having a node that controls which nodes are allowed to retrieve a certain file should be a thing. Encrypting the files is no good in some scenarios. Some example:
Have some media service, where people have to pay to access the content. To save on bandwidth, using IPFS would make sense, if they could ensure that only those who paid could access the files, at least through their nodes and the nodes of the honest users. If the files were protected by encryption only, it would just require a single user that extracts the key per medium, and pirates could steal the content through IPFS. Without asynchronous encryption, you couldn't even know which users distributed the key, and with asynchronous encryption, you don't get the advantages of IPFS. Please reconsider this.

A way to implement that, would be that the node that is asked for the file would ask some authority, whether the node trying to access the file was allowed to do so, and act based on that. It shouldn't be too hard to do that either, and there definitely would be users.

from ipfs.

The private network feature looks interesting, but it would force people to have a completely separate node for accessing this content, and I doubt that is what most people would want. Also, there we have again a single key that would need to be compromised, instead of an central authority that has control over who get's the file.

About whether a node should share the file if they got it from somewhere else, how should they even know, that the file has restricted access then? I guess sharing it then is fine, because the thing I am trying to ensure is only that if someone "steals" the file, that the server nodes that have pinned the files, and the nodes of the honest users don't make their downloads super fast, because they can download it from all those nodes too, but only from those not so honest users.

from ipfs.

Exactly. Caps. See e-rights and Tahoe-LAFS

—
Sent from Mailbox

On Fri, Sep 4, 2015 at 4:46 PM, Mourad De Clerck [email protected]
wrote:

You'd be better off using capabilities instead. Naive example: encrypt the file with some secret, and share the secret with the people who have "read permission".

Reply to this email directly or view it on GitHub:
#86 (comment)

from ipfs.

I also agree that encryption is the most straightforward way to do this.
Encryption schemes can be hacked, but so can the nodes. Users simply need
to be aware of these potentialities when trying to provide access control
to blobs.
On Sep 9, 2015 6:48 PM, "Etienne Maheu" [email protected] wrote:

Encryption to manage permission is a very bad idea. It works well in
optimistic scenarios but does not hold itself very well in reality.

For instance, assuming that an encrypted file gets distributed across
multiple nodes and reach someone with malicious intentions, then they could
put some effort into decrypting the file. In an optimistic world, they
fail, and everyone is happy. Yeah!

In the real world, if the file has been created a while back, it is
possible that a flaw in the encryption algorithm has been found since then.
Or, it is possible that new special decryption hardware becomes widely
available. This would drastically reduce the complexity of the decryption
process. Because nobody truly owns the file, there is no way to pull the
existing file and replace it with a new version that is encrypted with a
new and safer algorithm. Even if you could do something like this, what
tells you the malicious node will not keep the previous version of the file
anyway.

In the end, nothing beats preventing the file from leaving the network
when it comes to security and privacy.

Instead of file permissions, I think it would be more meaningful to do it
on a node level. Basically, a node should be able to refuse connections
from other nodes based on a whitelist/blacklist paradigm. This would let
people create a private IPFS network, a little bit like private bit torrent
trackers, to share sensitive data while avoiding leaking to a malicious
node.

Maybe we could even consider a globally distributed blacklist of nodes,
stored on IPFS itself, to automatically block known malicious nodes.
Though, I don't know how useful this would be considering a node identity
can be simply re-generated through a new key pair.

—
Reply to this email directly or view it on GitHub
#86 (comment).

from ipfs.

@kawazoe please read into capability models. every single permission scheme can be represented in a capability system, so it is a strictly superior system. papers abound.

a node should be able to refuse connections from other nodes based on a whitelist/blacklist paradigm. This would let people create a private IPFS network, a little bit like private bit torrent trackers, to share sensitive data while avoiding leaking to a malicious node.

this is already planned, but orthogonal.

from ipfs.

@jbenet I am not saying that capabilities are bad. It is great that you plan on using this model. What I'm saying is that there is a distinctive difference between an Access capability and a Read capability (no matter at which level or how it is implemented) and that encrypting the data alone is not a sufficient to distinguish the two.

from ipfs.

@jcgruenhage You could have every user of the network be on the same private network. (see ipfs/kubo#3397 (comment) for more info on private networks)

Aside from that, you could possibly implement this as a special bitswap extension, but then you run into a couple weird issues, trying to have unencrypted 'private' content while still connected to the primary network. What if someone outside the 'allowed group' gets the file through some other means (and it has the same hash) and then a node in the allowed group grabs it (maybe its part of some other archive they downloaded). Should they then serve the files to other peers who requested it since it came from a non-protected source?

from ipfs.

@jcgruenhage I agree about the inconvenience of requiring a private network.

Also, it is not clear how much the private network helps because upon decrypting data a dishonest user could immediately upload this data to the public network. Please correct me if something prevents this.

If the private network had a maximum of two nodes then the honest node would know that the other node is dishonestly leaking data. Allow more than two nodes in the private network, and leak determinism is lost.

Even in the two node private network, the honest node would not immediately know that the data is leaking. Time would elapse, and by that point the data may be half way across the galaxy.

A possible solution is to add an encrypted node id / tracer id during file decryption. Thereby each user gets a slightly modified copy of each file containing a tracer/node id unique to them. The decrypted files would always be different from the original, but the original would remain immutable and verifiable.

Sentinel nodes related to the private network could monitor the public network for these tracer values. In this way, it would be possible to detect leak origin in a timely manner.

This would not prevent a node on one private network from leaking data to another private network.

from ipfs.

You can't prevent users from sharing the files, but you should be able to prevent them using your infrastructure for that, but currently there is no distributed file distribution system that does this yet.

from ipfs.

from ipfs.

For me more important is the ownership --- I want to make sure that the file was modified by someone I trust. One way to do this is to encrypt the file and used the decryption key as a part of the file name --- so once hash-sum is calculated for the decrypted file I will know that only one who knows the encryption key could do it.

Likely it is not the best way, but is it implemented somewhere?

from ipfs.

Files named by /ipfs paths (e.g., /ipfs/QmSVyMxF5W5NFTJxKWhhdVjqnhhFmsqjFgSrbPovp5bzwF) are immutable so this shouldn't be an issue. Files named by an /ipns/... path are mutable but are signed by the author (the owner of the IPNS name).

However, if you're obtaining /ipfs/... paths out of band and want to determine authorship, you'll likely need to sign the data (can be done with, e.g., gnupg).

Note: We'll likely eventually build a mutable filesystem like SUNDR. That filesystem will likely carry authorship information. We'll likely also allow arbitrary metadata in the future (that could, in theory, carry authorship information).

from ipfs.

@risen @jbenet Can you describe (or link to description) how capability models could be used to prevent permissioned files on an IPFS node from leaving that node except to an authorized requester? Is there an explicit capability model feature in IPFS? I've searched around for documentation on this but haven't found anything explicit.

from ipfs.

Hi @vdods -- we're leaving issues in this repo open for reference purposes, but requesting that followup discussion happen in https://discuss.ipfs.io/ (which is actively monitored). Please post there -- thank you!

from ipfs.