Dokumentation über die Sicherheit gegen Oracle-Angriffe.

[root_s2yse8vt]

Up

0

Down

::

Ich bin mir zu 90% sicher, dass ich die Antwort weiß, aber ich dachte, ich frage die Mods nach einer offiziellen Antwort oder einem Verweis auf die Dokumentation.

Generell verstehe ich unter einem Orakel-Angriff etwas, bei dem der Angreifer alle Eingaben und alle Ausgaben sehen kann, aber blind für die privaten Schlüssel ist. Der Angriff besteht darin, viele Eingaben und Ausgaben zu analysieren, um den verborgenen Schlüssel für die kryptografische Operation zu ermitteln. Mir geht es nicht wirklich um Auffüllorakel, sondern um einen allgemeineren Zweck. Wenn ein Angreifer alles sehen kann, was in den Trezor hineingeht und alles, was herauskommt, und zwar über einen langen Zeitraum hinweg, besteht dann überhaupt ein Risiko?

Ich DENKE, dass das Gerät vor Orakelangriffen sicher ist. Die meisten Eingaben werden mit Geheimnissen verschlüsselt, bevor sie in die kryptografischen Funktionen eingespeist werden, so dass es für einen Angreifer unmöglich ist, die wahren Eingaben zu kennen.

Zum Beispiel hat `CipherKeyValue`, wie ich es verstehe, den folgenden Arbeitsablauf:

“`
INPUT: {Schlüssel , Wert}
-> hmac(in.key, wallet.priv) ==> { tmp.key, tmp.iv }
-> aes(tmp.key, tmp.iv, in.value) ==> OUTPUT: { value }
“`

Da die Eingabe mit dem privaten Schlüssel in einem hmac-Hash gemischt wird, ist der Angreifer eigentlich blind für die Eingaben der AES-Funktion. Ich vermute also, dass diese Abstraktion ausreicht, um zu verhindern, dass die “wallet.priv” für jede Art von Orakelangriff anfällig ist. IMHO.

Was denken Sie über die anderen Funktionen der Wallet? U2F, FIDO2, ECDSA? Irgendetwas anderes?

[matejcik]

Up

0

Down

::

What you’re talking about is actually called a _known plaintext attack_, and the answer is something like, (1) this is a well known and well researched class of attacks, (2) if a cipher was practically vulnerable to KPA, we would consider it broken, and (3) there is no known-broken cryptography on Trezor.

An _oracle attack_ is something else. It is interactive and relies on having access to a device that tells you “yes/no” to some question that you otherwise can’t answer, e.g., “does this message decrypt with a valid padding?”

Even non-broken cryptography can be vulnerable to oracle attacks, because the oracle could be just _telling_ you the answer one bit at a time.

The answer here is more along the lines of (1) there is no general “security-against-oracle-attacks” property because an oracle can be anything, very often some sort of side channel that nobody notices until they do. And (2) if you do figure out an oracle attack against Trezor, please please contact [Trezor security](https://github.com/trezor/trezor-firmware/security/policy) so that the problem can be fixed ASAP!

[Autor]

Beiträge