Caveat Implementor! Key Recovery Attacks on MEGA

MEGA is a large-scale cloud storage and communication platform that aims to provide end-to-end encryption for stored data. A recent analysis by Backendal, Haller and Paterson (IEEE S &P 2023) invalidated these security claims by presenting practical attacks against MEGA that could be mounted by the MEGA service provider. In response, the MEGA developers added lightweight sanity checks on the user RSA private keys used in MEGA, sufficient to prevent the previous attacks.

We analyse these new sanity checks and show how they themselves can be exploited to mount novel attacks on MEGA that recover a target user’s RSA private key with only slightly higher attack complexity than the original attacks. We identify the presence of an ECB encryption oracle under a target user’s master key in the MEGA system; this oracle provides our adversary with the ability to partially overwrite a target user’s RSA private key with chosen data, a powerful capability that we use in our attacks. We then present two distinct types of attack, each type exploiting different error conditions arising in the sanity checks and in subsequent cryptographic processing during MEGA ’s user authentication procedure. The first type appears to be novel and exploits the manner in which the MEGA code handles modular inversion when recomputing \(u=q^{-1} \bmod p\). The second can be viewed as a small subgroup attack (van Oorschot and Wiener, EUROCRYPT 1996, Lim and Lee, CRYPTO 1998). We prototype the attacks and show that they work in practice.

As a side contribution, we show how to improve the RSA key recovery attack of Backendal-Haller-Paterson against the unpatched version of MEGA to require only 2 logins instead of the original 512.

We conclude by discussing wider lessons about secure implementation of cryptography that our work surfaces.

1. 1.

   This by itself does not suffice for authenticated encryption security, but presents the “immediate” level of countermeasures, i.e. the most easily achievable solution in the short term. [2] outlines further levels of countermeasures termed “minimal” and “recommended”, which provide better guarantees but require more fundamental changes to the MEGA platform.

2. 2.

   For \( x \in \mathbb {Z}\), the value of \(| x |_{\textsf{b}} \) as understood by the MEGA client implementations is not always exact. In the big integer representation used by the web client, \(| x |_{\textsf{b}} \) is normally rounded up to the closest multiple of 8 or 32.

3. 3.

   For instance, we omit the file attributes in our description for simplicity.

4. 4.

   We include the prime \( p ' \) for several reasons. First, because of one of the uncaught errors, we must make sure that \( q \bmod p \ne 0\). Further, to avoid false positives from error \(\bot _{5} \), we need the \(\gcd ( p , q ) \ne 1\) signal to be equivalent to \(\gcd ( p , q ) = r _ i \).

5. 5.

   Note that the attack can be easily modified to use one less login for each \( r _ i \). This is because, in the online phase, if the server does not get a positive answer from the oracle for any of the values \( t \in \left\{ 0, \ldots , r _ i - 2\right\} \), it means that the value \( r _ i - 1\) is the correct one and so does not need to be submitted explicitly.

6. 6.

   That is, \({\texttt{ptd}}[{0}:{4}] = {\texttt{p}}[{124}:{128}] \) for all \(\texttt{p} \), and \({\texttt{ptp} _ i }[{0}:{2}] = {\texttt{q} ^*}[{126}:{128}] \) for all \(\texttt{q} ^*\).

7. 7.

   There is a possibility that \( d ^* \bmod ( p - 1)( q - 1) = 0\) where \( d ^* \leftarrow d ' + ( d \bmod 2^{1968})\) and \( d \) is the original value encrypted in \(\texttt{ct} \). Because of the uncaught non-termination bug arising during the computation of \(( d ^*)^{-1} \bmod ( p - 1)( q - 1)\), in this case the attack would fail, but this is highly unlikely to happen in practice.

8. 8.

   Note that the server does not know whether this is because prior to zero-padding, we have \(| m ^* |_{\textsf{B}} \le | N ^* |_{\textsf{B}} - 2\) and therefore trivially \({\texttt{m} ^*}[{1}] = \texttt{00} \) or because \(| m ^* |_{\textsf{B}} = | N ^* |_{\textsf{B}} \) and \({\texttt{m} ^*}[{1}] = \texttt{00} \). However, the root cause is immaterial to our attack.

9. 9.

   The factors do not need to be common between \(( p ^* - 1)\) and \(( q ^* - 1)\), and can be freely distributed between the two.

10. 10.

    These primes could repeat, the goal here is to avoid \(( p ^* - 1)( q ^* - 1)\) having any other small factors except for \( r _0 , \ldots , r _{ n -1}\).

11. 11.

    Note that by the choice of \( d ^\prime \), overwriting the least significant full block of \( d ^\prime \) with \( B \) is equivalent to adding \(2^{48} \cdot B \) to \( d ^\prime \).

12. 12.

    An honest response refers to the data that an honest server would have sent. Note that in this case, the “honest” \(\texttt{uh} \) will not match the value recovered from \(\texttt{c} ^*_{ i , x }\), but this check only comes after the errors triggered by the attack. The attacker could equally replace the \(\texttt{uh} \) value with an arbitrary 11-byte UTF-8 string.

13. 13.

    This is also why we cannot make the block-aligned simplification for this attack, because if we aligned it such that the least-significant block of \( d ^*\) is full and therefore placed our target block \( B \) there, then if \( B \equiv 0 \pmod {2}\) the client would output error \(\bot _{6} \) on all queries.

14. 14.

    Note that an 11 B byte string interpreted as a valid UTF-8 string will likely not be a string of size 11, i.e. a string consisting of 11 characters, since not all byte values are interpreted as text and non-ASCII characters require multiple bytes to encode [36].

15. 15.

    One alternative is to instead for all \( t \in \mathcal {T} _ i \) submit \( x ' \leftarrow x \cdot t ^{-1} \cdot t _j \bmod r _ i \) for some \( t _j \in \mathcal {T} _ i , t _j \ne t \), and use the original error \((\bot _{2}, 254)\) as the confirmation signal. This still has a potential for false positives and false negatives, however. A final, and most expensive, failover strategy is then to cycle through all values of \( x \), saving the ones for which the client returns \((\bot _{2}, 254)\) and then running an offline computation to determine which \( x \) values are matched to which \( t \) values.

16. 16.

    The traditional presentation of this algorithm invokes the LLL algorithm which gives a short vector that is at most an exponential factor away from the shortest vector. However, the lattice dimensions involved here are in the range where the shortest vector problem (SVP) can be solved efficiently in practice – say, up to dimension 150 [7] – and we may thus simply assume we solve SVP. In any case, the exponential factor is \(\approx 1.0219^{h}\) which is \(< 3\) for \(h \le 50\).

17. 17.

    We extract \(g(x)\) as \(g^{(j)} {:}{=}v_{j}/X^{j} \in \mathbb {Z}\).

18. 18.

    We note that this computation is “proudly parallel” or “embarrassingly parallel”. This is because for each of our \(2^{16}\) guesses we can run an independent lattice reduction. We also note that the running time is independent of whether the input instance corresponds to a correct or incorrect guess. Moreover, incorrect solutions resulting from incorrect guesses can be filtered out using the known public key.

19. 19.

    In contrast to timing-based side-channel attacks, generally considered less practical in the remote, as opposed to local, setting.

The research of Mareková was carried out in part during a visit to the Applied Cryptography Group at ETH Zürich. She was also supported by the EPSRC and the UK Government as part of the Centre for Doctoral Training in Cyber Security at Royal Holloway, University of London (EP/P009301/1). The work of Paterson was supported in part by a gift from VMware. The work of Albrecht was done while Albrecht was at Royal Holloway.

Authors and Affiliations

1. King’s College London, London, UK

   Martin R. Albrecht

2. Applied Cryptography Group, ETH Zurich, Zurich, Switzerland

   Miro Haller & Kenneth G. Paterson

3. Information Security Group, Royal Holloway, University of London, London, UK

   Lenka Mareková

Corresponding author

Correspondence to Lenka Mareková.

Editors and Affiliations

1. Bar-Ilan University, Ramat Gan, Israel

   Carmit Hazay

2. Simula UiB, Bergen, Norway

   Martijn Stam

Reprints and permissions

© 2023 International Association for Cryptologic Research

Policies and ethics