Okay, got it. I don’t see the point though, as you could just not give the app permission to read the disk.
1 Like
We cannot easily do that. Cross platform secure enclave/sandbox etc. maybe, but not simple
That is nowhere as easy as you imagine AFAIK (it used to be though) Now these keys can be stored in cpu register and so on
Then it’s not really a node at all, it’s malware they have agreed to run.
I may be wrong, but did that not depend on detecting scanners etc. Again more work, not simple, but doable perhaps.
There is also SGX And pals too, but none of it is simple at all.
2 Likes
Then it’s not really a node at all, it’s malware they have agreed to run.
If it functions as a node, then it is a node. What you’re describing, an app that scans the hard disk, is malware that they have agreed to run. I’m not seeing any meaningful difference here.
1 Like
Well if the disk is removed from the machine the files are still readable on another machine and scanning the disk for bad chunks would still succeed. But with temp key (whether stored on a disk or not) the scanning would not be able to get a positive and the operator also can safely and truthfully say they had no knowledge of any bad material being stored.
Only takes one person to do it then its out there.
Depends on the CPU
No its one logical outcome from your suggestion of what a hacker might do.
The point was that if someone is capable of getting the safely stored key on disk then they are capable of modifying the node app as well.
Thus the temp key safely on disk is no different to it not being on disk in this regard.
Nope, scanners do not try and brute force any file. Even if they suspect its bad.
Since the real malware is randomly encrypted (weakly) then there is no signature for the virus/malware scanners to match
2 Likes
If you apply that to any software then, say a bitcoin node then you can see the problem. A node that normally runs as a node can be much more than that.
This app is not a node, it could be a picture viewer or anything. Jsut an app that scans your chunk store.
The difference is this, lets use bitcoin again
- You run a bitcoin node.
- You would not run a bitcoin node from another source, even a government, I presume
The app I am talking about is a scanner that scans you chunk store, not something to replace your node at all.
In that case if we ignore things like DEP and ASLR etc. we just say all computers are fully open to anyone.
Sure does 
I think you are not getting my point. A scanner app can simply read the key and decrypt as it scans. It’s that simple.
I was not suggesting they did, but was the protection not detecting the scanner and then temp encrypting the file with an in RAM key?
If you apply that to any software then, say a bitcoin node then you can see the problem. A node that normally runs as a node can be much more than that.
I still don’t see the problem.
- You would not run a bitcoin node from another source, even a government, I presume
Are you suggesting that people won’t happily run maidsafe nodes from non-official sources? I see that as inevitable.
This app is not a node, it could be a picture viewer or anything.
Then why the concern about it? Why would it matter if a random picture viewer knows my node is hosting a ‘bad’ chunk?
Guys, I need to jump out of this for now. We have an early morning meeting and it’s an important one. So sleep becons. I will check back on the convo tomorrow though to see if we got any further.
5 Likes
If it’s child porn or something.
2 Likes
I still don’t see the issue. How would that end badly for me?
If the police come through your door and find it in your chunk storage directory.
1 Like
Then I’d say I had no way of knowing what it was, and wasn’t doing anything that other safenet nodes weren’t.
And if they police know a certain chunk is bad, they should release a hash of it as part of a list of hashes of bad chunks, so that nodes can know which ones to refuse.
1 Like
Thinking on this for a while now. I appreciate @neo’s solutions, but also @dirvine’s counterarguments. Taking a step back …
The temp key being in RAM is for protecting the node - not data integrity. If the key is discoverable by a bad actor in any instance, then this is a security risk to that node. Putting it in RAM isn’t perfect, but seems the most secure option. So doing so fulfills the objective of securing the node as much as is possible.
However putting the key in RAM does reduce data integrity. So …
-
Perhaps nodes can be given the option of where to store the temp-key during setup? They may feel that being able to recover from power-loss is more important than the risk they take from storing the key in RAM. If the default in setup is to store in RAM, then Maidsafe can claim they’ve done their best to protect nodes and the risk is fully on the node operators.
-
Perhaps increasing network copy number +1 to insure a good balance of node security to data integrity given the lowered data integrity introduced by temp-key.
From the client’s angle, depending on how sufficient the network copy number is or isn’t … it’s also still technically feasible for clients to pay for more copies to be stored on the network. This can be achieved by uploading a normal copy of the file once, then encrypting another copy of the file (prepend the key?) and upload again. As the encrypted file is novel all chunks get new XOR addresses (so more copies). Pay twice, but double the number of copies. Much more time/energy/$$ for the client, but maybe worth it depending on the perceived risk.
Seems reasonable to me that node operator can use a config option to choose between:
-
Key is in RAM, as obscurely/securely as possible for the device. cpu register, tpm, etc. All chunks lost on restart.
-
Key is on disk, weakly encrypted, so it can be brute-forced on startup. Chunks preserved on restart.
With either option, node operator has plausible deniability that s/he does not and cannot know the unencrypted contents of the chunks, – which are also probably encrypted by the client.
edit: I’m not knowledgeable about TPM (trusted platform module) but my 10000 mile high understanding is that it is for storing crypto keys in a secure fashion. So I wonder if (a) that can be leveraged for this purpose, (b) how it would be that the node software could read it, and no other app, and (c) do we as a community trust the TPM in the first place? anyone have answers for these q’s?
4 Likes
That is assuming your device has it in the first place
3 Likes
And you happen to know about that, because you live there. These might happen more often globally. And even if that would not wipe out chunks permanently, these events could affect the reliability of the network.
I don’t know what can be done to alleviate the problem, but 2 simple solutions would be:
- Increase the replication count
- Increase the chunk size
Could those be tailored according to file size? Bigger files would have bigger chunks and/or more replicas?
Than you for making the calculator, it’s a great tool! 
I have feature request though (of course only if you have time etc.), could you make a version, where you set the file size and calculate the survival prognosis based on that?
3 Likes
And wouldn’t it be possible to add one more layer of obfuscation to self-encryption by sending the chunk and key to the node, with the latter being responsible for performing the final obfuscation encryption?
This obfuscation key would be added to the datamap, in this way, the nodes wouldn’t need to store any keys, and it would be the client’s responsibility to perform all the decrypting. This would primarily allow the possibility of a restart with the data.
2 Likes
Gotta keep brainstorming this one so good
issues would be
loss of deduplication
would nodes do the extra work?
4 Likes
Not necessarily, if clients calculate the final hash of the encrypted chunks and send the data to the node closest to this hash.
Is the next client to upload the exact same file going to use the same extra encryption key as the first one.
Or are you meaning that the node does the final encryption step in the “self encryption” phase. If so then unencrypted data is going to be sent to the nodes for every chunk and easy to harest wouldn’t it.
2 Likes