FR private key support

[Efreak]

Currently there's no way to add a private key to correct to sftp servers. I see in #82 you're existing all diffusion settings, but there's still no easy way to actually get the file to the apps internal storage[^1]

[^1]: I'd actually prefer the key to be in the Android keychain like tergent does, depending on fingerprint authentication to be used, but that would require specific code for a single type of remote. If anyone else asks for this, https://github.com/aeolwyr/tergent/issues/15#issuecomment-1479797342 might help, not sure)

I tried adding the key files to the zip backup, but they were ignored when I imported the backup. Instead, I edited the rclone.conf to create a remote for the internal app data at /data/data/de.felixnuesse.extract/files and added the key_file path to my sftp configuration, then rezipped and imported. After this, I enabled a webdav server for the internal app data remote and copied the public and private keys into the apps private data directory using my file manager. This finally allows me to connect to my sftp server via rclone and get rid of FileManagerUtils (which doesn't support key authentication at all). If only my file manager actually supported it...

This is a big workaround (that thankfully only had to be done once). I suggest the following:

1. Simply extract the contents of the backup to the necessary directory. Set the HOME environment variable to the private data files location, this way user can set the path relative to that directory (~/.ssh/id_rsa) in the rclone config. Later backups should also export these extra files.
2. Encrypt backups. This should be done regardless, since there's passwords and so on in the file. A standard user-reversible encryption such as password-protected zip file is preferred.

[newhinton]

Simply extract the contents of the backup to the necessary directory. Set the HOME environment variable to the private data files location, this way user can set the path relative to that directory (~/.ssh/id_rsa) in the rclone config. Later backups should also export these extra files.

This seems like a straightforward implementation. In addition to that, i would implement a button somewhat like "Import Keys" which will take care of the importing.

The encrypted backups-one is a different topic. rcx did support import of encrypted rclone-files, however i feel that there is not much benefit to it. Modern android devices should use full disk encryption by default, so the rclone config on the device itself shouldn't need additional protection. If you then export the backup, you could handle that yourself.

Though i see why one would like me to do it. I will think about a rudimentary way to do this, but dont expect it soon ;)

[youk]

Modern android devices should use full disk encryption by default, so the rclone config on the device itself shouldn't need additional protection.

rclone config frequently contains sensitive information (such as passwords or access tokens). It requires protection measures beyond encrypted storage which becomes accessible once device is unlocked.

BTW, Android switched from full-disk encryption to file-based one quite a long time ago. So "modern android devices" simply can't use FDE.

[newhinton]

BTW, Android switched from full-disk encryption to file-based one quite a long time ago. So "modern android devices" simply can't use FDE.

That is true, but it doesn't detract from the argument. The rclone config is protected by the operating system. While encrypted, the data is simply unavailable to someone outside. After unlocking the device, file security is handled by android itself. As long as the device is unrooted, no other apps beside the OS can access that file. If the device is rooted, or compromised, there is simply no way to secure the config, regardless of encryption. So to me it is not worth the effort for something that is easily circumvented anyway.

[youk]

The rclone config is protected by the operating system. While encrypted, the data is simply unavailable to someone outside.

The level of protection you are talking about is inadequate for protecting secrets. Secrets should be:

a. protected by a passphrase b. non-exportable

If the device is rooted, or compromised, there is simply no way to secure the config, regardless of encryption.

It is only true if there is no encryption beyond OOTB FBE. However, there is no need to rely on a single level of encryption.

On a more general note, the truly secure way to protect secrets on Android is to use hardware-backed keystore. Sure, one can claim that access tokens is not a such big deal.

[newhinton]

It is only true if there is no encryption beyond OOTB FBE

No, this is true regardless of encryption. If an attacker has the highest level of access (eg. root-access), said attacker can simply dump your passphrase for your config and get it anyway from memory. Hell, they could bypass that step entirely and just get the decrypted config from memory directly, no need for passphrases.

Anyway, this is also not the proper issue for this. For encrypted config, look here: #200