Backup encryption - why implement?

[s7eu...@mailtor.net]

> On 23.12.2013 05:45, Axon wrote:
>> I noticed the following lines in /core-admin/core/backup.py:
>>
>>
>> if encrypt:
>> # Start encrypt
>> # If no cipher is provided, the data is forwarded
>> unencrypted !!!
>> encryptor = subprocess.Popen (["openssl", "enc",
>> "-e", "-aes-256-cbc",
>> "-pass", "pass:"+passphrase] +
>> (["-z"] if compress else []),
>> stdin=pipe, stdout=subprocess.PIPE)
>>
>>
>> The GUI doesn't appear to allow the user to specify a desired cipher. Is
>> there a way to do this? Maybe a command line flag?
>>
>> Also, I was under the impression that CBC is no longer recommended (and
>> that XTS is now recommended). Does the user have any options here?
>
> As you see, the encryption cipher is hardcoded. There is also no place in
> backup header to store chosen cipher (so if it would be configurable, the
> user
> must provide the same manually during restore). But anyway it is doable to
> add
> configuration option and even change the default.
>
> Joanna, what do you think about this?
>
> --
> Best Regards,
> Marek Marczykowski-GĂłrecki
> Invisible Things Lab
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
>
>

Playing Devils Advocate, would it not be better to leave the encryption /
security of backups to the user? It appears that a small error in the
above python code (omission of a cipher) would lead to the backup not
being encrypted, giving the user potential false sense of security.

In the existing documentation, it is recommended to backup to a luks
encrypted external backup volume. I think this works well. If a user wants
to place an encrypted backup in email, ftp, "the cloud", etc..then there
are tools available such as GnuPG and the openssl command line to encrypt
a single file. The advantage here would be that the user could encrypt
with a keyfile instead of or in addition to a passphrase, and automate
this process.

Can I ask the reason for wanting to build option to backup the file into
Qubes? There are existing tools, this means we are having to trust yet
another implementation. Corollary to many eyes make bugs shallow must be
to minimise, as Qubes project has so successfully done, security critical
parts of the codebase.

I've likely overlooked some good reasons for encrypting backups in Qubes
and would be interested to learn them.

[Joanna Rutkowska]

Qubes is specific in several way. It maintains many separate, mutually
untrusted VMs, which makes also their filesystems, and so backups, to be
treated as untrusted.

Certainly it is not an option to require to e.g. mount each of the VM's
filesystems to Dom0 filesystem (in order to make the backup), because
mounting of an untrusted filesystem is a very risky operation (think
e.g. malformed metadata that might exploit a hypothetical bug in the
Dom0 kernel filesystem module).

Also, with the recent innovation on the backup system that was
introduced in R2B3, it is now possible to save and restore backups
to/from *untrusted* AppVM. And yet this all is possible without
requiring double space for the backup in any place on the system.

joanna.

[Axon]

Axon wrote:
> I noticed the following lines in /core-admin/core/backup.py:
>
>
> if encrypt:
> # Start encrypt
> # If no cipher is provided, the data is forwarded
> unencrypted !!!
> encryptor = subprocess.Popen (["openssl", "enc",
> "-e", "-aes-256-cbc",
> "-pass", "pass:"+passphrase] +
> (["-z"] if compress else []),
> stdin=pipe, stdout=subprocess.PIPE)
>
>
> The GUI doesn't appear to allow the user to specify a desired cipher. Is
> there a way to do this? Maybe a command line flag?
>
> Also, I was under the impression that CBC is no longer recommended (and
> that XTS is now recommended). Does the user have any options here?
>

Does the existence of practical malleability attacks against
CBC-encrypted Qubes backups present a good reason for changing the
default Qubes backup encryption algorithm to AES-256-XTS?


The idea is that it might be possible for an attacker with access to a
Qubes backup (e.g., stored offsite) to perform a malleability attack
against a CBC-encrypted Qubes backup. Such an attack could, in theory,
allow for the targeted manipulation of the plaintext, e.g., for the
purpose of injecting a full remote code execution backdoor which would
be available to the attacker once the Qubes user restores from the
compromised backup file.

However, the risk of such an attack succeeding in practice is perhaps
mitigated by the fact that Qubes backups are backups only of the
contents of user data (i.e., home directories) rather than entire
encrypted partitions or disks which include the full OS.

Nonetheless, if it's only a matter of changing three characters in the
code, the change may be worthwhile.

Details:
http://www.jakoblell.com/blog/2013/12/22/practical-malleability-attack-against-cbc-encrypted-luks-partitions/

[Axon]

On second thought, maybe this isn't a problem since each CBC-encrypted
private.img file is already integrity-checked against its HMAC before
decryption is attempted.

[Axon]

...Except, the default HMAC algorithm is SHA-1, which may not be a
prudent choice for long-term backups. Is there any reason not to make
the default SHA-256 or SHA-512? Performance could be one reason. Is the
performance-security trade off significant here?

Of course, users can opt to specify whichever algorithms they desire
with command-line switches, but IMO the defaults are still important for
at least two reasons:

1. The GUI makes it much easier to select which VMs to backup when the
user has a very large total number of VMs.

2. Most users will not realize that they can (and in some cases should)
specify their own algorithms, and we can rescue them by changing just
one line of code. ;)

If there is resistance to changing the default, perhaps it would be
possible to allow the users to set their own default algorithms in a
config file (so that we can still use the GUI to perform backups)?

[Pedro Martins]

Thanks for the link.

>
> On second thought, maybe this isn't a problem since each CBC-encrypted
> private.img file is already integrity-checked against its HMAC before
> decryption is attempted.
>

And one can always perform additional rounds of encryption on the
backups before sending them to offsite storage.

--
Pedro Martins

[bradbury9]

El martes, 16 de septiembre de 2014 10:46:49 UTC+2, Axon escribió:

Axon wrote:

If there is resistance to changing the default, perhaps it would be
possible to allow the users to set their own default algorithms in a
config file (so that we can still use the GUI to perform backups)?

Or remove the actual CheckBox and add a Radio in the GUI with:

None

SHA-1

SHA-256

SHA-512 (adviced)

[Axon]

Here's some further reading on why HMAC-SHA1 is probably a bad idea for
long-term use.

Short answer:
http://stackoverflow.com/a/2894496

Long technical paper:
http://eprint.iacr.org/2012/074.pdf

[Axon]

True, but:

1. This is unnecessarily labor-intensive for the end user.
2. The need for this can be avoided with a small, simple change.
3. The security of the backup system should stand on its own merits
without being propped up by the end user.
4. Outside security experts or prospective users who examine Qubes might
negatively judge Qubes as a whole on the basis of minor perceived flaws.
(Of course, if those perceptions are inaccurate, then the prudent thing
to do is to leave the code unchanged and to address the misconception in
an FAQ.)

[Marek Marczykowski-Górecki]

Default HMAC algo changed to SHA512:
http://git.qubes-os.org/?p=marmarek/core-admin.git;a=commit;h=dba6798a607866e7c7bcb0a4e386ccbae7743dac


--
Best Regards,
Marek Marczykowski-Górecki

[Davíð Steinn Geirsson]

On Tue, 16 Sep 2014 01:41:17 +0000
Axon <ax...@openmailbox.org> wrote:

> Axon wrote:
> > I noticed the following lines in /core-admin/core/backup.py:
> >
> >
> > if encrypt:
> > # Start encrypt
> > # If no cipher is provided, the data is forwarded
> > unencrypted !!!
> > encryptor = subprocess.Popen (["openssl", "enc",
> > "-e", "-aes-256-cbc",
> > "-pass", "pass:"+passphrase] +
> > (["-z"] if compress else []),
> > stdin=pipe, stdout=subprocess.PIPE)
> >
> >
> > The GUI doesn't appear to allow the user to specify a desired
> > cipher. Is there a way to do this? Maybe a command line flag?
> >
> > Also, I was under the impression that CBC is no longer recommended
> > (and that XTS is now recommended). Does the user have any options
> > here?
> >
>
> Does the existence of practical malleability attacks against
> CBC-encrypted Qubes backups present a good reason for changing the
> default Qubes backup encryption algorithm to AES-256-XTS?

XTS is not a good choice for this kind of work. Thomas Ptacek puts it
better than I could:
http://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/

That said, as you already noted, this is not really an issue since
qubes adds an HMAC after encryption. :)

[Joanna Rutkowska]

Nevertheless the article makes a good point that FDE on block-level
might not be the best place to enforce authentication, something that
might be relevant for Qubes FDE (not backups). I think it's a no-brainer
that we would also lik to have authentication (integrity protection) for
FDE. The questions is: should we use LUKS for that or should this be
enforced on filesystem-level?

j.

[Davíð Steinn Geirsson]

I'm no crypto expert, I just play one on mailing lists :)

I guess the main alternative to block-level crypto on linux is
eCryptfs. A cursory glance at the docs suggests it can do integrity
protection using a MAC. But I get the feeling that eCryptfs has had
much less eyeballs on the design and code than LUKS has. One option
would be to do eCryptfs-on-LUKS, if the performance cost is acceptable.

-Davíð