Hallo, folgende Ausgangssituation. Wir möchten Geräte verkaufen, die auf Embedded Linux basieren und ein Betriebssystem, Anwendungssoftware und eine Datenbank beinhalten. Da es für die Datenbank regelmäßige Updates gibt, ist eine einfache Update-Möglichkeit wichtig. Die Firmware komplett inkl. Datenbank soll der Einfachheit halber als eine Datei ausgeliefert werden. Das Aufspielen soll per USB-Kabel über eine PC-Software oder alternativ durch Kopieren auf SD-Karte und Einschieben in das Gerät funktionieren. Da die Geräte fest installiert werden, ist ein Internetanschluß nicht vorgesehen. Weil die Datenbank kostenpflichtig ist (wir kaufen die von einem Drittanbieter und müssen pro verkaufter Lizenz Gebühren an diesen Anbieter abführen), soll eine Firmware nur auf ein Gerät passen. Die Firmware wird von unserem Downloadserver bereitgestellt und kann das Paket anhand der eingegebenen Seriennummer für ein spezielles Gerät schnüren. Dabei kann auch geprüft werden, ob für das Gerät ein gültiges Abo abgeschlossen ist. Aus der Firmware-Datei darf sich die Datenbank nicht extrahieren lassen. Hierfür brauche ich nun ein Konzept. Meine Idee bisher ist: - Verschlüsseln und Signieren der Firmware anhand eines asymmetrischen Krypto-Systems - Gerät entpackt die Software, prüft eine Checksumme, flasht Kernel und RootFS neu, legt anschließend die Datenbank in verschlüsselter Form im neuen RootFS ab. - Das Flash ist groß genug, um zwei komplette Versionen der Firmware vorzuhalten. Der Bootloader prüft, welche die aktuellere ist und startet die neuere. Hier gibt es auch ein Fallback zur letzten Version, falls beim Flashen etwas schief gelaufen ist (zum Beispiel Stromausfall während Update) - Beim Benutzen der Datenbank wird diese in eine RAM-Disk entschlüsselt und von dort benutzt. - Der private Schlüssel liegt in einem batteriegepufferten internen RAM eines Utility-µC und wird beim Öffnen des Gerätes gelöscht. Das Gehäuse ist so gestaltet, dass beim Öffnen Netzteilplatine und CPU-Platine getrennt werden und damit die Stromversorgung zum RAM getrennt wird. Was haltet ihr von dem Konzept, wie könnte man es besser machen?
Horst schrieb: > Der private Schlüssel liegt in einem batteriegepufferten internen RAM > eines Utility-µC und wird beim Öffnen des Gerätes gelöscht. Das Gehäuse > ist so gestaltet, dass beim Öffnen Netzteilplatine und CPU-Platine > getrennt werden und damit die Stromversorgung zum RAM getrennt wird. Was passiert, wenn die Batterie leer ist? Service-Techniker? Baugruppe einschicken? Das ist das, was mir spontan einfällt.
Horst schrieb: > - Der private Schlüssel liegt in einem batteriegepufferten internen RAM > eines Utility-µC und wird beim Öffnen des Gerätes gelöscht. Das Gehäuse > ist so gestaltet, dass beim Öffnen Netzteilplatine und CPU-Platine > getrennt werden und damit die Stromversorgung zum RAM getrennt wird. Soll das eine neue Implemtierung von geplanter Obsoleszenz werden?
Das abzusichern dürfte hart sein. Gerade mit Linux, gerade wenn man die Möglichkeitt hat Updates einzuspielen. Aber wieso legst DU Wert darauf, die Datenbank zu sichern. Wenn der Kunde einen Rechtsbruch begeht und die Datenbank irgendwie kopiert ist das doch nicht dein Problem? Wenn du deinen eigenen Code schützen möchtest ist das ja noch verständlich. Wenn du genauere Hilfestellungungen möchtest musst du, meiner Meinung nach, sagen wovor du dich genau schützen möchtest. Vor: - Auslesen der Datenbank? - Modifikation der Datenbank? - Auslesen deines Codes? - Modifikation deines Codes? - Modifikation des Gerätes? - "Kopieren" der Datenbank von einem anderen Gerät? etc. Außerdem, welche Art von Angreifern hast du im Sinne? Die, die auch mal den Flash auslöten und neu beschreiben? Der gelangweilte Kollege, der einfach mal das Update vom größeren Modell fahren will? Der Typ, der das Rasterelektronenmikroskop von letztens gekauft hat? Die Chinesische Mafia? NSA? Die meisten davon dürften nämlich zB von deinem Gehäuse-Aufbrech-Schutz nicht viel halten, im Zweifel macht man halt das erste Gerät kaputt, spätestens beim Zweiten weiß man dann, wo man ein Loch in den Deckel fräsen kann.
Horst schrieb: > - Der private Schlüssel liegt in einem batteriegepufferten internen RAM > eines Utility-µC und wird beim Öffnen des Gerätes gelöscht. Das Gehäuse > ist so gestaltet, dass beim Öffnen Netzteilplatine und CPU-Platine > getrennt werden und damit die Stromversorgung zum RAM getrennt wird. krasses Fehldesign. Für einen Angreifer, der sich ein zweites Gerät beschafft, simpel zu umgehen. Für einen normalen Anwender, dem der Utility-µC wegen irgendetwas (EMV-Störung, Bug) abstürzt, dagegen der Totalausfall. Service skaliert auch nicht, da das Gerät nicht extern wartbar ist (außer man gibt doch wieder das know-how raus).
>Weil die Datenbank kostenpflichtig ist (wir kaufen die von einem >Drittanbieter und müssen pro verkaufter Lizenz Gebühren an diesen >Anbieter abführen), soll eine Firmware nur auf ein Gerät passen. Da wird sich die Konkurrenz freuen und Harald Welte (gpl-violations.org) einen Tipp geben. Bevor ich Aufwand in ein HW-Schutzkonzept reinstecke, würde ich halt die 250E in einen juristischen Spezialisten reinstecken. Aus meiner Sicht waere es heikel, dass sich nur durch blosses Gehäuseöffnen des neuerworbenen Eigentum eine Funktionsunfaehigkeit oder -minderung ergibt. Das einfache Feststellen des Öffnen waere OK (ggf. wegen der Reduzierung von Gewährleistungsansprüchen). Wir sind uns einig, dass ein ernsthafter Konkurrent mehrere Geraete kauft und beim ersten rausbekommt, wie die "Schutzmechanismen" laufen? IMHO kannst Du die die Datenbank (weil proprietär, richtig?) so schützen, bzgl. den Firmware GPL Sachen (Linux+Anpassungen, Linux Userland) musst Du die tatsaechlichen Quellen rausgeben. Im Prinzip ist der oben beschriebene Schutzmechanismus so in pgp/gpg verfügbar(auch im Userland, gpg ist GPL), in dem gpg-Manual waere Mailadresse durch Seriennummer zu ersetzen. Das waere fertig und direkt einsetzbar und waere auch zu empfehlen, da man bei der Implementierung von Kryptosystemen so viele Fehler machen kann, dass man besser was Fertiges nimmt.
Mach Dir nicht so viele Gedanken über den Schutz des Systems, sondern eher über die Wünsche der Kunden, "runde" Bedienung, Zuverlässigkeit etc. Ein simpler Schutz, der z.B. die Updatedatei mit einer individuellen Seriennummer des Prozessors verschlüsselt, reicht vollkommen aus. Jeder ernst zu nehmende Geschäftskunde wird da keine große Zeit in Reverse-Engineering stecken, sondern das vielleicht höchstens einmal 10 Minuten ausprobieren. Wenn Du es dagegen mit einem professionellen Codeknacker zu tun hast, wird es sehr sehr sehr aufwendig bis unmöglich Dein System zu schützen. Schau Dir die ganzen Spielekonsolen an, da wird richtig Aufwand reingesteckt die zu schützen und dennoch sind sie alle geknackt. Unterm Strich bist Du also besser dran wenn Du durch ein besseres Produkt mehr zahlende Kunden gewinnst, als wenn Du ein paar, die sowieso nichts zahlen wollen, abgewehrt bekommst. Irgendwelche Daten bei bloßem Öffnen des Geräts unbrauchbar zu machen halte ich in der Praxis für höchst problematisch. Selbst kleinste Reparaturen (z.B. festdrücken eines durch Versand/Umzug gelockerten Kabels) durch einen fachlich versierten Kunden werden unmöglich. Auch könnte es zu Fehlalarmen kommen. Der ehrliche Kunde wird, wenn er das rausbekommt, zu Recht sauer oder gar Schadenersatz fordern.
> Was passiert, wenn die Batterie leer ist? > Service-Techniker? Baugruppe einschicken? Es ist vorgesehen, dass zwei CR2032-Knopfzellen über eine Schottky-Dual-Diode den Utility-µC speisen, so dass diese einzeln nacheinander ausgetauscht werden können. Selbstverständlich gibt es rechtzeitig eine Warnung, dass die Batterie nachlässt. Wir denken über eine mechanische Lösung nach (drehender Deckel etc.), bei der es nicht möglich ist, beide Batterien gleichzeitig zu entnehmen. Wenn das Gerät länger als 5 Jahre in einer Schublade liegt und die Batterien vollständig entleert werden, hilft tatsächlich nur einschicken. Darauf wird der Kunde in der Anleitung hingewiesen. Wir planen nicht, für das Re-Initialisieren mehr als das Porto plus eine kleine, nicht mal kostendeckende Aufwandspauschale zu verlangen. > Soll das eine neue Implemtierung von geplanter Obsoleszenz werden? Nein. Eine wesentliche Funktion des Gerätes ist es, Daten aufzuzeichnen, die "manipulationssicher" sind, d.h. die Hürden für eine Manipulation werden mit technischen Maßnahmen erhöht. Dazu gehört es, die Daten mit einer digitalen Signatur zu versehen. Das Gerät enthält den privaten Schlüssel. Die öffentlichen Schlüssel aller unserer Geräte sind in der Auslesesoftware hinterlegt, die wir als Stand-Alone-Programm und als DLL für Drittanbieter zur Verfügung stellen. Dieses Vorgehen ist von der Zulassungsstelle für diese Geräte so vorgeschrieben. Dass die Datenbank mit dem gleichen System geschützt wird, ist sozusagen ein Abfallprodukt. > Wenn du genauere Hilfestellungungen möchtest musst du, meiner Meinung > nach, sagen wovor du dich genau schützen möchtest. Vor: > - Auslesen der Datenbank? Ja. Es soll verhindert werden, dass die Datenbank extrahiert, in ein anderes Format konvertiert wird und dann als Torrent im Netz landet. Nicht, weil die so hoch geheim ist, sondern weil der Urheber der Datenbank das in seinen Lizenzbestimmungen so vorschreibt. Urheber ist übrigens der Deutsche Staat, bzw. ein mit hoheitlichen Aufgaben beliehenes Unternehmen. > - Modifikation der Datenbank? Wäre mir persönlich egal, allerdings hätte der Kunde auch nichts von geänderten = falschen Daten. > - Auslesen deines Codes? Die Schlüssel sollten nicht ausgelesen werden, die liegen aber auf dem Utility µC und werden von diesem verwaltet. Der Programmcode liegt nur binär vor und ist nicht so weltbewegend, dass ein Reverse-Engineering meine Firma ruinieren würde. Es stecken jedenfalls keine "Trade Secrets" drin, wie es immer so schön heißt. > - Modifikation deines Codes? > - Modifikation des Gerätes? Es sollte nicht (bzw. nur mit großem Aufwand) möglich sein, eine geänderte Firmware zu installieren, die die privaten Schlüssel ausliest und auf dem Bildschirm anzeigt. > - "Kopieren" der Datenbank von einem anderen Gerät? Genau das soll verhindert werden, damit ich den Vertrag mit dem Urheber der Datenbank einhalte. > Außerdem, welche Art von Angreifern hast du im Sinne? Die, die auch mal > [...] > Mafia? NSA? Die meisten davon dürften nämlich zB von deinem > Gehäuse-Aufbrech-Schutz nicht viel halten, im Zweifel macht man halt das > erste Gerät kaputt, spätestens beim Zweiten weiß man dann, wo man ein > Loch in den Deckel fräsen kann. Das ist mir klar. Wer ein Gerät kaputt macht, um raubkopierte Datenbanken nutzen zu können, handelt nicht wirtschaftlich, da Preis Gerät >> Preis Datenbank. Wer das Gerät kaputt macht, um herauszufinden, wie er den "RAM-Pufferbatterie-Unterbrechungs-Kontakt" beim nächsten Gerät überlisten kann, könnte Aufzeichnungen mit dem Gerät fälschen, die dann trotzdem eine valide digitale Signatur hätten. Da es hier aber um sportliche Leistungen geht, wäre der maximale Gewinn eine Auszeichnung, die man sonst nicht verdient hätte. Und es wäre wahrscheinlich für Experten des Sportes eine leichte Sache, gefälschte Daten zu erkennen. Das einzige realistische Szenario wäre wohl, die tatsächlich stattgefundene Leistung eines anderen für die eigene auszugeben. > krasses Fehldesign. Für einen Angreifer, der sich ein zweites Gerät > beschafft, simpel zu umgehen. Siehe oben. Wie gesagt, es geht darum, die technischen Hürden so hoch zu machen, dass es sich nicht besonders lohnt, diese zu überspringen. Wenn einer meiner technisch versierten Kunden die Datenbank doch kopiert, dann kann ich es eben auch nicht ändern. Hauptsache, der Prozentanteil dieser Nutzer bleibt klein.
> Da wird sich die Konkurrenz freuen und Harald > Welte (gpl-violations.org) einen Tipp geben. Warum? Selbstverständlich werden wir alles zur Verfügung stellen, was wir zur Verfügung stellen müssen. Und das ist der gesamte Quelltext, Konfiguration und Toolchain mit der Ausnahme von - unser eigener 1st stage Bootloader - unsere eigene Anwendungssoftware - Datenbank - private Schlüssel des individuellen Gerätes - Firmware des Utility µC > Aus meiner Sicht waere es heikel, dass sich nur durch blosses > Gehäuseöffnen des neuerworbenen Eigentum eine > Funktionsunfaehigkeit oder -minderung ergibt. Ist leider so vorgeschrieben, wenn wir für das Gerät eine Zulassung bekommen wollen, damit es offiziell für die Aufzeichnung dieser sportlichen Leistungsdaten eingesetzt werden kann. Das gleiche Problem haben sämtliche Konkurrenzprodukte also auch. > IMHO kannst Du die die Datenbank (weil proprietär, richtig?) > so schützen, bzgl. den Firmware GPL Sachen (Linux+Anpassungen, > Linux Userland) musst Du die tatsaechlichen Quellen rausgeben. Ich gebe selbstverständlich die Quellen etc. für alle verwendete GPL-Software heraus, wüsste aber nicht, was gegen eine Auslieferung der Firmware als verschlüsseltes Binary spricht?
P.S.: Politisch bin ich übrigens der Meinung, dass diese Datenbank allen Bürgern kostenlos zur Verfügung stehen sollte. Die aktuelle Situation ist aber eine andere. Da der Nutzerkreis recht eingeschränkt ist, lässt man diesen halt für den Aufwand der Datenpflege zahlen.
Wieso muss es dann RAM sein? Nutze doch für den Utility µC einen dieser extra sicheren Mikrocontroller mit Lockbits und co. Der spuckt dann nicht etwa den Schlüssel an das Linux aus, sondern signiert die Daten selber. Also Daten in den Utility µC pumpen und Signatur rausbekommen. Das sollte dann sicher genug sein und du hast nicht den Mist mit den Batterien. Auf die Art (nagut, die hatten das in Hardware) hat Sony es geschafft die PSP über viele Jahre trotz symmetrischer Krypto (in der Hinsicht) sicher zu halten. Jemand, der den Key klauen will müsste dann schon den µC aufätzen und mehr. Bezüglich der Datenbank, hier implementierst du was vorgeschrieben ist, zB in eine RAM-Disk decrypten (den Key dafür kann dir ja auch der Utility-µC aus dem Header der Datenbank errechnen oder so), aber keinen Strich mehr. Ist ja nicht dein Problem wenns dann doch jemand knackt.
Achso um mit der Methode Daten zu fälschen muss man natürlich "nur" den Utility-µC selbst ansprechen. Aber ich glaube das fällt in die gleiche Kiste wie "ein Gerät kaputt machen um beim nächsten zu wissen wie es geht". Du solltest mit dem Utility-µC natürlich auch schon verschlüsselt sprechen. Das ist zwar nicht hochsicher da der Key im Code steht, aber sollte reichen und ist vor allem auch nicht besser oder schlechter als den Key im RAM zu halten.
Ehrlich ... ganz ganz ehrlich: Wenn ich das oben lese und ich Kunde wäre und von solchen Schutzmechanismen wüßte, würde ich das Gerät nur in dem Falle kaufen, wenn es weltweit das einzige seiner Art wäre und ich es dringenst benötige. In meinem Betrieb laufen unzählige Meßsysteme (bis zum 2 Mio. Euro teuren Rasterelektronenmikroskop). Viele dieser Meßsysteme sind aufwändig gesichert sodass es schon ein paar mal vorgekommen ist, dass diese Geräte ohne Herstellerunterstützung nicht reparierbar, manchmal nicht mal wartbar waren. Schlimm ist das (bisher in 3 Fällen) wenn es die Firma dann gar nicht mehr gibt (so geschehen bei einem 50.000 Euro teuren Fermenter)... Sensationell ! Einfach nur klasse ! Ich hasse das sehr ! Oder es gibt etwas in der Art, dass das Interface zur Meßstrecke einfach sich nicht an einem anderen PC betreiben lassen mag, weil dieses geschissene Interface von dem PC Schutzdateien ausliest und danach erst das Interface frei gibt. Dumm nur, wenn die Festplatte gestorben ist ! Ein Ersatz gibt es nicht, Support für den restlos veralteten (8 Jahre) Adapter gibt es sowieso nicht mehr aber (O-Ton Hersteller) "Natürlich sind wir gerne bereit Ihnen ein Angebot für ein neues Meßsystem zu unterbreiten" (die dann ohne Scheiß original dieselbe Meßstrecke beinhalten - Coulter Counter - Partikelgrößenmeßgerät). Ehrlich, wirklich ganz ganz ehrlich: Kaum einer, der solche Geräte kauft und dann benutzt wird ein zweites Gerät dann herstellen um sich die Anschaffungskosten zu sparen. Von Firmen - wenn ich bei der Entscheidung bei neuen Geräten involviert bin - die ihre Geräte derart "schützen" dass der Umgang mit ihnen extrem schwierig ist, rate ich den Entscheidungsträgern bei uns dann immer ab. Die Firmen sollten sich mal das Wort Kundenfreundlichkeit durch den Kopf gehen lassen !
PS: ... da ist selbst Microsoft "besser" (und ich mag Microsoft nun wirklich nicht). Ein Gerät, das einen programmierten Controller oder ein SoC beinhaltet und "sich hochohmig geht" (wie ein lange verrenteter Kollege so schön sagte) war in aller Regel deshalb teuer, weil die Software die diese Controller betrieb die meiste Entwicklungsarbeit forderte und deshalb teuer war. Ist ein solches Gerät kaputt und ich muß ein neues beschaffen, bezahle ich genau den gleichen Preis noch einmal (obwohl ich doch eigentlich die Software schon bezahlt habe - bestes Bsp. ist hier ein KFZ Steuergerät). Selbst bei Microsoft bezahlt man für die Softwarelizens ... und nicht für den Datenträger (bei Geräten wäre das eben der Microcontroller). Für mich zielt das immer nur in eine Richtung, nämlich in Richtung Gewinnmaximierung auf Kosten des Kundens ! Hrmpf ! Schutzssysteme .... Der Threadersteller tut mir wirklich leid, dass er wohl Anweisungen hat, ein solchiges zu Erstellen !
Ich möchte Dich noch darauf hinweisen, dass es nicht reicht die Sourcen, Toolchain und die Konfiguration bereitzustellen um die GPL bzw LGPL zu erfüllen. Du musst dem Kunden auch die Möglichkleit geben, eine neue Version der unter der GPL/LGPL stehenden Bibliothek zu linken und ersetzen. D.h. der Kunde muss irgendwie Zugriff auf das Filesystem haben. Siehe GPL Kapitel 6, bzw LGPL Kapitel 4.
Ich würde erst einmal den Datenbankhersteller fragen, was er als eine zumutbare Lösung ansieht, ohne dass er euch später ans Bein pisst. Evtl. sollte er auch Lösungen von anderen Kunden parat haben. Denn selbst die Beste Lösung ist immer knackbar, es kommt eben auf den Aufwand an, meist ist es aber aufgrund eines Designfehlers und den werdet ihr auch irgendwo (siehe auch Spielekonsolen, dort sitzen aber Mannschaften dran, die sich das ausdenken) machen. Es kann also nur eine bestmögliche abgewogene Lösung geben, die der Hersteller akzeptiert und diese würde ich wählen. Die Geschichte mit dem Ram-Buffer würde ich nicht machen (ok, ich mach normalerweise Medizintechnik), denn sobald dies ausfällt ist das System wertlos und in unserem Fall ruft dann ein erboster Kunde an, da er ein Problem im OP hatte. Ganz abgesehen davon vor Hardware-Manipulationen ist man nur sehr schwer geschützt, daher solltest du dich Fragen, wie stark muss der Schutz mindestens sein und keinen Schritt weiter gehen. Alles was nicht sein muss macht nur Ärger und kostest 3 mal Geld, beim Entwickeln, in der Produktion und dann beim Service!
Ralph S. schrieb: > Schutzssysteme .... Der Threadersteller tut mir wirklich leid, dass er > wohl Anweisungen hat, ein solchiges zu Erstellen ! An sich sind Schutzsysteme einen interessante und wichtige Sache. Richtig implementiert (siehe zB. xbox360) stören sie die zahlenden Kunden überhaupt nicht, die ungewollten Eindringlinge dagegen werden gut abgehalten (zumindest im großen Rahmen). Um so ein System wirklich sicher zu bekommen muss man natürlich die Methoden der Eindringlinge kennen. Ein Firmwarefile von USB/SD zuerst zu prüfen und dann bei erfolgter Prüfung in den Flash zu schreiben ist zum Beispiel grob fahrlässig. Gut bekannter Angriffsvektor: mofizierter Datenträger bietet beim ersten Lesen ein Original-Update, beim zweiten Mal ein Custom-Update. Solche Szenarien gibt es einige, da sollte man sich schon ein wenig auskennen. Linux ist leider auch nicht wirklich für solche Systeme gedacht soweit ich weiß. Mir ist keine Methode bekannt, mit Linux eine Chain of Trust aufzubauen. Vielleicht wird sich das im Zuge von Secure Boot bessern. Ansonsten, denk dir n vernünftiges Krypto-Konzept ohne RAM aus, dann passt das schon.
Nimm einen bootloader, wie CFE, uboot usw welche eine Notfall NVRAM bereitstellen können, wo ihr dann für jedes Gerät eigens eine crypto gesicherte Serial habt.
Dani Z schrieb: > Ich möchte Dich noch darauf hinweisen, dass es nicht reicht die Sourcen, > Toolchain und die Konfiguration bereitzustellen um die GPL bzw LGPL zu > erfüllen. Du musst dem Kunden auch die Möglichkleit geben, eine neue > Version der unter der GPL/LGPL stehenden Bibliothek zu linken und > ersetzen. D.h. der Kunde muss irgendwie Zugriff auf das Filesystem > haben. Siehe GPL Kapitel 6, bzw LGPL Kapitel 4. So einen Schwachsinn habe ich selten in einer Lizenz gelesen. Auf der einen Seite verstehe ich die Intention, aber wenn jeder an einer Maschine rumschraubt, dann kann diese durchaus kaputt gehen, oder ihre Zulassung verlieren. Gerade in der Medizintechnik ist das ja nett, ich freue mich schon darauf, das das nächste Gerät das für meine Behandlung eingesetzt wird, vom Nutzer gepimpt wurde. Die V2 hat dieses noch nicht enthalten.
> Da es hier aber um > sportliche Leistungen geht, wäre der maximale Gewinn eine Auszeichnung, > die man sonst nicht verdient hätte. Ach her je. Das wird aber kein IGC-Logger? Und die "Datenbank" sind ein paar Luftraum-Koordinaten, Wendepunkte etc.?
Horst schrieb: >> Da wird sich die Konkurrenz freuen und Harald >> Welte (gpl-violations.org) einen Tipp geben. > > Warum? Selbstverständlich werden wir alles zur Verfügung stellen, was > wir zur Verfügung stellen müssen. Und das ist der gesamte Quelltext, > Konfiguration und Toolchain mit der Ausnahme von Oder einfach konsequent keinerlei GPL-Software benutzen. Es gibt ja noch mehr als Linux. Für PC-basierte Systeme verwende ich meist OpenBSD. Da muss ich nichts rausgeben. Und BSD gibts ja auch embedded, auch wenn das weniger verbreitet ist. Oder gleich ein richtiges RTOS. Frag doch mal die Leute bei WIBU. Die haben auch Dongles in Form von CF- und SD-Cards, die gleichzeitig als sicheres Speichermedium dienen können. Und sie haben Support nicht nur für Desktop-Systeme, sondern zB auch für vxWorks (dem einzigen interplanetaren RTOS). fchk
Frank K. schrieb: > Oder einfach konsequent keinerlei GPL-Software benutzen. Es gibt ja noch > mehr als Linux. Für PC-basierte Systeme verwende ich meist OpenBSD. Da > muss ich nichts rausgeben. Und BSD gibts ja auch embedded, auch wenn das > weniger verbreitet ist. Oder gleich ein richtiges RTOS. > > Frag doch mal die Leute bei WIBU. Die haben auch Dongles in Form von CF- > und SD-Cards, die gleichzeitig als sicheres Speichermedium dienen > können. Und sie haben Support nicht nur für Desktop-Systeme, sondern zB > auch für vxWorks (dem einzigen interplanetaren RTOS). Genau, pack so vielen proprietaeren scheiss rein wie du nur kannst. Das macht das System bestimmt sicherer, einfacher und billiger! Frag doch mal bei Microsoft an, die haben Erfahrungen damit Systeme, bei denen nicht viel schief gehen kann total in den Sand zu setzen.
Horst schrieb: > - Beim Benutzen der Datenbank wird diese in eine RAM-Disk entschlüsselt > und von dort benutzt. Und wie verhinderst du, dass jemand die RAM-Disk dumped? Horst schrieb: > - Der private Schlüssel liegt in einem batteriegepufferten internen RAM > eines Utility-µC und wird beim Öffnen des Gerätes gelöscht. Das Gehäuse > ist so gestaltet, dass beim Öffnen Netzteilplatine und CPU-Platine > getrennt werden und damit die Stromversorgung zum RAM getrennt wird. Das hindert jemanden, der die Datenbank definitiv haben will genau einmal. Beim nächsten Mal wird er sich dann etwas einfallen lassen um an den Inhalt des RAMs zu kommen (Öffnen des Gehäuses durch Fräsen geeigneter Öffnungen, Herunterkühlen des Utility-PCs um den RAM-Inhalt auch bei Trennung der Spannungsversorgung zu erhalten usw.). Ganz davon ab, dass auch hier ggf. je nach Architektur ein direkter Dump aus dem System heraus erfolgen kann. Generell frage ich mich, warum du dir über sowas überhaupt Gedanken machen musst. Ihr zahlt pro verkaufter Lizenz und gut ist, warum sollte es euch kümmern, was der Anwender mit der Datenbank treibt? Immerhin verstößt er ja gegen die Lizenzbedingungen, wenn er die Datenbank ohne gültige Lizenz nutzt, und macht sich somit ggf. strafbar. Das festzustellen und zu verfolgen sollte aber Aufgabe des Datenbankherstellers sein, und nicht eure. Zumindest würde ich diesbezüglich erst einmal die rechtliche Lage überprüfen, bevor man sich weitere Gedanken über Schutzmaßnahmen macht. Sollten weitere Schutzmaßnahmen nötig sein so würde ich das aufgezeigte Konzept für ungeeignet erachten, hier wäre mindestens der Einsatz eines dedizierten Security-Controller mit sicherem (tamper-resistant/tamper-detecting) Speicher für kryptographisches Schlüsselmaterial angebracht. Allerdings würde ich mir für ein umfassendes Konzept externe Hilfe holen, und damit meine ich nicht irgendwelchen Foren sondern bei Firmen, deren tägliches Geschäft es ist Sicherheitskonzepte zu entwerfen und zu analysieren. Nur so kann man sicherstellen, dass man nicht vielleicht doch irgendeine Kleinigkeit übersieht, welche letztenendes das gesamte Sicherehitskonzept unwirksam macht. Viele Grüße Daniel
Guest (Gast) schrieb: >Genau, pack so vielen proprietaeren scheiss rein wie du nur kannst. Propriaetaer muss nicht gleich schlecht sein. Zur GPL gibt es open_source Alternativen wie BSD-Lizenz. >Das macht das System bestimmt sicherer, einfacher und billiger! Das Dogma der Securitybranche lautet (und da bin ich "glaeubig"): Cheap, simple, secure? Choose two! >Frag doch mal bei Microsoft an, die haben Erfahrungen damit Systeme, >bei denen nicht viel schief gehen kann total in den Sand zu setzen. Die obige sehr sichere Alternative OpenBSD unter BSD-Lizenz wurde schon erwaehnt, hier muss man den Quellcode/Modifikationen nicht herausgeben (aber dafuer lt. Lizenz andere Dinge tun). Wenn man sich fuer Linux entscheidet, ist man an die GPL gebunden. Das ist fuer viele kommerzielle Produkte und Firmen vollkommen OK, weil das Basissystem von der Community entwickelt wird und damit Kosten spart. Die GPL stellt sicher, dass ich z.B. in 5 Jahren ein GPL Betriebssystem/Library/Userland mit einer neuen Version, die mir durch die Community bereitgestellt wird, patchen kann und darf (bspw. bei sowas wie Heartbleed). IMHO wird das bei den Internet-of-things-Dingern (und IPv6) immer wichtiger, weil die dann direkt am Netz haengen werden. Daher wuerde ich bei einem kommerziellen Produkt auf Linux Basis erwarten, dass die GPL Sachen (ggf. unter Verlust der Gewaehrleistung) modifizierbar sind, die Applikation duerfte durchaus proprietaer sein (muss aber nicht ;-) ). In dem obigen Beispiel der Verwendung von Linux mit einer "very-closed" DB darf man durchaus fragen, ob Linux die richtige Wahl war. Es gibt seit Ende der 90er ein spezielles Urheberrecht fuer Datenbanken, welches strafbewaehrt illegale Kopien sanktioniert. Ob das einschlaegig ist und ob hinsichtlich der Liefervertraege zum DB-Vorlieferanten dieses ausreichend greift, kann nur ein Jurist klaeren. Thema Microsoft (SCNR): 1. Keiner ist nutzlos, er kann immer noch als schlechtes Beispiel dienen. 2. Viele arbeiten in der (Netzwerk-)Securitybranche, die sich nicht entwickelt haette, wenn Microsoft hochsichere Systeme designed haette bzw. designen wuerde und daher auch Ausloeser fuer die bekannten Alternativen ist/war. Hier sage ich nur: Danke Microsoft!
Ich bin mir nicht ganz sicher was diese ganze Lizenzgeschichte an der Stelle soll. Zum Einen steht Linux garnicht unter GPLv3 sondern nur unter GPLv2. Das heißt, der fragliche Paragraph zum Thema "Neuflashen muss möglich sein" steht überhaupt nicht zur Debatte. Zum Anderen würde es auch kein Problem darstellen, wenn dem nicht so wäre. Du integrierst in deinen Bootloader einfach einen Unlock-Befehl. Dieser löscht zunächst die Keys aus dem Utility-UC (überschreiben, sperren, wie auch immer), dann löscht er den kompletten Flash (außer sich selbst natürlich) und zuletzt setzt er die Bootloader-Keys auf einen Default-Wert. Nun kann jeder ein eigenes Image flashen. Wenn du dazu noch ein Image veröffentlichst, in dem du deinen proprietären Teil einfach weglässt/durch Stubs ersetzt dürftest du die GPLv3 erfüllen. Und das völlig ohne Nutzen für irgendwelche Angreifer. Linux und andere GPL-Lizensierte Software sind weit verbreitet und oft fast alternativlos, so dass der Einsatz rein von BSD/MIT-Lizensierter Software unnötig schwierig ist, zumal das Erfüllen der GPL nun echt kein Aufwand ist. Die Datenbank zu sichern scheint kompliziert, was genau sagt dein Vertrag hierzu aus? Mit dem Gedanken im Hinterkopf, dass das "Kopierschutz"-Bit auf Audio-CDs eine "wirksame technische Kopierschutzmaßnahme" ist, sollte es doch wohl reichen, keinen "normalen" Zugang zum System offen zu lassen. Mich würde vor allem aber interessieren, ob und wie es möglich ist, mit einem nicht vertrauenswürdigen System trotzdem vertrauenswürdige Signaturen/Daten zu erzeugen. Selbst falls ein (vertrauenswürdiger) Utility-UC die Signaturen erzeugt, wie stellt man sicher, dass keine gefakten Daten an diesen übergeben werden, ohne den Key dafür wieder im RAM stehen zu haben?
Guest schrieb: > Mich würde vor allem aber interessieren, ob und wie es möglich ist, mit > einem nicht vertrauenswürdigen System trotzdem vertrauenswürdige > Signaturen/Daten zu erzeugen. Gar nicht. Man kann lediglich verhindern, dass sich ein nicht vertrauenswürdiges System als vertrauenswürdiges System ausgibt, z.B. indem man statt einfacher Public-Key-Krypto digitale Zertifikate einsetzt, durch welche die Echtheit eines öffentlichen Schlüssels verifiziert werden kann. Lässt sich mit diesem Schlüssel dann die Authentizität einer Signatur verifizieren so bedeutet dies implizit, dass derjenige, der die Signatur erzeugt hat über den zum Zertifikat gehörigen privaten Schlüssel verfügt, und somit, da das Zertifikat erfolgreich verifiziert wurde, vertrauenswürdig ist. Guest schrieb: > Selbst falls ein (vertrauenswürdiger) > Utility-UC die Signaturen erzeugt, wie stellt man sicher, dass keine > gefakten Daten an diesen übergeben werden, ohne den Key dafür wieder im > RAM stehen zu haben? Indem man spezielle Security-Controller einsetzt welche über zugriffsgeschützten Speicher verfügen welcher ggf. geschrieben, aber nicht ausgelesen werden kann. So verfügen einige Security-Controller beispielsweise über Kryptobeschleuniger, welche ihre Schlüssel aus dedizierten Registern beziehen. Diese Register können zwar durch den Controller geschrieben, aber lediglich durch den Kryptobeschleuniger gelesen werden. Allerdings ist auch der Schreibzugriff in der Regel reglementiert, so dass man die Schlüssel ohne Berechtigung auch nicht ohne Weiteres austauschen kann. Häufig wird das erreicht, indem der Controller bereits ab Werk mindestens einen zufällig generierten ROM-Schlüssel besitzt, der weder ausgelesen noch überschrieben werden kann.
Daniel H. schrieb: > Gar nicht. Man kann lediglich verhindern, dass sich ein nicht > vertrauenswürdiges System als vertrauenswürdiges System ausgibt, z.B. > indem man statt einfacher Public-Key-Krypto digitale Zertifikate > einsetzt, durch welche die Echtheit eines öffentlichen Schlüssels > verifiziert werden kann. Lässt sich mit diesem Schlüssel dann die > Authentizität einer Signatur verifizieren so bedeutet dies implizit, > dass derjenige, der die Signatur erzeugt hat über den zum Zertifikat > gehörigen privaten Schlüssel verfügt, und somit, da das Zertifikat > erfolgreich verifiziert wurde, vertrauenswürdig ist. Das loest nicht sas Problem. Jemand koennte das System weiterhin kompromittieren und den legitimen priv key zum signieren verwenden. Daniel H. schrieb: > Indem man spezielle Security-Controller einsetzt welche über > zugriffsgeschützten Speicher verfügen welcher ggf. geschrieben, aber > nicht ausgelesen werden kann. So verfügen einige Security-Controller > beispielsweise über Kryptobeschleuniger, welche ihre Schlüssel aus > dedizierten Registern beziehen. Diese Register können zwar durch den > Controller geschrieben, aber lediglich durch den Kryptobeschleuniger > gelesen werden. Allerdings ist auch der Schreibzugriff in der Regel > reglementiert, so dass man die Schlüssel ohne Berechtigung auch nicht > ohne Weiteres austauschen kann. Häufig wird das erreicht, indem der > Controller bereits ab Werk mindestens einen zufällig generierten > ROM-Schlüssel besitzt, der weder ausgelesen noch überschrieben werden > kann. Das ist zwar gut und schoen, jedoch geht es um die Kommunikation mit dem Krypto-IC. Wie auch immer, nach einiger Diskussion ist die einzige Moeglichkeit ein solches System sicher zu bekommen die einzelnen Sensorwerte direkt, am bestenso frueh wie moeglich, also am besten gleich schon im Sensor zu signieren. Das kompromittierte Linux kann dann mit den Werten rechnen (lassen), und es ist nachvollziehbar ob die Werte je modifiziert wurden. Sprich, das Generieren der Daten muss in einer vertrauenswuerdigen Umgebung geschehen, der Rest ist egal.
Guest schrieb: > Jemand koennte das System weiterhin > kompromittieren und den legitimen priv key zum signieren verwenden. Nur wenn das System schlecht designed ist. Ein anspruchsvolleres System würde die Funktion zum Signieren nicht ohne weitere Schutzmaßnahmen, wie z.B. Challenge-Response-Protokolle, von außen zugreifbar machen. Guest schrieb: > Wie auch immer, nach einiger Diskussion ist die einzige Moeglichkeit ein > solches System sicher zu bekommen die einzelnen Sensorwerte direkt, am > bestenso frueh wie moeglich, also am besten gleich schon im Sensor zu > signieren. Vollkommen korrekt. Damit sind wir dann aber auch wieder an dem Punkt, dass die Schnittstelle zum Signieren nicht ohne Weiteres von außen zugänglich ist.
Detlef Granzow kann bei dem Thema sicherlich weiterhelfen ;)
Daniel H. schrieb: > Guest schrieb: >> Jemand koennte das System weiterhin >> kompromittieren und den legitimen priv key zum signieren verwenden. > > Nur wenn das System schlecht designed ist. Ein anspruchsvolleres System > würde die Funktion zum Signieren nicht ohne weitere Schutzmaßnahmen, wie > z.B. Challenge-Response-Protokolle, von außen zugreifbar machen. Das loest das Problem nicht, da der Algorithmus zum Durchfuehren des Challenge-Response Protokolls oder Aehnlichem samt Keys auf dem vertrauensunwuerdigen Linux Rechners gespeichert werden muss.
Wir können das Spielchen gerne weiter treiben. Am Ende wird sich immer irgendeine Besonderheit finden, bei der die Sicherheit weiter untergraben wird. Solange also nicht das vollständige System mit allen Teilnehmern, Kommunikationsrichtungen, schützenswerten Daten/Entitäten und vor allem Angreifermodellen und Angriffspfaden bekannt ist bringt es wenig sich von Sicherheitsfeature zu Sicherheitsfeature zu hangeln.
Horst schrieb: >> Soll das eine neue Implemtierung von geplanter Obsoleszenz werden? > > Nein. Eine wesentliche Funktion des Gerätes ist es, Daten aufzuzeichnen, > die "manipulationssicher" sind, d.h. die Hürden für eine Manipulation > werden mit technischen Maßnahmen erhöht. Dazu gehört es, die Daten mit > einer digitalen Signatur zu versehen. Das Gerät enthält den privaten > Schlüssel. Die öffentlichen Schlüssel aller unserer Geräte sind in der > Auslesesoftware hinterlegt, die wir als Stand-Alone-Programm und als DLL > für Drittanbieter zur Verfügung stellen. > > Dieses Vorgehen ist von der Zulassungsstelle für diese Geräte so > vorgeschrieben. > > Dass die Datenbank mit dem gleichen System geschützt wird, ist sozusagen > ein Abfallprodukt. Sag doch gleich, dass es um ein elektronisches Fahrtenbuch oder sowas geht ;)
Daniel H. schrieb: > Solange also nicht das vollständige System mit allen Teilnehmern, > Kommunikationsrichtungen, schützenswerten Daten/Entitäten und vor allem > Angreifermodellen und Angriffspfaden bekannt ist bringt es wenig sich > von Sicherheitsfeature zu Sicherheitsfeature zu hangeln. Es geht doch gerade darum, dass ein potentiell irgendwie kompromittiertes System Sensordaten erheben, verarbeiten und abspeichern. Dabei soll transparent sein, ob die Daten modifiziert wurden. Das ist im Grunde die Vollstaendige Problembeschreibung, mehr gibts dazu nicht zu sagen. Eine Loesung fuer das Problem waere es, die Sensordaten direkt im Sensor zu signieren. Beim weiterverarbeiten muessen dann die Werte-Signaturen mit gespeichert werden, so dass spaeter nachgerechnet werden kann. Da die Sensoren das nicht wirklich von selbst tun werden, ist der logische Schritt die Sensordaten in einem vertrauenswuerdigen UC einzulesen und dann direkt zu signieren bevor sie an den unvertrauenswuerdigen Prozessor gehen. Damit ist die einzige Manipulationschance die ein Angreifer hat dadurch gegeben, dass er die (analogen?) Sensoreingaenge direkt mit Fake-Daten beaufschlagen muss. Laut OP stellt das einen erheblichen Aufwand dar und ist dann anhand der Daten trotzdem ersichtlich. Faellt dir noch eine andere Loesung ein?
Bau doch einfach nen TPM Chip ein. Ist in jedem neueren Festplattenreceiver drin, wegen CI+. Im Kleingedruckten steht dann: "Bei einem Defekt des Motherboards sind alle Aufnahmen weg".
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.