In this work we present a primary account of frameup, an incriminatory attack made possible because of existing implementations in distributed peer to peer storage. The frameup attack shows that an adversary has the ability to store unencrypted data on the hard drives of people renting out their hard drive space. This is important to forensic examiners as it opens the door for possibly framing an innocent victim. Our work employs Storj as an example technology, due to its popularity and market size.
Just like a data centre you are not liable for what someone else does, even more so on purpose. If you are made aware by authorityās then StorJ should remove the data. But you the end-user can not access the file(s) and can not be held accountable for what you do not know.
If youāre not talking about encrypted Storj pieces then the law is very grey and it certainly depends on the jurisdiction. Take this case of someone who is now a convicted sex offender as they were sent a WhatsApp video, but never even looked at it - https://www.bbc.co.uk/news/uk-england-london-56102139
Nodes donāt check or enforce encryption on the pieces received/stored, so it is possible to send and store unencrypted illegal content on Storagenodes. Uplink client encrypts data by default but it is possible to change the code and use custom uplink client that doesnāt do encryption.
Even then they will store 1/80 of the file. So what illegal content are you able to extract from it?
If the file is small enough (smaller than a metadata for it), it will be stored on the satellite.
Modify uplink code to upload the piece that is the illegal content. Only check I am aware that storagenode does is size of the piece maybe. Just pad the content to be expected size. There is a max size limit on the piece so I agree you cannot upload content bigger than that, but smaller than that, should not be a problem.
Is there code on storagenode side that you can show that authenticates, validates or otherwise verifies that the piece received is encrypted, or conforms specific format or requirement beside the size?
Indeed. One must assume that the client code is untrusted and will be changed.
One (delayed) defense that comes to mind is to use an erasure coding scheme that makes it computationally unfeasible to generate 80 valid stripes that somehow result in at least one of the stripes being some desired plain text.
If it really is only about technical possibilities (although: who cares if itās not a law problemā¦ because then it wouldnāt be illegal) then this has been answered a lot in different threads.
It is true someone could choose not to encrypt āincriminatingā data, which small pieces of would end up on a number of nodes.
However, there exits the technical ability to remove such data. Someone could put the same data in a bitcoin or ethereum transaction and it would be on far more machines, far more continuous (not in scattered pieces), and far harder to deal with. It seems yet to be a big problem.
With k, n reed solomon erasure encoded data the first k pieces simply represent the original content. With storj that means the first 29 pieces could be whatever the malicious uploader would want them to be and only the remaining 51+ would be generated by erasure encoding. So it is very well possible to simply repeat the same incriminating data for each of the first 29 pieces without encryption and then generate the erasure encoded remaining pieces and be able to survive audits as well as repairs.
Iām theory it would be possible for nodes to detect those pieces as they will have relatively low entropy due to the lack of encryption. But as far as I know no such checks are in place.
I believe that refers mostly to the legal implications, but not the technical feasibility of such an āattackā.
That may be true, but for now it is unclear for SNOs how to proceed should this situation occur or even hoe to know that such a situation has occurred on their nodes.
Unfortunately not just a hypothetical. There are images of child abuse on the bitcoin blockchain apparently. Though I donāt think thatās reason to not address these questions for Storj. I donāt consider it a major concern personally because there is nothing to gain from anyone attempting something like this and quite a bit to lose as they would be incriminating themselves more than anyone else. But I still hope we can get a more in depth response regarding technical and procedural mitigations as well as legal implications, should something like this happen. Because unfortunately become people just want to see the world burn and malicious intent canāt be excluded and the existence should be assumed in networks like this.
For SNOs and also customers that data is potentially unencrypted as uplink can be manipulated.
If an SNO gets into legal trouble for whatever reasons that these data cannot be held against him
For SNO to consider personal defense like disk encryption or something
I must say that until yesterday I was relying on the Storj claim that everything is encrypted that reaches the disks of my nodes. Today I see that differently. From the SNO viewpoint as well as the from the Tardigrade user. Maybe as SNO you should encrypt your nodes disks and maybe as Tardigrade user you should encrypt your data before upload as when using like Filezilla and such you can never be sure if the implementation guarantees the encryption or not.