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.
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.
@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
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?
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.
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.
Grafik_1.png
(13 KB)
