www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik I2C schützen


Autor: Bert 0. (maschinist)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

in einer sicherheitsrelevanten Baugruppe überträgt ein I2C-Bus einen 
kryptografischen Schlüssel von einem Schlüsselspeicher zur MCU.

Der Schlüssel muß gegen unauthorisiertes Abhören geschützt werden.

Beide beteiligten Bauteile sind im BGA-Gehäuse, d.h. die Bussignale sind 
innerhalb der PCB verdeckt führbar und erst einmal nicht angreifbar.
In der PCB wird der Bus nämlich auf einer Mittellage geführt und durch 
umliegende Meshlagen geschützt.

Allerdings verlangt ein I2C Bus ja externe Pullup-Rs, an denen ja dann 
auch die Bussignale anliegen und somit abgreifbar sind. Diese Rs lassen 
sich schwerlich "innerhalb" einer PCB anordnen, sondern verlangen ein 
Durchkontaktieren des betroffenens Signals bis an die Oberfläche.

Welche Möglichkeiten des Schutzes wären hier denkbar, um den I2C dennoch 
gegen Abhören durch Anzapfen zu schützen?


Gruß...Bert

Autor: TSE (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ist es möglich in den Bauteilen interne Pullups zu aktivieren?
liegen dann zwar nicht genau in der I2C norm aber sollte auch gehen

Autor: Bert 0. (maschinist)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm,

das würde bedeuten, ich implementiere auf der MCU einen Soft-I2C an zwei 
gewöhnlichen Portpins und aktiviere dazu die eingebauten Pullups.

Würde sowas funktionieren, wenn ich nur einen Slave ansprechen müßte?


Gruß...Bert

Autor: Lukas K. (carrotindustries)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Google mal nach "active multilayer", mit dieser Technik können Bauteile 
in Multilayer-Innenlagen eingebaut werden. Vollkommen sicher wird das 
auch dadurch nicht, denn man kann mit genügend Aufwand den I2C Bus 
bestimmt auch kapazitiv oder induktiv belauschen.

Autor: Carsten Wille (eagle38106)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann braucht man auch Blind Vias, damit man nicht von der Unterseite 
doch noch die Signale abgereifen kann.

Aber hat die MCU nicht internen FLASH/EEPROM Speicher, in dem man den 
Schlüssel geschützter ablegen kann?

Wenn ich mal ketzerisch sein darf: I²C zum Übertragen von 
kryptografischen Schlüsseln zeugt nicht gerade von einer guten 
Design-Idee.

Autor: ElCattivo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wenn ich mal ketzerisch sein darf: I²C zum Übertragen von
> kryptografischen Schlüsseln zeugt nicht gerade von einer guten
> Design-Idee.

Das würde ich so nicht sagen.
Eher:
Das unverschlüsselte Übertragen eines geheimen Schlüssels ist keine gute 
Idee.
Wo wir grad beim Thema sind: Ein beliebter Fehler ist übrigens auch 
immer schön symmetrisch zu verschlüsseln und keinen Salt zu verwenden.

Autor: Nonsense (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

die einzig sinnvolle Lösung ist, den Schlüssel verschlüsselt zu 
übertragen (Public-Key-Verschlüsselung) oder aber ihn bei beiden Seiten 
z.B. in internem Flash zu speichern oder sogar hartverdrahtet (wenn es 
ein selbst entwickelter Chip ist) zu hinterlegen.
Alles andere fällt in die Kategorie "security by obscurity". Auch das 
verdecken von Bauteilen o.ä. hilft hier wenig. Es ist heutzutage für 
Angreifer (mit entsprechendem Budget und Kenntnissen) ohne Weiteres 
möglich sogar ICs zu öffnen und anhand des Aufbaus Rückschlüsse auf 
Funktion usw. zu ziehen. Daher kann man davon ausgehen, dass es 
mindestens ebenso problemlos möglich ist gezielt einzelne Platinenlayer 
oder in ihnen versteckte Bauteile freizulegen. Und selbst wenn man den 
Schlüsse derart hinterlegt kann ein Angreifer ihn womöglich dennoch 
herausfinden, denn je nachdem wie lang er ist und was mit ihm 
veranstaltet wird wirkt sich die auf den Stromverbrauch der ICs aus, so 
dass sich durch dessen Messung Rückschlüsse auf die Beschaffenheit des 
Schlüssels ziehen lassen.

Ich muss leider sagen, dass das Thema alles andere als trivial ist, in 
sicherheitskritischen Umgebungen sollte sowas von Anfang an 
berücksichtigt werden.

Autor: Uwe S. (de0508)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich möchte noch ein Verfahren für diesem Zweck aus meinem Studium 
beitragen:

Diffie-Hellman-Schlüsselaustausch

Hier noch ein Buch vom meinem Professor Beutelspacher:

http://books.google.com/books?id=NP5RhYcDC6sC&pg=P...

Autor: Lattice User (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bert Braun schrieb:
> das würde bedeuten, ich implementiere auf der MCU einen Soft-I2C an zwei
> gewöhnlichen Portpins und aktiviere dazu die eingebauten Pullups.
>
> Würde sowas funktionieren, wenn ich nur einen Slave ansprechen müßte?

Interne Pullups sind typischerweise sehr hochohmig, das macht den I2C 
Bus langsam und fehleranfällig.

Wenn der Slave nicht die Clock auf Low zieht (um den Master zu bremsen) 
kann es trotzdem machen. Clock wird dann vom Master aktiv high und low 
angesteuert. Die Datenpins auf beiden Seiten werden an den passenden 
Stellen im Telegram vom Master bzw Slave getrieben, der andere geht 
jeweils auf tristate. Der interne Pullup dient dann nur dazu die Leitung 
oben zu halten wenn gerade keiner von beiden treibt. Geht natürlich nur 
wenn man beide Seiten implementiert (da kann man sich natürlich fragen 
warum dann überhaupt I2C)

Alternative sind Widerstände in 01005 Bauform zwischen die Balls des 
BGAs. Es soll Bestücker geben die das können.

Aber nicht vergessen:

Carsten Wille schrieb:
> Dann braucht man auch Blind Vias, damit man nicht von der Unterseite
> doch noch die Signale abgreifen kann.

Autor: Jan S. (jan_s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bert Braun schrieb:
> in einer sicherheitsrelevanten Baugruppe überträgt ein I2C-Bus einen
> kryptografischen Schlüssel von einem Schlüsselspeicher zur MCU.

Egal was du mit deiner Platine und dem I2C Bus anstellst, dein Schlüssel 
ist bereits dadurch hinfällig.

Auch ein BGA IC bekommt man wieder von der Platine, und dadurch machst 
du es selbst jedem Hobby Angreifer so richtig schön einfach.

Denke lieber ein bisschen mehr über ein sicheres Systemdesign nach als 
über Alibi Hardware-Lösungen.

Autor: ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wozu gibt es eigentlich security eeproms? z.B. von Atmel?

Autor: Jan S. (jan_s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich schrieb:
> Wozu gibt es eigentlich security eeproms? z.B. von Atmel?

Würde ich jetzt auch nicht als der Weisheit letzten Schluss betrachten.
Die einfachere Frage ist, warum packt man den Schlüssel nicht in die 
MCU?
Platzmangel?

Autor: Daniel Steffen (derdaniel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn du es trotzdem unbedingt in Software machen willst (ma abgesehen 
von den schon erwähnten Problemen):

Vergieß den ganzen Spaß und mach feine Sicherungsdrähte in das Harz die 
beim entfernen reißen usw...
Alles danach Folgende is der Fantasie überlassen, nur kleine 
Sprengladungen sind meißtens bisi oversized. ;-)

Autor: Jan S. (jan_s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schwarzes/undurchsichtiges Harz sei noch zu empfehlen. :-D

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.