Can an attacker store potentially incriminating data unencrypted on a node?

Storage Node Operators FAQ
#1

I just found this: https://www.researchgate.net/publication/331474925_Frameup_An_incriminatory_attack_on_Storj_A_peer_to_peer_blockchain_enabled_distributed_storage_system

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.

Is this attack still possible?

1 Like
#2

Interesting that this paper was published in 2019, but appears to be analyzing the old v2 network.

5 Likes
#3

This has been discussed before.

4 Likes
#4

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.

#5

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

#6

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.

#7

So it is totally doable to bypass encryption and make nodes serve illegal unencrypted content directly p2p exposing their ip addresses?

#8

Yes. You have the nodes IP when uploading content to it and you can upload unencrypted content by compiling custom/modified uplink client.

#9

That for me anyway shows how broken that system is. But yeh it would be nice If StorJ can clear up the air.

#10

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.

#11

That is not true. You can have 1/80th (the piece that goes to the node) be the illegal content itself.

1 Like
#12

Could you elaborate how?

#13

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?

2 Likes
#15

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.

#16

We were already promised an official answer to these concerns 30 days ago:

#17

As I understand it, this thread is about technical possibilities, not law-based policies.

#18

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.

#19

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.

1 Like
#20

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.

1 Like
#21

Despite of all this it is important to know:

  1. For SNOs and also customers that data is potentially unencrypted as uplink can be manipulated.
  2. If an SNO gets into legal trouble for whatever reasons that these data cannot be held against him
  3. 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.