compressed & encrypted flags

[Maciej Pijanowski]

Hello,

I wanted to try out image encryption feature and I stumbled upon following message:

[NOTIFY] : SWUPDATE failed [0] ERROR core/cpio_utils.c : copyfile : 153 : encrypted zip images are not yet supported -- aborting
 
I looked at the code and I've discovered that compressed & encrypted flags combination is forbidden:

  /*
     * Simultaneous compression and decryption of images
     * is not (yet ?) supported
     */
    if (compressed && encrypted) {
        ERROR("encrypted zip images are not yet supported -- aborting\n");
        return -EINVAL;
    }

Could You elaborate on what's the reason behind this and where in the could should I look for the conflict and possible implementation
of such functionality? I wouldn't like dropping compressed flag, as compression reduces image size significantly.

Thanks,

[Stefano Babic]

Hi Maciej,

Encryption and compression do not work together. In cryptography's books
it is discouraged to use both. In fact, both encryption and compression
will scrambled data. We can have two cases:

- first encrypt, then compress. We do not add security issues, but we
can spare the step. Encrypted data are so scrambled that a compression
is worthless.

- first compress, then encrypt. At first glance, this seems the
solution. But this creates a security leak, because the nature of the
data is known (a zip image). An attacker can use this information to
find patterns in the decrypted data.

See the CRIME and BREACH attacks:

https://en.wikipedia.org/wiki/CRIME
https://en.wikipedia.org/wiki/BREACH

In most cases, encryption and compression should not use at the same time.

Best regards,
Stefano

--
=====================================================================
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=====================================================================

[Romain Bazile]

Hello,

I beg to disagree.

Your first scenario is valid, there is no point in compressing after
encryption. Random data does not compress well (if at all).


However, for the second scenario, I do not believe there is a security
leak nor a security breach.
Both attacks you mentioned involved the ability for the attacker to
craft messages and analyse responses from the website under attack to
uncover the secret keys.
In our use case, we download relatively big files from a server, which
serves almost all the time the same file (at least, the attacker can't
force the server to serve anything else than what we send and can't
forge requests to analyse the responses).

This means that the attacker can't use those attacks.

This stack exchange security question resumes well the answer:
https://security.stackexchange.com/questions/19969/encryption-and-compression-of-data

The attack can only be done in an _interactive_ environment, where the
attacker can actually inject part of known strings in an unknown stream
of data. Which is not our use case at all.


I too would think it would be good to support both compression and
encryption(necessarily in that order, as to per your first point), and
support this request for change.

Sincerely,

Romain Bazile
Hardware R&D Engineer
www.ubiant.com

[Stefano Babic]

Hi Romain,

On 09/08/2017 19:24, Romain Bazile wrote:
> Hello,
>
> I beg to disagree.
>
> Your first scenario is valid, there is no point in compressing after
> encryption. Random data does not compress well (if at all).
>

ok

>
> However, for the second scenario, I do not believe there is a security
> leak nor a security breach.
> Both attacks you mentioned involved the ability for the attacker to
> craft messages and analyse responses from the website under attack to
> uncover the secret keys.

Right.

> In our use case, we download relatively big files from a server,

About the size, this is true in most cases. There are also cases where
the SWU contains just a few MBytes, and this is the FW for an attached
microcontroller (I had such a use case). But again, in 95% of cases we
have large images.

> which
> serves almost all the time the same file (at least, the attacker can't
> force the server to serve anything else than what we send and can't
> forge requests to analyse the responses).
>

This is true.

> This means that the attacker can't use those attacks.
>
> This stack exchange security question resumes well the answer:
> https://security.stackexchange.com/questions/19969/encryption-and-compression-of-data

Thanks for the link.

>
>
> The attack can only be done in an _interactive_ environment, where the
> attacker can actually inject part of known strings in an unknown stream
> of data. Which is not our use case at all.
>
>
> I too would think it would be good to support both compression and
> encryption(necessarily in that order, as to per your first point), and
> support this request for change.

I will just add this as new feature in the roadmap, so that it will not
be lost for the future.

Best regards,
Stefano Babic

[Maciej Pijanowski]

I'm wondering how difficult would it be to implement this. I can see that
whole decryption / decompression is done within copyfile in cpio_utils.c?

> Best regards,
> Stefano Babic
>
>

--

Maciej Pijanowski
Embedded Systems Engineer
http://3mdeb.com | @3mdeb_com

[Stefano Babic]

Hi Maciej,

True, decompress and decryption must be pipelined - decryption works
already with buffers in memory, the decompression must be convinced to
do the same

Best regards,
Stefano

[Maciej Pijanowski]

On 11.08.2017 10:27, Stefano Babic wrote:
> Hi Maciej,
Hi,

I'd like to ask if you have any more thoughts about this implementation
in SWUpdate.
We would like to estimate the effort of such contribution.

> Best regards,
> Stefano

[Stefano Babic]

On 08/09/2017 11:11, Maciej Pijanowski wrote:
>
>

No, it is clear to me what should be done to get it working ;-)