2017-05-23 4 views
4

Ich frage mich, ob die Util. * Funktionen in einer JavaCard normalerweise Seitenkanalresistent sind.
Existieren einige JavaCards, die Seitenkanalresistente Util. * Funktionen haben?
Ich schaute in mehreren öffentlichen JavaCard Security Targets. Aber keiner hat Sicherheitsansprüche für die aufgeführten Util. * -Funktionen.Sind Util. * Funktionen auf JavaCard Seitenkanal resistent?

In Java selbst Seitenkanalwiderstand ohne die Hilfe von nativem Code zu erreichen, scheint hart, wenn nicht unmöglich. Daher sollte eine JavaCard Seitenkanalresistente Util. * Funktionen haben, oder?

Antwort

3

Nein, ich glaube nicht, dass ich so etwas gesehen habe. Aber es scheint wenig Bedürfnis zu sein:

  • arrayCopy(byte[] src, short srcOff, byte[] dest, short destOff, short length)
  • arrayCopyNonAtomic(byte[] src, short srcOff, byte[] dest, short destOff, short length)
  • arrayFill(byte[] bArray, short bOff, short bLen, byte bValue)
  • arrayFillNonAtomic(byte[] bArray, short bOff, short bLen, byte bValue)

Kopieren und füllen Operationen im allgemeinen nicht mit den Bits innerhalb der Arrays etwas tun. Sie kopieren oder ersetzen die Bytes, aber sie tun das unabhängig von dem Inhalt der Bytes. Nur bei EEPROM oder Flashlevel kann es zu Undichtigkeiten kommen - und dies wird wahrscheinlich auf der Java-Karten-Ebene nicht gelöst.

Warnung: falsches Kopieren von Daten sollte immer noch vermieden werden, insbesondere beim Schreiben in den permanenten Speicher können Informationen verloren gehen.


  • getShort(byte[] bArray, short bOff)
  • makeShort(byte b1, byte b2)
  • setShort(byte[] bArray, short bOff, short sValue)

Nun ist diese Funktionen im Grunde betrachten nicht den Inhalt des Bytes entweder. Sie kopieren oder verschieben einfach die Werte des Speichers in die richtige Position, wiederum unabhängig vom Inhalt.

Für die Kopier- und die Short-Handling-Funktionen könnte man theoretisch eine Funktion gegen Seitenkanalangriffe machen, aber generell sollte man sicher sein: sie unsicherer zu machen wäre tatsächlich schwieriger als sie sicher zu machen.


  • arrayCompare(byte[] src, short srcOff, byte[] dest, short destOff, short length)

Nun wäre dies eine spezifische Programmierung erfordern, Seitenkanalangriffe zu vermeiden.

Derzeit scheint keine Seite Kanal-sichere Version von arrayCompare. Das ist irgendwie ärgerlich, wie in 3.0.5 es kann bieten Funktionalität zum Sichern des Ergebnisses des Arrays vergleichen mit SensitiveResult.

Dies ist etwas, das sollte in der Spezifikation geändert werden, aber für jetzt können Sie stecken bleiben mit der Programmierung selbst.

Natürlich bestimmte Anbieter diesen Aufruf sichern können; es würde Sinn machen. Jedoch auf einer bestimmten Lieferanten Funktion unter Berufung macht Ihr Applet weniger tragbar über Implementierungen.


Ihre Plattform Dokumentation prüfen, ob und wie der Datenzugriff anfällig für Angriffe und plattformspezifische mitigations.

+0

Ich denke nur daran Timing-Attacken hatte. Was ist mit Stromverlust? Hier kann beim Kopieren die Hammingdistanz verloren gehen. – Cryptostasis

+0

Sorry für Missverständnisse. Ich bin kein Muttersprachler und deshalb verstehe ich nicht ganz den Satz „... Sie würden nicht an irgendwelchen, aber die grundlegenden Ebenen der Lage sein, zu korrigieren“. Was meinst du mit "grundlegendsten Ebenen"? – Cryptostasis

+0

Nein, das war nicht so klar: Ich meinte, Sie würden entweder Hardware- oder HAL-Level-Unterstützung benötigen, um sicherzustellen, dass Informationen auf dieser Ebene nicht durchgelassen werden. –

Verwandte Themen