Decouple Addressing And Encryption In Future Releases

[dfens]

I read about the btsync protocoll stack and it seems to me it has a significant design flaw that comes crashing down if you realize certain use cases.

 

The btsync protocoll is designed to be secure in the scenario "trusted devices vs. everyone else". Realistically to have reasonable reliability you have to have either

 

a.) have one private "always on" device with btsync that you control alone

b.) have a server somewhere with btsync as "always on" device

 

Option a.) is perfectly fine, option b.) with the current design isn't. Realistically a server in some hosting environment is no "trusted device" in that the server (which you don't own and don't ultimately control) has the same pitfalls as a regular cloud storage service:

 

The provider can and may look into your files or may even be obliged to do so by law in certain cases. Technically this is very easy, since most offers today are based on virtualization technology.

 

So the claim that btsync offers security advantages compared to "cloud providers" may be true in practical ways but not in a strict technical way. You can mitigate some risk scenarios by setting the device as "read only", but that doesn't help the issue that the provider may look into your files (since btsync needs "a" secret to operate).

 

I therefore propose a protocoll change: decouple addressing and encryption key. That would allow the b.) scenario to work with just the addressing key in a "zero knowledge" operation mode. It would allow the operation of an "always on" reliability node/device in some cheap hosting environments without the security pitfalls currently associated with it.

 

Regards,

 

dfens

 

 

Nevermind, i just realized (from the meagre documentation) that btsync apparenly doesn't encrypt the files at all but just the transport of the files between devices.

 

Still the protocoll should implement a modus that allows a non-trusted device to participate in a secure manner.

[piotrnik]

There are encrypted secrets that can be used with a hosting provider or such - the BTSync installation with an encrypted secret has only the encrypted files (I believe with or without the file tree, depending on secret type).  To retrieve the data, you must connect with another computer having the normal read-only or read-write secrets (ie they will download and decrypt it).   I don't know all the details of this, or the types of encrypted keys, but I do know that it's possible and used by quite a few people with untrusted hosts (be it a hosting provider or a friend/family member that they don't want able to see/change their files).

[ChrisH]

b.) have a server somewhere with btsync as "always on" device

 

Option a.) is perfectly fine, option b.) with the current design isn't. Realistically a server in some hosting environment is no "trusted device" in that the server (which you don't own and don't ultimately control) has the same pitfalls as a regular cloud storage service:

 

The provider can and may look into your files or may even be obliged to do so by law in certain cases. 

Nobody stops you from renting a root server and putting your own encryption layer on it - that's what I do. My hosting provider would need some very sophisticated procedures (like deep-freezing the RAM modules so the key stays readable when they pull them out) - I don't think that's realistic. It's much easier to e.g. break into my house and plug some spying device into the LAN.

 

Also, BTSync offers encrypted read only secrets so that hosts store the data only encrypted.

[dfens]

Nobody stops you from renting a root server and putting your own encryption layer on it - that's what I do. My hosting provider would need some very sophisticated procedures (like deep-freezing the RAM modules so the key stays readable when they pull them out) - I don't think that's realistic. It's much easier to e.g. break into my house and plug some spying device into the LAN.

 

Also, BTSync offers encrypted read only secrets so that hosts store the data only encrypted.

 

is there any documentation on how encrypted secrets work?

Edited August 26, 2014 by dfens

[ChrisH]

is there any documentation on how encrypted secrets work?

 

There is http://forum.bittorrent.com/topic/25823-generate-encrypted-read-only-secret-without-api-key but I'm not sure if this still works in 1.4.

 

BTW I was talking about real metal, not vServers (and Windows, not Linux) - but yes, you probably are right about DMA. Still, I trust my hoster enough (and I have never heard about the police using sophisticated stuff like that - usually they just grab the hardware and take it to their overworked tech labs).

[dfens]

Thanks, that pretty much sums it up. So basically it is working, but not readily documented at this point and not pushed by the developer (since it doesn't seem to be implemented properly in the main client).

 

I get how "to get it working", but is there any information on how the file encryption actually works? As i understand it, the normal modus operandi is to use a cryptographic one way hash of the secret for adressing and use several keys for authentication and access control. Transport encryption - is it based on session keys or based on the actual secrets?

 

I didn't find any documentation on how the actual files on the "encrypted secret" node are encrypted, stored and exchanged. Now the obvious question to me is: with what keys are the files encrypted that are stored on the encrypted node? They can't be encrypted based on the master secret i assume, especially in light of:

 

"If you are concerned about security, BitTorrent Sync provides opportunity to regularly generate new Secrets for a folder, or replace an existing secret with your own Base64 string more than 40 characters long. The new folder secret should be re-entered on all the devices in sync."

 

If the files in transit are encrypted using the 20 byte master secret the encrypted node could just store the encrypted file, though that would open another can of issues. If it uses a key that is derived, the question would be - how?

 

Reading through thee forums i get the impression:

 

Master key -> 20 bytes randomly generated -> beencoded -> Master Secret - used for addressing AND encryption/decryption

edit: apparently this is wrong, the read only key is always generated and the hash of a part of the read only key is used for addressing

 

Read only secret -> derived from Master key (edit: apprently a sha256 hash of the masterkey), split addressing and encryption/decryption key

Encrypted secret -> part of the read only key, probably the part that gets hashed for addressing, but lacking the decryption/encryption key

 

edit2: apparently the announce hash is a sh256hash of the readonlykey so basically sha256(addressing part of sha256(masterkey))

 

So it seems that for the read only key addressing and decryption was decoupled and only the former is used for the encrypted secret.

 

One argument that was made by the BT folks was that the encrypted secret is not in the client because it would add additional load on embedded systems. However as far as i understand it, the systems that store encrypted files don't do any cryptographic operations and the systems that transmit files have to do transport encryption anyways. Added workload would only happen, if there was an extra layer of encryption, that doesn't use the transport encryption but works with derived keys that would have to be persistent on the encrypted node ala MEGA. Is there any documentation or observations concerning this?

 

 

@CrisH: those DMA based forensic tools are not really sophisticated nowadays, they are turnkey "plug and play" solutions that work for several DMA capable hardware interfaces, exspecially if you run a standard Windows or Linux Distribution.

[tcurdt]

I would also looooove to have to have some kind of super or seed node where information is stored on only encrypted. (adding some kind of encryption layer on top myself is not enough)

[ChrisH]

Did you read the thread?

[tcurdt]

I might have missed the link to the other thread.

Sounds like it is implemented but not exposed.

 

You can generate encrypted read-only secrets using the normal btsync client without any API key.

 

Do the normal "Add a Sync Folder",

click "Generate", but change the first letter of the "Folder sercet" from "A" to "D" (see 1 and 2),

set the "Folder to sync", click "OK",

right click on that folder from the list,

click "Show Folder Preferences",

copy the "Read only secret" (see 3),

paste it into Notepad(or other text editor),

"Encrypted Read-Only Secret" is the first 33 char of that string with the first letter changed from a "E" to "F" (see 3 and 4)

 

 

 

 

The Encrypted nodes functionality is implemented in code and therefore is working. There is no UI for it now, so it can be accessed either via modifying Secret's prefix (as in instruction above) or via API.