Falscher Ansatz

[/mecki78]

Wie die Seite erklärt, auf die Golem selber verlinkt hat im Artikel

https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/resources/data-operand-independent-timing-instructions.html

dibt es Anweisungen, die von Haus aus immer gleich lange brauchen, egal mit welchen Daten sie arbeiten und es gibt eben Anweisungen, wo das nicht der Fall ist. Für letztere kann man dann einschalten, dass sie eben auch gleich lange brauchen, aber das bremst eben die CPU als ganzes runter und zwar auch da, wo es nicht um Sicherheit geht, und so feingranular kann man das nicht an- und abschalten, denn alleine das umschalten kostet Zeit.

Statt also das zu tun schlägt Intel vor, man solle doch bei Sicherheitsrelevanten Code einfach nur die Anweisungen nutzen, die immer gleich lange brauchen, weil dann tritt das Problem nicht auf und deswegen bieten sie die Liste unter obigen Link an, damit man weiß, welche Anweisungen das sind.

Zitat: "The table below lists instructions that have data-independent timing."
("In der folgenden Tabelle sind Anweisungen mit datenunabhängigem Timing aufgeführt.". datenunabhängig heißt: Brauchen immer gleich lange, egal wie die Daten aussehen)

Denn nutzt sicherheitsrelevanter Code ausschließlich diese Anweisungen, dann muss man eben ein ansonsten sinnvolles Feature gar nicht erst ausschalten, weil der Code dann von dem Problem gar nicht betroffen ist und trotzdem jederzeit an anderer Stelle, wo es nicht um Sicherheit geht, von der höheren Geschwindigkeit der anderen Anweisungen profitieren kann.

Und neu ist daran BTW gar nichts. Integerdivision z.B. hat schon beim 8086 unterschiedlich lange gedauert, je nachdem mit welchen Zahlen dort gerechnet wurde. Das war bei vielen Instruktionen schon immer so. Es sind lediglich im laufe der Zeit weitere hinzugekommen, wo das heute auch der Fall ist und früher eben nicht der Fall war, weil man super lange Pipelines hat und daher Shortcuts nutzt (manchmal liegt das Ergebnis schon nach einem Teil der Rechenschritte vor, dann spart man sich natürlich den Rest).

/Mecki

[MarcusK]

/mecki78 schrieb:
--------------------------------------------------------------------------------
> Denn nutzt sicherheitsrelevanter Code ausschließlich diese Anweisungen,
> dann muss man eben ein ansonsten sinnvolles Feature gar nicht erst
> ausschalten, weil der Code dann von dem Problem gar nicht betroffen ist und
> trotzdem jederzeit an anderer Stelle, wo es nicht um Sicherheit geht, von
> der höheren Geschwindigkeit der anderen Anweisungen profitieren kann.


das wird bei einer lib aber gar nicht so einfach. Wenn ich mit openssl eine Datei verschlüssele, dann soll es so schnell wie möglich gehen. Sicherheit spielt da keine Rolle.
Wenn ich mit openssl einen Webserver betreibe, ist es schon wichter.

[abcde]

Naja, wenn wirklich der Entwickler verschiedene APIs zur Verfügung hat, dann nutzt man dafür Flags.

[/mecki78]

MarcusK schrieb:
--------------------------------------------------------------------------------
> das wird bei einer lib aber gar nicht so einfach. Wenn ich mit openssl eine
> Datei verschlüssele, dann soll es so schnell wie möglich gehen. Sicherheit
> spielt da keine Rolle.
> Wenn ich mit openssl einen Webserver betreibe, ist es schon wichter.

Dann biete man halt einfach die Verschlüsselung zweimal an, einmal schnell und einmal sicher und nimmt standardmäßig immer sicher. Wer dann entscheidet, dass er sicher nicht braucht und lieber schnell will, der kann das einstellen, auf eigene Gefahr. Da man ja CPU Code selten bis nie von Hand schreibt, das macht ja weitgehend ein Compiler, muss man nicht mal neuen Code dafür schreiben, sondern der Compiler braucht ein Flag, dass er nur CPU Anweisungen nutzen darf, die immer gleich lange dauern und dann baut man den gleichen Code einfach zweimal, einmal mit Flag und einmal ohne und setzt ein Preprozessor Makro, damit die Symbole der beiden Versionen am Ende unterschiedlich heißen (z.B. einmal AES_encrypt() und einmal AES_encrypt_fast() und zur Laufzeit entscheidet die Implementierung dann, welches davon sie aufruft). Wobei AES hier ein schlechtes Beispiel ist, denn das können x86 CPUs heute in Hardware machen und deren Hardwareimplemtierung ist natürlich immun gegen Timingangriffe (Intel ist schließlich nicht ganz doof).

/Mecki

[xUser]

/mecki78 schrieb:
--------------------------------------------------------------------------------
> Wobei AES hier ein schlechtes Beispiel ist,
> denn das können x86 CPUs heute in Hardware machen und deren
> Hardwareimplemtierung ist natürlich immun gegen Timingangriffe (Intel ist
> schließlich nicht ganz doof).

Doch AES Instructionen sind laut dem ursprünglichen Bericht auch betroffen. Ergo Intel ist doof (oder die NSA hat ein Feature platziert).
https://www.openwall.com/lists/oss-security/2023/01/25/3