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
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
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
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.
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.
> 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.
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.
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=PA58&lpg=PA58&dq=diffie+hellman+schl%C3%BCsselaustausch+beutelspacher&source=bl&ots=O8_xmBHsi_&sig=-I2vn-3PHDRxy8Arx1BQ_k4baEE&hl=de&ei=DgFCTY-vOqmAhAfZyNyEAg&sa=X&oi=book_result&ct=result&resnum=1&ved=0CBYQ6AEwAA#v=onepage&q&f=false
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.
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.
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?
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. ;-)
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.