request for TLBleed information / non-constant-time vulnerabilities

[Michael R. Hines]

NIIBE,

Thank you so much for your response. This was extremely helpful. =)

- Michael

On 08/22/2018 07:49 PM, NIIBE Yutaka wrote:
> Hello,
>
> I should have answered earlier.  I was joining Debconf18 in Hsinchu and
> was busy to distribute 5x5 LED Matrix board.
>
> The paper is great, it shows us coarse-grained leak like the one through
> TLB (the shared resource) is still important.
>
> But... from the libgcrypt developer(s) view, it's somewhat confusing, I
> have to say.  I don't know if it's intentional, if not, I wish
> improvement for their clarification.
>
> Please note that they have not reported to us.  If had, I would have
> complained. :-)
>
>
> "Michael R. Hines" <mrhines at digitalocean.com> wrote:
>> Our team is trying to get an accurate understanding of whether or not
>> the most recent version of libgcrypt does or does not remain vulnerable
>> to the timing attack document here:
>> https://www.vusec.net/wp-content/uploads/2018/07/tlbleed-author-preprint.pdf
> For an attack to libgcrypt EdDSA described in the paper, it is
> irrelevant to _any_ versions of libgcrypt, if "signing" refers the use
> of the function _gcry_ecc_eddsa_sign.
>
> I mean, the scenario never occurs in real use case of
> _gcry_ecc_eddsa_sign.  In the paper, it says, "We use the non-
> constant-time version in this work.", in the second paragraph in section
> 8 "Temporal Analysis".  I interpret that they changed the code so that
> their attack can work for that path.  It is artificial, from my
> viewpoint.
>
> In _gcry_ecc_eddsa_sign, the scalar A is allocated in secure memory.
> So, it always goes another path, which always call
> _gcry_mpi_ec_add_points.
>
> They would have targeted the call of point_set function in the old
> version of 1.6.3.  This was fixed in 2015, to use point_swap_cond,
> unconditionally.  Version 1.7.0, 1.8.0 or later has this fix.
>
>
> For an attack to libgcrypt RSA, it is also not the real use case,
> but artificial (for 1.6, 1.7 and 1.8).
>
> We keep the old and simple implementation of _gcry_mpi_powm, which can
> be enabled with the macro USE_ALGORITHM_SIMPLE_EXPONENTIATION.  Their
> target is this code, which is not used since 1.6.0.
>
> Well, in 1.8.0, I modified this implementation too.  So, if they attack
> the one in 1.8.0, it won't work.
>
>
>> In addition to that, more generally, as a cloud provider we are also
>> looking for input and guidance on whether or not there are other
>> locations that should be of concern within libgcrypt from the
>> perspective of TLBleed.
> Although their current version of "attacks" are pretty artificial (for
> me), their points make sense; There are more possibility of side channel
> leaks, along with improvements of signal analysis and reverse
> engineering of lower architecture.
>
> We need to remove any non-constant time code.