Liebe Forum-Gemeinde Ich habe von meinem Arbeitgeber den Auftrag bekommen, ein Konzept auszuarbeiten um unsere Hardware vor Reverse Engineering zu schützen sodass es einem Drittanbieter nicht möglich ist Ersatzteile für unsere Kunden zu produzieren. Ich habe mich mit dem Thema schon etwas auseinandergesetzt, aber mir fehlt die Erfahrung um zu beurteilen, welche Lösung am geeignetsten wäre oder in welche Fallen man tappen könnte. Deshalb wende ich mich an euch, vielleicht hat sich der Eine oder Andere auch schon mit dem Thema beschäftigt und kann mir ein paar Hinweise liefern. Um was geht es konkret: Wir arbeiten mit einer Hardware, nennen wir es Master-HW, die wir inhouse selbst entwickelt haben über die verschiedene Peripherie-Geräte wie Motoren, Encoder, Sensoren usw. angeschlossen werden können und die mit dem Hauptrechner kommuniziert. Damit die genannte Peripherie an den Master-HW angeschlossen werden kann, wird sie mit einer zusätzlichen Slave-HW erweitert, die alle Anschlüsse zur Verfügung stellt. Die Slave-HW kann unterschiedlich aussehen, das hängt davon ab wo auf der Maschine die Master-HW eingesetzt wird. Die Master-HW bleibt also immer gleich, von der Slave-HW haben wir aber unterschiedliche Versionen, die wir je nach Funktionalität der Master-HW einsetzten (siehe Grafik 1). Auf der Master-HW arbeitet ein Altera Cyclone IV. Da wir die Master-HW aber nun überarbeiten, kann dies in Zukunft auch durchaus ein anderes FPGA sein. Nun möchten wir erreichen, dass die Master-HW die Slave-HW authentifizieren kann, also feststellt dass dies ein Bauteil aus unserem Hause ist. Um dies zu erreichen bauen wir auf beiden, also Master-HW und Slave-HW, ein Authentifizierungs-Device ein das mittels SHA oder AES eine authentifizierung vornehmen kann. Nun stellen sich mir aber ein paar grundsätzliche Fragen: - Wie sicher wäre ein Secret Key der im FPGA hinterlegt ist? Denn die Implementation des SHA oder AES im FPGA wäre die sauberste Lösung. So könnte man die Berechnung der Response innerhalb des FPGA vornehmen und wäre nicht von einem externen Bauteil abhängig. - Alternativ könnten sowohl auf der Master-HW als auch auf der Slave-HW externe Bauteile wie z.B. der ATSHA204A von Atmel eingesetzt werden, die die Berechnung und Speicherung des Secret Keys übernehmen. Allerdings müsste ein Drittanbieter dann bloss beide Bauteile austauschen die mit seinem eigenen Secret Key versehen sind und der Kopierschutz wäre hinfällig. Gäbe es hierfür eine bessere Lösung? - Gibt es von Altera speziell gesicherte FPGA's wo der Secret Key in einem sicheren Bereich hinterlegt ist, wie man dies von Mikrokontrollern auch kennt? - Gibt es grundsätzlich ein gutes Konzept wie man eine solche authentifizierung sicher vornehmen kann? Ich hoffe ich konnte euch mein Anliegen einigermassen verständlich darlegen, ansonsten bitte gerne nachfragen.
Angehängte Dateien:
-
Grafik_1.png
13 KB
Muss der Secret Key nicht wenn schon in den Slave, und der Master
überprüft mit dem public Key die Authentizität? Wenn der Slave einen
private Key + Zertifikat bekommt, kann der Master beliebig viele Slaves
akzeptieren. Wenn der Master außerdem am Internet hängt ("wichtige
Sicherheits Updates"), kannst du dem kompromittierte Zertifikate
mitteilen, sodass "kopierte" Slaves nutzlos werden. Der root CA Key
verbleibt natürlich in deiner Firma.
Das Thema ist moeglicherweise etwas komplexer. Der Key darf natuerlich nicht ausgetauscht werden. Und irgendwas in Richtung AES ist voellig uebertrieben. AES ist fuer Blockchiffre, was hier nicht zutrifft. Es geht in der richtung von der Eine schickt etwas an den anderen und bekommt etwas zurueck, dann sendet der andere Etwas und bekommt etwas zurueck. aus den antworten sollte beide herausfinden koennen ob der Andere, derjenige ist, den man erwartet. Allenfalls muss eben noch eine Runde Austausch hinzugefuegt werden. Ein FPGA mit internem EEPROM kann Daten speichern, die ausschliesslich RAM basieren nicht. Die Null Ahnung des Posters sind etwas mager. Da fehlt ein Stueck.
:
Bearbeitet durch User
@Dr. Sommer: Ich muss vielleicht noch erwähnen, dass die Master-HW nicht mit dem Internet verbunden ist. Eine Überprüfung mittels eines Servers ist also keine Option. @Oh Doch: Du hast natürlich recht, der Key darf auf keinen Fall ausgetauscht werden, ansonsten funktioniert die Authentifizierung mit "alter" Hardware nicht mehr. AES kann durchaus für eine Authentifizierung benutzt werden. Das Prinzip ist das selbe wie auch bei SHA, mittels "challenge and response". Und was meinst du mit: "Die Null Ahnung des Posters sind etwas mager. Da fehlt ein Stueck."? Was fehlt dir denn?
Die ganze Authentifizierungsgeschichte hat einen Haken: Die einzige wirklich sichere Möglichkeit, die mir einfällt ist, die gesamte Funktionalität in einem secure Microcontroller ablaufen zu lassen. Das ist der klassische Closed System Ansatz, wie er z.B. bei Kredit- oder SIM Karten verwendet wird. Da Du aber bei deinem Haupt-Design von einem FPGA sprichst orakel ich mal, das die Rechenkapazität eines secure Microcontrolles nicht reichen wird und Du daher auch kein Closed System bauen kannst. Also wird am Ende des Tages wird irgendwo die Antwort, ob die Authentifizierung erfolgreich war oder nicht als elektrisches Signal auftauchen und z.B. einen Teil der Schaltung aktivieren. Dort kann man als Angreifer immer ansetzten.
Nils P. schrieb: > Also wird am Ende des Tages wird irgendwo die Antwort, ob die > Authentifizierung erfolgreich war oder nicht als elektrisches Signal > auftauchen Wird wohl eher so sein, dass der Master einen nicht authentifizierten Slave nicht bedient.
Nils P. schrieb: > Die ganze Authentifizierungsgeschichte hat einen Haken: > > Die einzige wirklich sichere Möglichkeit, die mir einfällt ist, die > gesamte Funktionalität in einem secure Microcontroller ablaufen zu > lassen. Das ist der klassische Closed System Ansatz, wie er z.B. bei > Kredit- oder SIM Karten verwendet wird. > > Da Du aber bei deinem Haupt-Design von einem FPGA sprichst orakel ich > mal, das die Rechenkapazität eines secure Microcontrolles nicht reichen > wird und Du daher auch kein Closed System bauen kannst. > > Also wird am Ende des Tages wird irgendwo die Antwort, ob die > Authentifizierung erfolgreich war oder nicht als elektrisches Signal > auftauchen und z.B. einen Teil der Schaltung aktivieren. Dort kann man > als Angreifer immer ansetzten. Ein secure Microcontroller kann auf der Master-HW nicht eingesetzt werden, dazu reicht zum einen die Rechenkapazität nicht und wäre auch konzeptionell nicht machbar. Der Closed System Ansatz wäre tatsächlich die beste Lösung. Deshalb wäre es wünschenswert einen sicheres FPGA zu haben in dem der Secret Key sicher gespeichert werden könnte. So wäre es möglich die Challenge & Response innerhalb des FPGA's zu erzeugen ohne auf ein externes Bauteil zurückgreifen zu müssen.
Oh D. schrieb: > Die Null Ahnung des Posters sind etwas mager. Da fehlt ein Stueck. Du hast dich hier auch nicht gerade mit Ruhm bekleckert. Wie soll denn "Etwas" sicher ausgetauscht werden ohne dass jeder andere es einfach nachmachen kann? Der AES wäre da durchaus geeignet, da man nur mit Kenntnis des Schlüssel das korrekte "Etwas" berechnen kann. Pascal schrieb: > - Gibt es grundsätzlich ein gutes Konzept wie man eine solche > authentifizierung sicher vornehmen kann? Challenge-Response mit zufällig generierten Challenges und kryptographisch sicheren Verfahren. Beispiel: 1. Master generiert zufällige Challenge c und sendet sie an Slave 2. Slave berechnet Response r = AES-CMAC_k(c) und sendet sie an Master 3. Master prüft ob r == AES-CMAC_k(c) Voraussetzung: 1. Challenge-Länge >= 96 Bit 1. Verfügbarkeit eines TRNG oder kryptographisch sicheren PRNG im Master 2. Schlüssel k lesegeschützt gespeichert in Master und Slave
Du wirst niemals 100% sicher sein. Nichtmal Microchip hats mit Keeloq geschafft: http://www.pittnerovi.com/jiri/hobby/electronics/keeloq/ Mach dein Konzept lieber so gut, dass es sich nicht lohnt nachzubauen...
Daniel H. schrieb: > Voraussetzung: > 1. Challenge-Länge >= 96 Bit > 1. Verfügbarkeit eines TRNG oder kryptographisch sicheren PRNG im Master > 2. Schlüssel k lesegeschützt gespeichert in Master und Slave Punkt 2 (ich glaube du hast eher Punkt 3 gemeint ;-) ) ist genau der Punkt der bei mir noch eine offene Frage ist. Wenn ich die Möglichkeit habe den Schlüssel k sicher auf meinem FPGA aufzubewahren, dann hätte ich die Möglichkeit ein geschlossenes System zu erzeugen bei dem es definitiv sehr schwer wäre dieses zu knacken. Dann kann ich die Berechnung der Response r = AES-CMAC_k(c) direkt auf dem FPGA vornehmen. Die Berechung der Response r = AES-CMAC_k(c) auf dem Slave wird sowieso in einem sicheren Device vorgenommen, wie eben z.B. auf dem ATSHA204A von Atmel. Aber wie sicher ist das Hinterlegen des Keys auf dem FPGA (oder auch im Flash des FPGA's)? Das Auslesen des FPGA's oder des Flash ist ja bekanntlich keine Sache. Oder mir sind zur Zeit zumindest keine FPGA's bekannt auf denen es einen lesegeschützten Bereich gibt. Denn wenn der Key auf dem FPGA nicht sicher ist bin ich dazu gezwungen den Key und die Berechnung der Response auf einem externen Bauteil durchzuführen. Dann könnte aber einer der das System "hacken" will einfach das externe Bauteil auf der Master-HW und auf der Slave-HW austauschen und mit seinem eigenen Key versehen. Dann wäre die Authentifizierung auch mit seinem Key erfolgreich.
Max D. schrieb: > Du wirst niemals 100% sicher sein. Nichtmal Microchip hats mit Keeloq > geschafft: http://www.pittnerovi.com/jiri/hobby/electronics/keeloq/ > > Mach dein Konzept lieber so gut, dass es sich nicht lohnt nachzubauen... Da bin ich mit dir völlig einverstanden. Allerdings wie sicher ist sicher? Ich denke ein geschlossenes System sollte es schon sein, sonst kann man sich die Authentifizierung gleich sparen. Die Frage ist einfach, wie bringt man ein solches geschlossenes System hin? Oder gäbe es einen Ansatz der auch für ein nicht komplett geschlossenes System hält?
Also wenn dein Endkunde bereit ist deinen Chip abzulöten und einen anderen draufzulöten, dann baut der sich zur Not auch deine ganze Kiste selber....
Max D. schrieb: > Also wenn dein Endkunde bereit ist deinen Chip abzulöten und einen > anderen draufzulöten, dann baut der sich zur Not auch deine ganze Kiste > selber.... Der Endkunde selbst vielleicht nicht, aber Konkurrenten von uns und Drittanbieter die ihre nachgebauten Module an unsere Endkunden verkaufen schon. Alles schon vorgekommen, deshalb arbeiten wir nun an diesem Konzept.
Pascal schrieb: > Ich habe von meinem Arbeitgeber den Auftrag bekommen, ein Konzept > auszuarbeiten um unsere Hardware vor Reverse Engineering zu schützen > sodass es einem Drittanbieter nicht möglich ist Ersatzteile für unsere > Kunden zu produzieren. Da wird sich der Kunde freuen. Steht die Eigenschaft dann auch mit im Prospekt oder lasst ihr ihn schön auf die Schnauzte fallen? Ist eure Firma auch so Hipp wie Apple, dass sich die Kunden das gefallen lassen oder Wechseln die Kunden nicht doch lieber zu einem Anbieter der sich einigermaßen an Standards hält? Habt ihr die Idee bei einem Druckerhersteller geklaut oder seid ihr selbst drauf gekommen?
Und der Kunde kauft dein Gerät nur weil die Funktion so einzigartig ist ? Und das baut die Konkurrenz nicht nach? Ich denke mal über die Garantie/Support-Schiene wirst du dem doch viel besser beikommen können. Getauschter Chip -> kein support
Karl schrieb: > Da wird sich der Kunde freuen. Steht die Eigenschaft dann auch mit im > Prospekt oder lasst ihr ihn schön auf die Schnauzte fallen? Ist eure > Firma auch so Hipp wie Apple, dass sich die Kunden das gefallen lassen > oder Wechseln die Kunden nicht doch lieber zu einem Anbieter der sich > einigermaßen an Standards hält? Habt ihr die Idee bei einem > Druckerhersteller geklaut oder seid ihr selbst drauf gekommen? Ein sehr konstruktiver Post Karl, aber ich möchte doch kurz darauf eingehen um Missverständnisse zu klären. In der Vergangenheit kam es schon öfters vor, dass chinesische Hersteller ganze Module unserer Maschinen kopiert und an unsere Kunden als Ersatzteile verkauft haben. All diese Module sind komplette Entwicklungen aus unserer Firma und passen auch nur auf unsere Maschinen. Das hat nichts mit irgendwelchen Standards zu tun, sondern sind von uns entwickelte und geschützte Produkte. Es ist wohl klar dass wir unsere Entwicklungen dahingehend schützen möchten, dass nicht jeder sein nachgebautes Produkt als unseres verkaufen kann. Am Ende sind wir zusätzlich mit qualitativ minderwertigen Ersatzteilen konfrontiert, mit denen wir ja eigentlich gar nichts zu tun haben.
Pascal schrieb: > Wenn ich die Möglichkeit > habe den Schlüssel k sicher auf meinem FPGA aufzubewahren, dann hätte > ich die Möglichkeit ein geschlossenes System zu erzeugen bei dem es > definitiv sehr schwer wäre dieses zu knacken. Ich kenne mich leider mit FPGAs kaum aus, ich wollte primär einen generellen Ansatz aufzeigen. Allerdings habe ich bei Altera die folgende Application Note gefunden: https://www.altera.com/en_US/pdfs/literature/an/an556.pdf Für mich hört sich das so an, als wenn man zumindest in einigen Altera-FPGAs Schlüssel persistent hinterlegen könnte.
Daniel H. schrieb: > Ich kenne mich leider mit FPGAs kaum aus, ich wollte primär einen > generellen Ansatz aufzeigen. Allerdings habe ich bei Altera die folgende > Application Note gefunden: > https://www.altera.com/en_US/pdfs/literature/an/an556.pdf Vielen Dank Daniel, das Dokument werde ich definitiv mal etwas genauer studieren!
Noch ein Nachtrag. Es gilt zwei Dinge bei Einsatz symmetrischer Kryptographie zu beachten: 1. Wenn man nur einen Schlüssel für alle Geräte verwendet dann ist das gesamte System gebrochen sobald es einem Angreifer gelingt den Schlüssel aus nur einem Gerät zu extrahieren 2. Will man 1. vermeiden muss man mit Geräte-/System-individuellen Schlüsseln arbeiten, was einen erhöhten (Konfigurations-)Aufwand bedeutet. Alternativ könnte man einen Ansatz mit asymmetrischer Kryptographie fahren, was aber die Performance erheblich senkt.
Daniel H. schrieb: > Alternativ könnte man einen Ansatz mit asymmetrischer Kryptographie > fahren, was aber die Performance erheblich senkt. Performance ist zum Glück kein Thema, ich benötige ja "bloss" die Authentifizierung. Konfigurationsaufwand könnte da schon eher ein Thema werden. Auf jedenfall danke für die Tips!
Georg A. schrieb: > So als Anregung könnte man sich auch den DS2432 von Maxim anschauen. Den DS2432 hatte ich auch schon im Auge, vorallem dann für die Authentifizierung der Slave-HW.
Pascal schrieb: > Performance ist zum Glück kein Thema Könnte es schon sein wenn es z.B. um die Startzeit geht ;) Ich entwickle z.B. gerade auf einem Controller der mit 100 MHz arbeitet. Eine RSA-Signaturerzeugung (implementiert in Software) dauert auf diesem Target etwa 10 Sekunden. Nicht sehr schön, wenn der Kunde den Start-Knopf drückt und sich dann erst einmal einen Kaffee holen kann :D
denkt euch mal was tolles aus. Und wenn es kommerziell für den Chinamann nutzbar wird, dann hat er innerhalb kürzester Zeit Euer Produkt geklont. Da greifen andere Mechanismen (Zoll) ggf. besser.
Pascal schrieb: > Es ist wohl klar dass > wir unsere Entwicklungen dahingehend schützen möchten, dass nicht jeder > sein nachgebautes Produkt als unseres verkaufen kann. Wenn euer Zeug so einfach nachzubauen ist, dann war eure Leistung wohl nicht besonders hoch. Wenn es jemand anders derart viel billiger verkaufen kann als ihr, dann sind eure Preise wohl Wucherpreise. Auf jeden Fall ist eine derartige Verdongelung von Hardware äußerst ärgerlich für den Anwender. Denn wenn ihr aus dem Markt geht oder einfach nur aus "politischen Gründen" keine Ersatzteile mehr liefert, dann ist er der Gelackmeierte. Siehe auch DRM. > Am Ende sind wir > zusätzlich mit qualitativ minderwertigen Ersatzteilen konfrontiert, mit > denen wir ja eigentlich gar nichts zu tun haben. Wenn ihr dem Kunden das Ersatzteil nicht verkauft habt (Rechnung, Seriennummer) dann ist es auch nicht euer Problem. Zur eigentlichen Frage äußere ich mich aus o.g. Grund nicht. Ich möchte, daß derartige Praktiken verschwinden. Da werde ich sicher keine Beihilfe leisten.
Pascal schrieb: > Deshalb wäre es wünschenswert einen sicheres FPGA zu > haben in dem der Secret Key sicher gespeichert werden könnte. So wäre es > möglich die Challenge & Response innerhalb des FPGA's zu erzeugen ohne > auf ein externes Bauteil zurückgreifen zu müssen. Les Dir mal die ersten Hits einer Google-Suche nach: "side-channel fpga bitstream encryption" durch. Wenn es sich bei deinen Produkten finanziell lohnt, dann wird es vermutlich auch jemand machen. Es sieht vom Aufwand hoch aus, aber wenn man sich mit der Materie auskennt ist es kein Hexenwerk den Key aus dem FPGA zu lesen.
Nils P. schrieb: > Es sieht vom Aufwand hoch aus, aber wenn man sich mit der Materie > auskennt ist es kein Hexenwerk den Key aus dem FPGA zu lesen. Auf irgendeine Art wird es wohl immer gehen. Die Idee ist, die Hürde so hoch wie möglich zu machen. Aber danke für den Hinweis!
Pascal schrieb: > In der Vergangenheit kam es schon öfters vor, dass chinesische > Hersteller ganze Module unserer Maschinen kopiert und an unsere Kunden > als Ersatzteile verkauft haben. Gehen die denn so oft kaputt ? Dann habt ihr schon mal ein Problem mit Zuverlässigkeit. > All diese Module sind komplette > Entwicklungen aus unserer Firma und passen auch nur auf unsere > Maschinen. Das hat nichts mit irgendwelchen Standards zu tun, sondern > sind von uns entwickelte und geschützte Produkte. Wenn diese aber so leicht zu kopieren sind, kann das auch keine grosse Entwicklung darstellen. Ein Nachbau kann sich nur lohnen wenn: a) es um Tausende von Stückzahlen geht b) Modulpreise übertrieben hoch sind Zu a) - Bei euch bestimmt nicht der Fall Zu b) - Bei euch bestimmt der Fall und ich schliesse mich der Meinung von Axel S. an, auch über evtl. Preissenkungen nachdenken, könnte im Endeffekt billiger sein als der ganze Kram mit Verschlüsseln. Ansonsten geht hier die ganze Kommunikation über SPI, wenn diese mit zwei ARMs und 512 bit verschlüsselt wird, braucht man: 50KB Flash für Programm (eher viel weniger) 64KB für Passwort, ergibt 1024 verschiedene Passwörter. 2KB = Tabelle mit Random Zeigern auf Passwörter 2KB = Tabelle um aus Pseudo-Befehlen richtige Befehle zu kriegen 1KB = Tabelle mit Anzahl der willkürlich angefügten Befehle 1KB = Tabelle mit Positionen der willkürlich angefügten Befehle Diese Zeiger werden beim Start von Master für jeden Slave bestimmt, Slave muss dies bestätigen und ab geht es mit verschlüsseltem SPI-Verkehr und Befehlen die anscheinend keinen Sinn ergeben und nicht zu entschlüsseln sind.
Marc V. schrieb: > Gehen die denn so oft kaputt ? > Dann habt ihr schon mal ein Problem mit Zuverlässigkeit. Unsere Maschinen lassen sich auch einfach mit unseren Modulen erweitern. Es geht dabei nicht ausschließlich nur um Ersatzteile. > Wenn diese aber so leicht zu kopieren sind, kann das auch keine grosse > Entwicklung darstellen. Je nach Modul ist die Komplexität sehr hoch. Aber auch jedes noch so komplexe Modul lässt sich in seine Einzelteile zerlegen und nachbauen. Ich spreche hier nicht nur von Elektronik, sondern auch von Mechanik. > Ein Nachbau kann sich nur lohnen wenn: > a) es um Tausende von Stückzahlen geht > b) Modulpreise übertrieben hoch sind Tausende von Stückzahlen sind es tatsächlich nicht. Der Modulpreis ist wieder vom Modul abhängig. Der Stückpreis der gesamten Maschine bewegt sich so um eine halbe Million Dollar. Klar können wir nicht die gleichen Preise machen wie die Kopierkünstler aus China, diese Problematik haben aber alle Hersteller die mit kopierter Hardware konfrontiert sind. Da stellt sich die Frage: Was heisst hier übertrieben hohe Preise? Am Ende will jede Firma konkurrenzfähig bleiben und passt ihre Preise entsprechend an, ansonsten Kauft keiner dein Produkt. Am Ende des Tages soll aber immernoch ein Gewinn für das verkaufte Produkt übrig bleiben, ansonsten müsste ich mir einen neuen Arbeitgeber suchen. Dein Ansatz mit der Verschlüsselung hört sich interessant an. Jedoch muss in meinem Fall die Kommunikation gar nicht verschlüsselt sein. Ich benötige ja bloss eine Authentifizierung mit der ich sicherstellen kann dass die Hardware nicht kopiert ist.
Pascal schrieb: > Dein Ansatz mit der Verschlüsselung hört sich interessant an. Jedoch > muss in meinem Fall die Kommunikation gar nicht verschlüsselt sein. Ich > benötige ja bloss eine Authentifizierung mit der ich sicherstellen kann > dass die Hardware nicht kopiert ist. Es geht nicht nur um die Verschlüsselung, sondern darum, dass die Kommunikation nicht 1:1 läuft.
Marc V. schrieb: > Ansonsten geht hier die ganze Kommunikation über SPI, wenn diese mit > zwei ARMs und 512 bit verschlüsselt wird, braucht man: > 50KB Flash für Programm (eher viel weniger) > 64KB für Passwort, ergibt 1024 verschiedene Passwörter. > 2KB = Tabelle mit Random Zeigern auf Passwörter > 2KB = Tabelle um aus Pseudo-Befehlen richtige Befehle zu kriegen > 1KB = Tabelle mit Anzahl der willkürlich angefügten Befehle > 1KB = Tabelle mit Positionen der willkürlich angefügten Befehle Urgs. Man kann es natürlich auch ressourcenschonender aufziehen. Wozu 512 Bit wenn 128 Bit ausreichend sicher sind? Wozu 1024 Schlüssel speichern (warum eigentlich 1024 und nicht 2048 oder 4096?) wenn man mittels kryptographisch sicherer Schlüsselableitung nahezu unbegrenzt viele Schlüssel dynamisch erzeugen kann? Ich würde es dann eher so machen: Zusätzliche Vorraussetzung zum weiter oben beschriebenen Schema: - Kryptographisch sichere Schlüsselableitung (KDF, z.B. nach NIST SP 800-108 mit AES-CMAC als PRF) Initialisierung: 1. Master wählt zufällige Challenge c und Nonce n mit c != n 2. Master berechnet Session-Key k' = KDF_k(n) 3. Master sendet c und n an Slave 4. Slave berechnet Session-Key k' = KDF_k(n) 5. Slave berechnet Response r' = AES-CMAC_k'(c) 6. Slave sendet r' an Master 7. Master verifiziert r' == AES-CMAC_k'(c) Kommunikation: 1. Befehl / Antwort m soll gesendet werden 2. mac = AES-CMAC_k'(m) wird berechnet 3. Nachricht (m,mac) wird gesendet 4. Empfänger verifiziert mac == AES-CMAC_k'(m)
Marc V. schrieb: > Zu b) - Bei euch bestimmt der Fall und ich schliesse mich der > Meinung von Axel S. an, auch über evtl. Preissenkungen > nachdenken, könnte im Endeffekt billiger sein als der > ganze Kram mit Verschlüsseln. Der Nachbauer muss die Entwicklungsphase eines Produkts nicht über den Produktpreis refinanzieren. Das ist bei Hardware fast so wie bei Software. Bei Software sind die Stückkosten nahe Null, aber für diesen Preis kann man sie nicht entwickeln. Ebensowenig kann man Hardware mit langer Entwicklungsphase zum Stückkostenpreis plus Gewinnspanne verkaufen, wenn man die Entwicklung selbst finanzieren muss, statt sie vom Konkurrenten zu klauen. Der Originalhersteller kann also nicht über den Preis mit dem Nachbauer konkurrieren, so lange die Entwicklungskosten nicht wieder drin sind.
:
Bearbeitet durch User
Moin, es gibt bei manchen FPGA-firmen einen ganz pragmatischen Ansatz: Wenn bisschen Stückzahl drinsteckt (und das auch schon ab 1000) kann man sich eine custom-Variante branden lassen, mit der dann die HW richtig läuft. Mit der Standard-Variante z.B. schlägt dann eine Zeitbombe zu, oder noch besser, der Bitstream wird nicht akzeptiert. Abgesehen von den verschlüsselten Bitstreams hat man zudem noch die Kontrolle, dass nicht irgendeiner die HW klont. Laut besagtem Hersteller wird die gebrandete Variante nur an die entsprechend "lizenzierten" Bestücker ausgeliefert. Bei kleinen Stückzahlen würde ich diesen Aufwand aber nicht treiben, die Gefahr ist gross, sich da selber ein Bein zu stellen. Erstens funktioniert in der FPGA-Welt Security by Obscurity meistens - zumindest in der Industrie - noch sehr gut. Und zweitens klonen manche Firmen äusserlich so gut, dass die nicht funktionierende Peripherie aufgrund Funktionsverweigerung wegen fehlender "Zertifikate" dann zum Originalhersteller zurückkommt und das den Ruf gar ruinieren kann (schon geschehen bei einem Kunden). Drittens ist man bei Änderungen sehr schwerfällig, und wenn der Master-Key mal raus ist, ist das eh alles für die Katz. Gefuste Key-Bits liest Igor aus St. P. gerne mal eben mit einem Ionenstrahl-Scope aus. Für manche Lösungen a la ADI-Lockbox oder Freescale secure booter braucht's nur einen JTAG-Hack. Mit einem FPGA kannst du schon so genügend Obskuritäten oder Funktionen einbauen, da tut's auch schon einfach ein MachXO2, der nicht ausgelesen werden kann. Nix ist sonst ärgerlicher, sich die tollste Encryptionmethode auszudenken, und ein findiger Fuchs umgeht's mit ner einfachen Methode. Grüsse, - Strubi
Strubi schrieb: > es gibt bei manchen FPGA-firmen einen ganz pragmatischen Ansatz: Wenn > bisschen Stückzahl drinsteckt (und das auch schon ab 1000) kann man sich > eine custom-Variante branden lassen, mit der dann die HW richtig läuft. > Mit der Standard-Variante z.B. schlägt dann eine Zeitbombe zu, oder noch > besser, der Bitstream wird nicht akzeptiert. Kennst du ein spezifisches FPGA oder eine Application Note eines Herstellers zu diesem Thema? Es würde mich mal interessieren wie dies bei einem FPGA umgesetzt ist. > Drittens ist man bei Änderungen sehr schwerfällig, und wenn der > Master-Key mal raus ist, ist das eh alles für die Katz. Gefuste Key-Bits > liest Igor aus St. P. gerne mal eben mit einem Ionenstrahl-Scope aus. > Für manche Lösungen a la ADI-Lockbox oder Freescale secure booter > braucht's nur einen JTAG-Hack. Wenn Igor unbedingt will, dann findet Igor auch irgendwie einen Weg. Igor soll es nur möglichst schwer haben. Das mit den gefusten Key-Bits bringt aber noch einen Vorteil: Der Atmel AT88SA100S zum Beispiel benutzt für die Berechnung der Response sowohl 64 Fuse-bits als auch einen Secret-Key. So kann ich von Atmel die Bauteile mit dem vorprogrammierten Secret-Key bestellen und der Print-Supplier brennt anschliessend die 64 Fuse-bits ein. So hat keiner der beiden den vollständigen Schlüssel, was das Risiko erheblich vermindert, dass der gesamte Schlüssel in falsche Hände gerät.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.