Hallo, ich mache mir gerade Gedanken darueber wie es moeglich ist eine Verbindung zwischen Mikrocontroller und PC (z.B. Uart/USB) so zu sichern dass die Daten die dort uebertragen werden nicht mitgelesen werden koennen (z.B. fuer Reverse Engineering). Die Art der Verschluesselung ist erstmal egal (AES, XTEA, ...) die funktioniert sobald beide Kommunikationspartner einen gemeinsamen Schluessel haben. Nur wie kommen beide an diesen Schluessel? Die eine Moeglichkeit waere diesen fest vorzugeben. Sobald aber dieser mal oeffentlich bekannt wird (siehe BMW ConnectedDrive) waeren alle Geraete anfaellig. Die andere Moeglichkeit ist ein Schluesselaustausch (z.B. Diffie-Hellman). Hier ist mir nicht klar, wie man einen Man-in-the-middle Angriff vermeiden kann. Gibt es hier Zertifikatssysteme die das wirksam verhindern koennen? Hat jemand schon mal was in der Art realisiert? Gruss
Christoph S. schrieb: > Die eine Moeglichkeit waere diesen fest vorzugeben. Sobald aber dieser > mal oeffentlich bekannt wird (siehe BMW ConnectedDrive) waeren alle > Geraete anfaellig. Fahrzeuge haben individuelle Schlüssel, egal ob traditionelle mechanisch oder mittlerweile elektronisch. Das entspräche individuellen Schlüsseln, also pro Exemplar einer. Das ist auf kleinen Controllern realistisch machbar. > Die andere Moeglichkeit ist ein Schluesselaustausch (z.B. > Diffie-Hellman). Hier ist mir nicht klar, wie man einen > Man-in-the-middle Angriff vermeiden kann. Gibt es hier > Zertifikatssysteme die das wirksam verhindern koennen? Wenn man davon ausgeht, dass der individuelle(!) private Schlüssel des Controllers im Controller bleibt und nicht auslesbar ist, dann entspricht das dem üblichen Public Key Verfahren (z.B. PGP). Der Controller müsste sich dann nur einmalig bei einer Registrierungsstelle anmelden, dort seinen öffentlichen Schlüssel hinterlegen und jenen der PCs abholen. Alternativ kannst du mal reinspicken, wie Zertifikate und DH Key Exchange von TLS arbeiten. Solche Methoden würde ich aber auf einem ATtiny24 oder so nicht empfehlen.
A. K. schrieb: > Wenn man davon ausgeht, dass der individuelle(!) private Schlüssel des > Controllers im Controller bleibt und nicht auslesbar ist, dann > entspricht das dem üblichen Public Key Verfahren (z.B. PGP). Der > Controller müsste sich dann nur einmalig bei einer Registrierungsstelle > anmelden, dort seinen öffentlichen Schlüssel hinterlegen und jenen der > PCs abholen. Ein Angreifer koennte aber dann doch sich selbst ein Geraet bauen, dass einen oeffentlichen Schluessel an den PC schickt und so eine verschluesselte Verbindung damit herstellt. Dann koennte er schon an Informationen kommen welche das PC-Programm versendet oder?
Christoph S. schrieb: > Ein Angreifer koennte aber dann doch sich selbst ein Geraet bauen, dass > einen oeffentlichen Schluessel an den PC schickt und so eine > verschluesselte Verbindung damit herstellt. Dann koennte er schon an > Informationen kommen welche das PC-Programm versendet oder? Sicher. Deshalb sollte eine solche ursprüngliche einmalige Zertifizierung auch vertrauenswürdig sein. Auch bei PGP werden Schlüssel per Vertrauen beglaubigt. Es müsste also Teil der Produktion bzw. ursprünglichen Auslieferung sein.
Wie geschieht dies vertrauenswuerdig? Ein Sicherheitszertifikat welches der Controller schickt kann ja der Angreifer mitloggen und auch dieses benutzen oder?
Christoph S. schrieb: > Wie geschieht dies vertrauenswuerdig? Ein Sicherheitszertifikat welches > der Controller schickt kann ja der Angreifer mitloggen und auch dieses > benutzen oder? Wenn es keinen einzigen Zeitpunkt während der Lebensdauer eines Produktes gibt, der vertrauenswürdig ist, von Herstellung bis Verschrottung, dann kann es keine Sicherheit geben. Der Unterschied eines Public Key Systems zum individuellen symmetrischen Schlüssel ist der Speicherort von ebendiesem. Im PKS befindet er sich nur im Controller. Es muss aber sichergestellt sein, dass dessen öffentlicher Schlüssel zum richtigen Exemplar gehört, und hier kommt das Vertrauen hinein. Das muss Teil des Herstellungs- oder Verkaufsverfahren und vertrauenswürdig sein. Danach ist diese Phase durch und es ändert sich nichts mehr.
Klar, bei der Produktion z.B. gibt es einen Vertrauenswuerdigen Zeitpunkt. Dann muss ich mir aber den oeffentlichen Schluessel zu jedem Geraet speichern oder? Wenn ich das nicht mache und das Geraet gibt spaeter mal seinen oeffentlichen Schluessel aus mit dem ich dann einen Sitzungsschluessel fuer z.B. AES verschluessele dann kann das ja auch ein Angreifer sein der sich selbst ein Schluesselpaar (private/public) generiert hat.
Anderes Beispiel: TLS mit DH handelt den Transportschlüssel individuell aus. Mittendrin abhören ist nicht drin. Eine Endstelle live fälschen geht hingegen sehr wohl. Deshalb gibts im Web Zertifikate, damit du auch weisst, dass du mit deiner Bank redest, und nicht mit einem anderen Gauner.
Christoph S. schrieb: > Klar, bei der Produktion z.B. gibt es einen Vertrauenswuerdigen > Zeitpunkt. Dann muss ich mir aber den oeffentlichen Schluessel zu jedem > Geraet speichern oder? Ja. Allerdings darf diese Information dann öffentlich sein. Eine zentrale Datenbank individueller symmetrischer Schlüssel darf das nicht. Mit Zertifikaten läuft das wieder etwas anders. Was aber eine absolut verlässliche Zertifizierungsstelle voraussetzt, d.h. keine davon hergestellen falschen Zertifikate. Nur von dieser ausgestellte individuelle Geräte- und PC-Zertifikate sind dann zulässig. Funktioniert für beliebig viele PCs und Geräte.
Wenn alle oeffentlichen Schluessel gespeichert sind und jemand kommt an so einen oeffentlichen Schluessel kann er sich als PC ausgeben und mit dem Mikrocontroller eine Verbindung aufbauen, hat also auch eine Luecke oder? Wie wird verhindert dass ein Zertifikat geklaut wird? Hab zu dem Thema noch nicht viel gefunden.
Christoph S. schrieb: > Wenn alle oeffentlichen Schluessel gespeichert sind und jemand kommt an > so einen oeffentlichen Schluessel kann er sich als PC ausgeben und mit > dem Mikrocontroller eine Verbindung aufbauen, hat also auch eine Luecke > oder? Nein. Wenn das volle Programm vgl. PGP gefahren wird, dann muss auf jeder Seite der jeweilige private und öffentliche Schlüssel dieser Seite vorhanden sein, und der öffentliche Schlüssel des Gegenübers. Den öffentlichen Schlüssel eines PCs oder Gerätes zu kennen nützt bei diesem Verfahren überhaupt nichts. Drum heisst er "öffentlich". Zu Hintergründen bitte die einschlägige Literatur bemühen. Gibt genug dazu. Grundprinzip: Was mit dem privaten Schlüssel verschlüsselt wird ist nur mit dem öffentlichen Schlüssel entschlüsselbar, und umgekehrt. > Wie wird verhindert dass ein Zertifikat geklaut wird? Hab zu dem Thema > noch nicht viel gefunden. Auch Zertifikate haben 2 Teile, einen privaten und einen öffentlichen Teil. Der private Teil verlässt auch hier nie das zertifizierte Gerät. Dafür Sorge zu tragen, dass der jeweilige private Teil dein Gerät oder deinen PCs nie verlässt, das bleibt eine Aufgabe, die du schon selber lösen musst. Wenn alle Stricke reissen und der PC als notorisch unzuverlässig gilt, dann wird eine separate Schlüsselkarte für den PC erforderlich.
A. K. schrieb: > Auch Zertifikate haben 2 Teile, einen privaten und einen öffentlichen > Teil. Der private Teil verlässt nie das zugehörige Gerät. Dafür Sorge > zu tragen, dass der jeweilige private Schlüssel dein Gerät oder deinen > PCs nie verlässt, das bleibt eine Aufgabe, die du schon selber lösen > musst. Wenn alle Stricke reissen und der PC als notorisch unzuverlässig > gilt, dann wird eine separate Schlüsselkarte für den PC erforderlich. Klar, es gibt noch genuegend andere Einfallmoeglichkeiten, aber zuerst mal zur Kommunikation selbst. Wenn ich das Zertifikat, was ein Banken-Server ja an alle verschickt die sich mit ihm verbinden wollen einfach kopiere und das dann selbst an andere Schicke, wie stellen diese dann fest dass ich eigentlich nicht der Besitzer dieses Zertifikates bin? Steh glaub ein wenig auf der Leitung...
Christoph S. schrieb: > Wenn ich das Zertifikat, was ein Banken-Server ja an alle verschickt Den privaten Teil dieses Zertifikats kennt nur der Bank-Server und der wird diesen Teil garantiert nicht in die Welt blasen. > sich mit ihm verbinden wollen einfach kopiere und das dann selbst an > andere Schicke, wie stellen diese dann fest dass ich eigentlich nicht > der Besitzer dieses Zertifikates bin? Weil du dann zwar den öffentlichen Teil seines Zertifikates hast, aber nicht den privaten. Und damit kannst du dir nichts kaufen. Mal krass verkürzt skizziert: Was jemand an die Bank schickt, dass wird mit dem öffentlichem Schlüssel der Bank verschlüsselt. Verfahrensbedingt kann das nur die Bank mit ihrem privaten Schlüssel entschlüsseln. Niemand sonst.
A. K. schrieb: > Den privaten Teil dieses Zertifikats kennt nur der Bank-Server und der > wird diesen Teil garantiert nicht in die Welt blasen. Das ist mir klar. > Weil du dann zwar den öffentlichen Teil seines Zertifikates hast, aber > nicht den privaten. Und damit kannst du dir nichts kaufen. > Mal krass verkürzt skizziert: Was du an die Bank schickst, dass wird mit > deren öffentlichem Schlüssel verschlüsselt. Verfahrensbedingt kann das > aber nur die Bank mit ihrem privaten Schlüssel entschlüsseln. Niemand > sonst. Das Zertifikat besteht ja aus ein paar Informationen die unverschluesselt sind sowie einem Hash darueber der mit dem privaten Schluessel der Bank verschluesselt ist. Wie wird verhindert dass ich die offenen Informationen nutze und mir selbst den Hash berechne und mit eigenem Schluessel verschluessele?
Christoph S. schrieb: > Wie wird verhindert dass ich die > offenen Informationen nutze Überhaupt nicht. Nur kannst du der Bank ebenso gut auch einen Salatkopf schicken, um eine Überweisung zu tätigen. Wenn man vom möglichen Mittagessen des Bankmitarbeiters absieht hat das den gleichen Nutzen. Details zu diesen Verfahren sind im Internet reichlich nachzulesen. Bitte dort weitersuchen. Zumal ich ziemlich sicher bin, dass du solche Verfahren nicht mit normalen µCs einsetzen wirst. Unterhalb von Raspberries ist das hässlich viel Arbeit (wenn nicht fertig bezogen) und in Geräten dieser Klasse ist alles schon drin.
A. K. schrieb: > Zumal ich ziemlich sicher bin, dass du solche > Verfahren nicht mit normalen µCs einsetzen wirst. Gibts da noch weitere Verfahren, die auch performant auf einem Cortex-M3 z.B. laufen? Hast du sowas schon mal verwendet? Kannst du Literatur zu den Themen empfehlen?
Der Cortex M3 ist performant genug, aber du solltest den Code lieber nicht selber schreiben wollen. ;-)
Christoph S. schrieb: > Das Zertifikat besteht ja aus ein paar Informationen die > unverschluesselt sind sowie einem Hash darueber der mit dem privaten > Schluessel der Bank verschluesselt ist. Wie wird verhindert dass ich die > offenen Informationen nutze und mir selbst den Hash berechne und mit > eigenem Schluessel verschluessele? Du solltest Dir nochmal das genaue Verfahren ansehen. Public Key basiert auf vertrauen. Natürlich kannst Du ein Zertifkat fälschen, also fremde Informationen mit Deiner Unterschrift versehen. Das ist die Schwachsteller von selbst signierten Zertifikaten. Der Trick ist dabei, dass noch andere das Zertifikat unterschrieben haben. In den meisten Fällen eine Zertifizierungsstelle. Wenn Du dieser Stelle trauen kannst, ist alles in Butter. Alternativ kannst Du dir über einen vertrauenswürdigen Weg eine Art Unterschriftenprobe geben lassen. Damit hast Du den öffentlichen Schlüssel der Gegenstelle und kannst prüfen, ob vermeintliche Nachrichten dieser Stelle korrekt sind. Ein Fälscher kann zwar selber ein Zertifikat erstellen, es passt aber nicht zur Unterschriftenprobe und wird so schnell als Fälschung erkannt.
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.