Mailing List Archive: Side-channel vulnerability in libgcrypt - the Marvin Attack

Side-channel vulnerability in libgcrypt - the Marvin Attack

gcrypt-devel at gnupg

Mar 7, 2024, 5:46 AM

Post #1 of 16 (198 views)

Hello,

I've tested libgcrypt against the Marvin Attack[1] and have verified it to
be vulnerable.

Running the test harness from marvin-toolkit[2] I got the following result:

tlsfuzzer analyse.py version 5 analysis
Sign test mean p-value: 0.1769, median p-value: 0.01503, min p-value:
4.587e-55
Friedman test (chisquare approximation) for all samples
p-value: 2.0539047856632484e-85
Worst pair: 2(no_padding_48), 4(signature_padding_8)
Mean of differences: 2.09765e-07s, 95% CI: 1.83451e-07s, 2.311208e-07s
(±2.384e-08s)
Median of differences: 2.09797e-07s, 95% CI: 1.81122e-07s, 2.323270e-07s
(±2.560e-08s)
Trimmed mean (5%) of differences: 2.09885e-07s, 95% CI: 1.84586e-07s,
2.308092e-07s (±2.311e-08s)
Trimmed mean (25%) of differences: 2.10169e-07s, 95% CI: 1.84646e-07s,
2.302561e-07s (±2.281e-08s)
Trimmed mean (45%) of differences: 2.09076e-07s, 95% CI: 1.82240e-07s,
2.321705e-07s (±2.497e-08s)
Trimean of differences: 2.08114e-07s, 95% CI: 1.80188e-07s, 2.266213e-07s
(±2.322e-08s)

Looking more closely at results, the side-channel from removal of blinding
or conversion of the integer returned from the RSADP() operation[3] to a
byte string is the most significant source of leakage.
That means that all padding modes that use RSA will be vulnerable: raw RSA
(RSASVE), PKCS#1v1.5, and RSA-OAEP.

But even with this code fixed, because the API of the decryption operation
doesn't permit a side-channel free returning of error messages (as the
returned object has different type and size depending on error or size of
the decrypted message), fixing it will require either implementing implicit
rejection or providing API specifically for PKCS#1v1.5 decryption.

This issue has been assigned CVE-2024-2236

1 - https://people.redhat.com/~hkario/marvin/
2 -
https://github.com/tomato42/marvin-toolkit/tree/master/example/libgcrypt
3 - https://datatracker.ietf.org/doc/html/rfc8017#section-5.1.2
--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky?ova 115, 612 00, Brno, Czech Republic

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gcrypt-devel

Re: Side-channel vulnerability in libgcrypt - the Marvin Attack [ In reply to ]

Mar 7, 2024, 6:55 PM

Post #2 of 16 (198 views)

Hello,

Hubert Kario wrote:
> I've tested libgcrypt against the Marvin Attack[1] and have verified it to
> be vulnerable.

Thank you for your report.

My understanding is that libgcrypt exposes timing differences against
chosen cipher texts by your timing analysis.

> Looking more closely at results, the side-channel from removal of blinding
> or conversion of the integer returned from the RSADP() operation[3] to a
> byte string is the most significant source of leakage.
> That means that all padding modes that use RSA will be vulnerable: raw RSA
> (RSASVE), PKCS#1v1.5, and RSA-OAEP.

The major possible causes of timing differences in libgcrypt are:

an old fork of GNU MP Bignum library for multi precision integer
arithmetic.

S-expression handling for multi precision integer representation.

I'd agree that we need documentation update of libgcrypt to explain
possible timing differences of libgcrypt RSA implementation; Well,
libgcrypt users should know that RSA private key may be at risk when
implementing decryption network service if timing information is
available to remote side.

If possible, could you give us some concrete information how large the
side-channel to compose a possible attack? It would be good for us to
know the impact of timing differences.
--

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gcrypt-devel

Re: Side-channel vulnerability in libgcrypt - the Marvin Attack [ In reply to ]

gcrypt-devel at gnupg

Mar 8, 2024, 2:27 AM

Post #3 of 16 (198 views)

On Friday, 8 March 2024 03:55:55 CET, NIIBE Yutaka wrote:
> Hello,
>
> Hubert Kario wrote:
>> I've tested libgcrypt against the Marvin Attack[1] and have verified it to
>> be vulnerable.
>
> Thank you for your report.
>
> My understanding is that libgcrypt exposes timing differences against
> chosen cipher texts by your timing analysis.

Correct, it's vulnerable to the chosen ciphertext attacks using timing
as a side-channel.

>> Looking more closely at results, the side-channel from removal of blinding
>> or conversion of the integer returned from the RSADP() operation[3] to a
>> byte string is the most significant source of leakage.
>> That means that all padding modes that use RSA will be vulnerable: raw RSA
>> (RSASVE), PKCS#1v1.5, and RSA-OAEP.
>
> The major possible causes of timing differences in libgcrypt are:
>
> an old fork of GNU MP Bignum library for multi precision integer
> arithmetic.
>
> S-expression handling for multi precision integer representation.

not only for integers, the result of the PKCS#1v1.5 decryption is also
returned as an S-expression and it includes memory allocation that is
exactly the size of the message. Combined with no memory allocation in
case of padding check failure, that gives a very clear signal.

So it's general S-expression handling of data that has secret lengths.

> I'd agree that we need documentation update of libgcrypt to explain
> possible timing differences of libgcrypt RSA implementation; Well,
> libgcrypt users should know that RSA private key may be at risk when
> implementing decryption network service if timing information is
> available to remote side.

+1 to that. Not every implementation needs to be side-channel safe, but
if it isn't, then the covered threat model needs to be documented so
that users can make informed decisions.

My reading of current https://gnupg.org/documentation/security.html
is that remote timing attacks are in scope. Only microarchitectural
attacks, like SPECTRE, are outside the threat model.

> If possible, could you give us some concrete information how large the
> side-channel to compose a possible attack? It would be good for us to
> know the impact of timing differences.

Not sure if I understand the question...

The size of the side-channel in libgcrypt is about 200 ns.
The smallest side-channel I was able to successfully differentiate
over the network, across 5 router hops (2 physically separate data centres
in the same city), is about 1 ns.

So in practice, to _fix_ a timing side-channel, the leakage needs to be
completely eliminated. Otherwise the attack is just a question of
attacker's persistence, not size of the side-channel.

--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky?ova 115, 612 00, Brno, Czech Republic

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gcrypt-devel

Re: Side-channel vulnerability in libgcrypt - the Marvin Attack [ In reply to ]

Mar 14, 2024, 11:42 PM

Post #4 of 16 (183 views)

Hello, again,

Hubert Kario <hkario@redhat.com> wrote:
> Correct, it's vulnerable to the chosen ciphertext attacks using timing
> as a side-channel.

Thank you for your confirmation.

>>> Looking more closely at results, the side-channel from removal of blinding
>>> or conversion of the integer returned from the RSADP() operation[3] to a
>>> byte string is the most significant source of leakage.
>>> That means that all padding modes that use RSA will be vulnerable: raw RSA
>>> (RSASVE), PKCS#1v1.5, and RSA-OAEP.
>>
>> The major possible causes of timing differences in libgcrypt are:
>>
>> an old fork of GNU MP Bignum library for multi precision integer
>> arithmetic.
>>
>> S-expression handling for multi precision integer representation.
>
> not only for integers, the result of the PKCS#1v1.5 decryption is also
> returned as an S-expression and it includes memory allocation that is
> exactly the size of the message. Combined with no memory allocation in
> case of padding check failure, that gives a very clear signal.
>
> So it's general S-expression handling of data that has secret lengths.

Thank you for your clarification.

>> I'd agree that we need documentation update of libgcrypt to explain
>> possible timing differences of libgcrypt RSA implementation; Well,
>> libgcrypt users should know that RSA private key may be at risk when
>> implementing decryption network service if timing information is
>> available to remote side.
>
> +1 to that. Not every implementation needs to be side-channel safe, but
> if it isn't, then the covered threat model needs to be documented so
> that users can make informed decisions.
>
> My reading of current https://gnupg.org/documentation/security.html
> is that remote timing attacks are in scope. Only microarchitectural
> attacks, like SPECTRE, are outside the threat model.

I think that we need to update the document to avoid possible confusion.

>> If possible, could you give us some concrete information how large the
>> side-channel to compose a possible attack? It would be good for us to
>> know the impact of timing differences.
>
> Not sure if I understand the question...
>
> The size of the side-channel in libgcrypt is about 200 ns.
> The smallest side-channel I was able to successfully differentiate
> over the network, across 5 router hops (2 physically separate data centres
> in the same city), is about 1 ns.
>
> So in practice, to _fix_ a timing side-channel, the leakage needs to be
> completely eliminated. Otherwise the attack is just a question of
> attacker's persistence, not size of the side-channel.

Again, thank you for your clarification.

I tried hard to consider a possible scenario we could imagine. I
managed to come up with something like:

* A crypto developer uses libgcrypt to build a secure enclave
implementation which offers RSADP service.

* He is not dumb, so, error return of gcry_pk_decrypt is hidden in the
service.

* But he is kind enough to attackers not having protection measures
against abuse for the service.

* In the service, side-channel of timing information is available to
attackers. Suppose there is no limitation for number of invocations.

In this scenario, yes, you are right that it's a matter of attacker's
persistence (or his/product lifespan). In theory, even with terrible
S/N ratio, information can be transmitted over a channel.

Thus, it means that RSA private key may be at risk, in this kind of
hypothetical scenario.

My original question was... about quantitative evaluation and
possibility in real cases. In other words, my interest is: if there are
any existing applications/services/products/etc., and the degree of how
likely are these problems and how much effort/time is needed to recover
RSA private key, in such a possible scenario.

Well, I think that there are other protection measures than eliminating
timing difference in the crypto library. We can consider the case of a
USB device. The communication from a device to host is basically
time-slotted (or device implementation can wait its response to the next
Start-Of-Frame, if needed). Timing information for the computation of
crypto operation can be hidden by time-slotted response.

Let us see how we can change our documentation.
--

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gcrypt-devel

Re: Side-channel vulnerability in libgcrypt - the Marvin Attack [ In reply to ]

gcrypt-devel at gnupg

Mar 15, 2024, 5:37 AM

Post #5 of 16 (183 views)

Hello

Thank you for your work and sharing your results!

How about the use case of interactively authenticating to a server
which is not controlled by oneself and therefore not fully trusted?
Since the authentication is interactive, the timing could matter.

For example, I am using my PGP key for SSH public-key authentication to
github.com and alike.

Regards
Stephan

Re: Side-channel vulnerability in libgcrypt - the Marvin Attack [ In reply to ]

gcrypt-devel at gnupg

Mar 15, 2024, 7:06 AM

Post #6 of 16 (183 views)

On Friday, 15 March 2024 13:37:16 CET, Stephan Verbücheln via Gcrypt-devel
wrote:
> Hello
>
> Thank you for your work and sharing your results!
>
> How about the use case of interactively authenticating to a server
> which is not controlled by oneself and therefore not fully trusted?
> Since the authentication is interactive, the timing could matter.
>
> For example, I am using my PGP key for SSH public-key authentication to
> github.com and alike.

Authentication uses signing, not decryption.
While there are also timing attacks on signing operations (see Kocher 1996
as the first example of those), that's not what I have been testing or
tried to
exploit.

While presence of timing attacks in decryption is a red flag, it's not a
guarantee that timing attacks in signing are exploitable. Or vice versa.

An implementation vulnerable to Bleichenbacher may be completely immune to
Kocher-like attacks and an implementation vulnerable to Kocher can be
completely immune to Bleichenbacher like attacks.
(though do note that Kocher allows for private key extraction, so if a
Kocher
like attack is possible, decryption of captured ciphertexts is also
possible)
--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky?ova 115, 612 00, Brno, Czech Republic

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gcrypt-devel

Re: Side-channel vulnerability in libgcrypt - the Marvin Attack [ In reply to ]

gcrypt-devel at gnupg

Mar 15, 2024, 7:14 AM

Post #7 of 16 (183 views)

On Friday, 15 March 2024 07:42:24 CET, NIIBE Yutaka wrote:
> Hello, again,
>
> Hubert Kario <hkario@redhat.com> wrote:
>>> I'd agree that we need documentation update of libgcrypt to explain
>>> possible timing differences of libgcrypt RSA implementation; Well,
>>> libgcrypt users should know that RSA private key may be at risk when
>>> implementing decryption network service if timing information is
>>> available to remote side.
>>
>> +1 to that. Not every implementation needs to be side-channel safe, but
>> if it isn't, then the covered threat model needs to be documented so
>> that users can make informed decisions.
>>
>> My reading of current https://gnupg.org/documentation/security.html
>> is that remote timing attacks are in scope. Only microarchitectural
>> attacks, like SPECTRE, are outside the threat model.
>
> I think that we need to update the document to avoid possible confusion.

Please do.

>>> If possible, could you give us some concrete information how large the
>>> side-channel to compose a possible attack? It would be good for us to
>>> know the impact of timing differences.
>>
>> Not sure if I understand the question...
>>
>> The size of the side-channel in libgcrypt is about 200 ns.
>> The smallest side-channel I was able to successfully differentiate
>> over the network, across 5 router hops (2 physically separate data centres
>> in the same city), is about 1 ns.
>>
>> So in practice, to _fix_ a timing side-channel, the leakage needs to be
>> completely eliminated. Otherwise the attack is just a question of
>> attacker's persistence, not size of the side-channel.
>
> Again, thank you for your clarification.
>
>
> I tried hard to consider a possible scenario we could imagine. I
> managed to come up with something like:
>
> * A crypto developer uses libgcrypt to build a secure enclave
> implementation which offers RSADP service.
>
> * He is not dumb, so, error return of gcry_pk_decrypt is hidden in the
> service.
>
> * But he is kind enough to attackers not having protection measures
> against abuse for the service.
>
> * In the service, side-channel of timing information is available to
> attackers. Suppose there is no limitation for number of invocations.
>
> In this scenario, yes, you are right that it's a matter of attacker's
> persistence (or his/product lifespan). In theory, even with terrible
> S/N ratio, information can be transmitted over a channel.
>
> Thus, it means that RSA private key may be at risk, in this kind of
> hypothetical scenario.
>
> My original question was... about quantitative evaluation and
> possibility in real cases. In other words, my interest is: if there are
> any existing applications/services/products/etc., and the degree of how
> likely are these problems and how much effort/time is needed to recover
> RSA private key, in such a possible scenario.

The current threat model specifies "Libgcrypt has been developed for use in
a
wide variety of platforms with different security needs." My reading of
that
is that it's an appropriate library for general purpose cryptography.

So yes, that means that Marvin requires such hypothetical scenario as you
talk about. But I'd say that using libgcrypt to implement a network API end
point that accepts Json Web Encryption tokens is not outside the realm of
possibility, or even a far fetched idea. And definitely within the
threat model as currently documented.

> Well, I think that there are other protection measures than eliminating
> timing difference in the crypto library. We can consider the case of a
> USB device. The communication from a device to host is basically
> time-slotted (or device implementation can wait its response to the next
> Start-Of-Frame, if needed). Timing information for the computation of
> crypto operation can be hidden by time-slotted response.

Actually no. If the time slots are consistent (say, the USB device returns
the message only on the second, on the dot), then the attacker can tune the
time when it _starts_ the operation so that it end exactly at the second.
Then quicker operations will be returned earlier, while slower will be
returned a second later.

The only way to effectively hide timing side-channel is to have operation
take the same amount of time always, but make it very long, so that
additional
load can't really push it towards that time. I mean like 30 to 60 seconds
per operation.

That won't mask any other side-channels, but may be enough to protect
against
simple timing attacks.

--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky?ova 115, 612 00, Brno, Czech Republic

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gcrypt-devel

Re: Side-channel vulnerability in libgcrypt - the Marvin Attack [ In reply to ]

Mar 15, 2024, 4:43 PM

Post #8 of 16 (183 views)

Hubert Kario <hkario@redhat.com> wrote:
> Actually no. If the time slots are consistent (say, the USB device returns
> the message only on the second, on the dot), then the attacker can tune the
> time when it _starts_ the operation so that it end exactly at the second.
> Then quicker operations will be returned earlier, while slower will be
> returned a second later.

This is not the communication of USB bus. The request from host is also
time-slotted. Your claim above would be only valid if the attacker can
start the request of the crypto operation from another channel where
timing can be accurately controlled, and the responce is on USB bus (for
some reason).

I don't think this is a general scenario in the real world.
--

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gcrypt-devel

Re: Side-channel vulnerability in libgcrypt - the Marvin Attack [ In reply to ]

gcrypt-devel at gnupg

Mar 18, 2024, 5:41 AM

Post #9 of 16 (171 views)

Hi,

> On 15. Mar 2024, at 07:42, NIIBE Yutaka <gniibe@fsij.org> wrote:
>
> My original question was... about quantitative evaluation and
> possibility in real cases. In other words, my interest is: if there are
> any existing applications/services/products/etc., and the degree of how
> likely are these problems and how much effort/time is needed to recover
> RSA private key, in such a possible scenario.

Just to give you a rough ball park of some numbers:

I looked at the same vulnerability in Apple’s CoreCrypto library. CVE-2024-23218 was assigned for that.

When directly measuring the affected decrypt operation, decryption of a cipher text without using the private key just by making calls to the timing oracle needed about 24 hours. I didn’t bother attempting to optimize this, and didn’t parallelize it.

Now, over the network, you’ll need more samples due to the noise. Hubert can probably guesstimate how many more samples, but let’s say you’d need 100 times of what you’d need locally. You can assume the attacker isn’t halfway around the world, but a few hops next to you in some Amazon or Google cloud datacenter.

That would still mean the attacker would need 100 days to decrypt a single cipher text. However, this entire attack can be run in parallel. You don’t need to always talk to the same server. If somebody were running a distributed service that does RSA decryption with an observable timing channel across 100 nodes, we’re back at 24 hours.

Sending this many requests might be detected as abuse, so an attacker would likely have to adequately reduce the number of queries to hide them in the noise.

Overall, definitely not something somebody would do for all captured cipher texts, but for a high-value target in some bigger cloud deployment, it certainly sounds a lot more doable.

--
Clemens Lang
RHEL Crypto Team
Red Hat

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gcrypt-devel

Re: Side-channel vulnerability in libgcrypt - the Marvin Attack [ In reply to ]

gcrypt-devel at gnupg

Mar 19, 2024, 6:22 AM

Post #10 of 16 (160 views)

On Monday, 18 March 2024 13:41:42 CET, Clemens Lang wrote:
> Hi,
>
>> On 15. Mar 2024, at 07:42, NIIBE Yutaka <gniibe@fsij.org> wrote:
>>
>> My original question was... about quantitative evaluation and
>> possibility in real cases. In other words, my interest is: if there are
>> any existing applications/services/products/etc., and the degree of how
>> likely are these problems and how much effort/time is needed to recover
>> RSA private key, in such a possible scenario.
>
> Just to give you a rough ball park of some numbers:
>
> I looked at the same vulnerability in Apple’s CoreCrypto
> library. CVE-2024-23218 was assigned for that.
>
> When directly measuring the affected decrypt operation,
> decryption of a cipher text without using the private key just
> by making calls to the timing oracle needed about 24 hours. I
> didn’t bother attempting to optimize this, and didn’t
> parallelize it.
>
> Now, over the network, you’ll need more samples due to the
> noise. Hubert can probably guesstimate how many more samples,
> but let’s say you’d need 100 times of what you’d need locally.
> You can assume the attacker isn’t halfway around the world, but
> a few hops next to you in some Amazon or Google cloud
> datacenter.

For same-switch attack vs loopback attack it's a factor of 4.
For more remote connections there's too much variables to provide
a good estimate.

--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky?ova 115, 612 00, Brno, Czech Republic

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gcrypt-devel

Re: Side-channel vulnerability in libgcrypt - the Marvin Attack [ In reply to ]

gcrypt-devel at gnupg

Mar 19, 2024, 6:28 AM

Post #11 of 16 (160 views)

On Saturday, 16 March 2024 00:43:58 CET, NIIBE Yutaka wrote:
> Hubert Kario <hkario@redhat.com> wrote:
>> Actually no. If the time slots are consistent (say, the USB device returns
>> the message only on the second, on the dot), then the attacker
>> can tune the
>> time when it _starts_ the operation so that it end exactly at the second.
>> Then quicker operations will be returned earlier, while slower will be
>> returned a second later.
>
> This is not the communication of USB bus. The request from host is also
> time-slotted. Your claim above would be only valid if the attacker can
> start the request of the crypto operation from another channel where
> timing can be accurately controlled, and the responce is on USB bus (for
> some reason).

If the communication is like that in both directions, then yes, it's more
problematic. But as long as there is a variability in the responses, the
statistical tests I'm using will still work.

Like, if the operation normally takes between 1.8 and 2.2 s, and the
communication can happen every 0.1 s, then the attack is still possible.

It only won't be possible if the inherent variability is completely hidden
by the quantization, like if in the above example the communication could
happen only every 10 s.

--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky?ova 115, 612 00, Brno, Czech Republic

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gcrypt-devel

Re: Side-channel vulnerability in libgcrypt - the Marvin Attack [ In reply to ]

gcrypt-devel at gnupg

Mar 19, 2024, 6:44 PM

Post #12 of 16 (153 views)

Hubert Kario via Gcrypt-devel wrote:
> On Saturday, 16 March 2024 00:43:58 CET, NIIBE Yutaka wrote:
>> Hubert Kario <hkario@redhat.com> wrote:
>>> Actually no. If the time slots are consistent (say, the USB device
>>> returns
>>> the message only on the second, on the dot), then the attacker can
>>> tune the
>>> time when it _starts_ the operation so that it end exactly at the
>>> second.
>>> Then quicker operations will be returned earlier, while slower will be
>>> returned a second later.
>>
>> This is not the communication of USB bus. The request from host is also
>> time-slotted. Your claim above would be only valid if the attacker can
>> start the request of the crypto operation from another channel where
>> timing can be accurately controlled, and the responce is on USB bus (for
>> some reason).
>
> If the communication is like that in both directions, then yes, it's more
> problematic. But as long as there is a variability in the responses, the
> statistical tests I'm using will still work.
>
> Like, if the operation normally takes between 1.8 and 2.2 s, and the
> communication can happen every 0.1 s, then the attack is still possible.
>
> It only won't be possible if the inherent variability is completely
> hidden
> by the quantization, like if in the above example the communication could
> happen only every 10 s.

The method to harden a USB device against this type of attack is to work
out the worst-case computation time, and always hold the response until
that time (measured in USB time slots) has elapsed. To use numbers from
your example, the device performs the operation, completing it in 18 to
22 time slots, but holds the response until 24 time slots have elapsed
from the request.

This of course requires actually knowing how your program works and its
worst-case running time, which sadly is probably rare in modern
commercial programming.

The device also must guard against a malicious host by having its own
clock (which is needed for its processor and USB interface anyway) and
shutting down if the time slots it sees on the bus do not align with the
USB spec. (If I remember correctly, the USB spec requires each time
slot to be some number of milliseconds, but the USB host determines the
precise timing.) Otherwise, a non-standard malicious host could "bend"
the slot timing enough that the fixed response delay is not always
sufficient for the operation to complete.

-- Jacob

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gcrypt-devel

Re: Side-channel vulnerability in libgcrypt - the Marvin Attack [ In reply to ]

gcrypt-devel at gnupg

Mar 20, 2024, 6:18 AM

Post #13 of 16 (152 views)

On Wednesday, 20 March 2024 02:44:51 CET, Jacob Bachmeyer wrote:
> Hubert Kario via Gcrypt-devel wrote:
>> On Saturday, 16 March 2024 00:43:58 CET, NIIBE Yutaka wrote: ...
>
> The method to harden a USB device against this type of attack
> is to work out the worst-case computation time, and always hold
> the response until that time (measured in USB time slots) has
> elapsed. To use numbers from your example, the device performs
> the operation, completing it in 18 to 22 time slots, but holds
> the response until 24 time slots have elapsed from the request.
>
> This of course requires actually knowing how your program works
> and its worst-case running time, which sadly is probably rare in
> modern commercial programming.
>
> The device also must guard against a malicious host by having
> its own clock (which is needed for its processor and USB
> interface anyway) and shutting down if the time slots it sees on
> the bus do not align with the USB spec. (If I remember
> correctly, the USB spec requires each time slot to be some
> number of milliseconds, but the USB host determines the precise
> timing.) Otherwise, a non-standard malicious host could "bend"
> the slot timing enough that the fixed response delay is not
> always sufficient for the operation to complete.

IIUC, there are ways to do polling more often... some gaming mice advertise
that as a feature.

But, yes, if there is no differentiation in the reply times, or they don't
depend on the secret data, then you will fix the timing side-channel.
It should be noted that this will protect only against timing
side-channel.

There are other side-channels, like sound:
https://arstechnica.com/information-technology/2013/12/new-attack-steals-e-mail-decryption-keys-by-capturing-computer-sounds/
or power related (using remote CCTV cameras):
https://arstechnica.com/information-technology/2023/06/hackers-can-steal-cryptographic-keys-by-video-recording-connected-power-leds-60-feet-away/

Fixing it so that the timing of the actual operation is actually
independent
of secret data is a first step in fixing the power side channels.

--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky?ova 115, 612 00, Brno, Czech Republic

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gcrypt-devel

Re: Side-channel vulnerability in libgcrypt - the Marvin Attack [ In reply to ]

Mar 21, 2024, 4:51 PM

Post #14 of 16 (145 views)

Hello,

Jacob Bachmeyer <jcb62281@gmail.com> wrote:
> Otherwise, a non-standard malicious host could "bend" the slot timing
> enough that the fixed response delay is not always sufficient for the
> operation to complete.

True. Thank you for showing this possibility. I didn't consider this
point.

Well, in general, I suggest not keeping a USB token inserted into a host.

There are possibilities (in theory, or in history) that a decryption
service by a USB token might be providing a decryption oracle to an
attacker by some channel(s).

When a user has a practice of only powering the device when needed,
bandwidth to an attacker could be small, hopefully small enough. Slower
service is better too, for smaller bandwidth.

It is a bit off-topic (from the original report). Sorry, It was me who
addressed USB communication.

And... yes, it's true that it's hard for programming to estimate
worst-case running time, it's also hard to guarantee constant-time
running time, in a given situation of programming environment and
hardware architecture.

For me, the question is how we can live with that.
--

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gcrypt-devel

Re: Side-channel vulnerability in libgcrypt - the Marvin Attack [ In reply to ]

gcrypt-devel at gnupg

Mar 21, 2024, 6:40 PM

Post #15 of 16 (145 views)

NIIBE Yutaka wrote:
> Hello,
>
> Jacob Bachmeyer <jcb62281@gmail.com> wrote:
>
>> Otherwise, a non-standard malicious host could "bend" the slot timing
>> enough that the fixed response delay is not always sufficient for the
>> operation to complete.
>>
>
> True. Thank you for showing this possibility. I didn't consider this
> point.
>

To be fair, when I said "non-standard", I meant a USB host implemented
either using a programmable logic device or by bit-banging on MCU GPIO
pins. I do not believe that a PC's USB host controller, for example,
will allow that. I would expect standard hardware USB hosts to enforce
spec-compliant bus timing beyond software control. Therefore, the token
should shut down or possibly even wipe itself if it detects such
incorrect timing.

> Well, in general, I suggest not keeping a USB token inserted into a host.
>
> There are possibilities (in theory, or in history) that a decryption
> service by a USB token might be providing a decryption oracle to an
> attacker by some channel(s).
>
> When a user has a practice of only powering the device when needed,
> bandwidth to an attacker could be small, hopefully small enough. Slower
> service is better too, for smaller bandwidth.
>

Leaving the token connected to the host and active (unlocked) raises a
different hazard: the token would then be available for malware on the
host to abuse at will. This largely defeats the purpose of using a
token in the first place, as the security benefits of tokens center
around preserving the security of the key even if the host is compromised.

Obvious decryption oracle: just ask the token to decrypt the
ciphertext. If it is connected and unlocked, it will. Oops.

> It is a bit off-topic (from the original report). Sorry, It was me who
> addressed USB communication.
>
> And... yes, it's true that it's hard for programming to estimate
> worst-case running time, it's also hard to guarantee constant-time
> running time, in a given situation of programming environment and
> hardware architecture.
>

The basic method is to do both sides of every branch and select the
result with the equivalent of a multiplexer. This obviously does not
work for loop-test branches, since loops must eventually terminate, and
still requires care at higher-levels that the set (and possibly
sequence) of operations performed is invariant with respect to secret
data, but it is possible as I understand.

This may also require avoiding the use of sufficiently-advanced
processors, if any exist that can detect that the result of a
speculative execution chain will not be used and elide the chain. This
could also be a good application for tokens containing simpler
processors intended for security over performance, if main processors
get advanced enough to do that.

-- Jacob

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gcrypt-devel

Re: Side-channel vulnerability in libgcrypt - the Marvin Attack [ In reply to ]

gcrypt-devel at gnupg

Mar 22, 2024, 5:24 AM

Post #16 of 16 (143 views)

On Friday, 22 March 2024 00:51:06 CET, NIIBE Yutaka wrote:
> Hello,
>
> And... yes, it's true that it's hard for programming to estimate
> worst-case running time, it's also hard to guarantee constant-time
> running time, in a given situation of programming environment and
> hardware architecture.

OpenSSL, BoringSSL (they have different code for RSA than OpenSSL now),
Go, NSS, GnuTLS, Apple corecrypto, and WolfSSL were all able to do this
operation in constant time in software, and those are only the ones
that I have directly seen the evidence that the fixes were successful,
so while it may not be simple, it's clearly not impossible.
--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky?ova 115, 612 00, Brno, Czech Republic

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gcrypt-devel