Hallo Leute Ich habe gerade folgendes Problem in einer Studienarbeit: Mehrere Geräte verschiedener Hersteller sollen Daten an eine Steuerung senden. Die Kommunikation soll verschlüsselt erfolgen. Identische Schlüssel zu verwenden kommt nicht infrage diese ja bekannt werden könnten. Idee war jetzt mit einem asymetrischen Verfahren einen AES Schlüssel zu vereinbaren. Ich habe dabei jetzt folgendes Problem, wie ich es drehe und wende muss ja der Öffentliche Schlüssel über den Datenkanal ausgetauscht werden. Damit ist das ganze System aber kompromitierbar. Die einzige Möglichkeit die ich sehe ist, den Schlüssel auf eine andere nicht kompromitierbare weise in die geräte zu bringen.
geht nur mit einem gemeinsamen CA. Jedes Gerät bekommt ein Certifikat diesen ist von einer Zentralen stelle unterschrieben.
Das mit dem Zertifikat geht nicht, weil die Geräte nicht über Ethernet verbunden sind.
zppp schrieb: > Das mit dem Zertifikat geht nicht, weil die Geräte nicht über > Ethernet verbunden sind. was hat das mit Ethernet zu tun?
das ist doch der witz an asymetrischen verfahren, dass man mit dem öffentlichen schlüssel zwar ver- aber nicht entschlüsseln kann? zppp schrieb: > Die einzige Möglichkeit die ich sehe ist, den Schlüssel auf eine andere > nicht kompromitierbare weise in die geräte zu bringen. ich sehe das problem immer noch nicht...
zppp schrieb: > Ich habe dabei jetzt folgendes Problem, wie ich es drehe > und wende muss ja der Öffentliche Schlüssel über den Datenkanal > ausgetauscht werden. Damit ist das ganze System aber kompromitierbar. > Die einzige Möglichkeit die ich sehe ist, den Schlüssel auf eine andere > nicht kompromitierbare weise in die geräte zu bringen. Haben Sie sich schon mal gefragt warum der öffentliche Schlüssel eben öffentlicher Schlüssel heißt? Den können S' in der Zeitung abdrucken, auf ihre Homepage stellen und im Radio vorlesen lassen und das System ist dadurch trotzdem nicht kompromittiert. Das ist ja gerade die Idee der asymetrischen Verschlüsselung. Sie haben da zwei Keys, einen private und einen public wobei der Public eben öffentlich ist, den darf (und soll sogar) jeder kennen.
:
Bearbeitet durch User
zppp schrieb: > Damit ist das ganze System aber kompromitierbar. Was verstehst du unter "kompromitierbar"? 1) Dass jemand die Kommunikation durch Kenntnis des öffentlichen Schlüssels entschlüsseln kann? Eben nicht, das ist ja der Witz an der Sache. Entschlüsseln kann man nur mit dem privaten Schlüssel. 2) Dass irgendwelche Geräte irgendwelche Daten an deine Steuerung schicken. Das kann natürlich passieren. Wenn du das verhindern willst, dann musst du die Geräte irgendwie bekannt machen (Zertifikate, symmetrische Schlüssel,...). Kannst ja jedem Gerät einen eigenen Schlüssel geben. > Die einzige Möglichkeit die ich sehe ist, den Schlüssel auf eine andere > nicht kompromitierbare weise in die geräte zu bringen. Ist das ein Problem? Jedem Gerät sein eindeutiger Schlüssel und die Steuerung kennt eben alle Schlüssel. Ist auch deutlich performanter und einfacher als eine asynchrone Verschlüsselung.
innerand innerand schrieb: > Haben Sie sich schon mal gefragt warum der öffentliche Schlüssel eben > öffentlicher Schlüssel heißt? > > Den können S' in der Zeitung abdrucken, auf ihre Homepage stellen und im > Radio vorlesen lassen und das System ist dadurch trotzdem nicht > kompromittiert. doch ist es. Nennt sich http://de.wikipedia.org/wiki/Man-in-the-middle-Angriff weil man nicht Prüfen kann ob man den echten Publickey hat oder eine Fälschung
Hallo, irgendwie war das doch noch anders: der Client generiert ein Schlüsselpaar. Den einen verschlüsselt er mit dem öffentlichen Key und sendet ihn an den Server, der ihn mit dem privaten Key entschlüsselt. Ab jetzt unterhalten sich beide mit dem neuen Key, der dann auch jederzeit gewechselt werden kann. Der öffentliche Key wird also pro Verbindung nur ein einziges Mal benutzt. Gruß, Michael
:
Bearbeitet durch User
Progger schrieb: > 2) Dass irgendwelche Geräte irgendwelche Daten an deine Steuerung > schicken. Das kann natürlich passieren. Wenn du das verhindern willst, > dann musst du die Geräte irgendwie bekannt machen (Zertifikate, > symmetrische Schlüssel,...). Kannst ja jedem Gerät einen eigenen > Schlüssel geben. Das soll gerade verhindert werden. Das mit den Zertifikaten klappt auch nicht, dazu ist ein Internetzugang erforderlich. Das mit den individuellen Schlüssel geht leider nicht. Die müssen ja dann irgendwie der Steuerung bekannt gemacht werden. Die müssen ja auch abgelsen werden oder über eine unsichere Schnittstelle übertragen werden. Das Dieffie Hellmann scheint interesaant zu sein.
zppp schrieb: > Das mit den Zertifikaten klappt auch nicht, dazu ist ein > Internetzugang erforderlich. wer sagt das? Wozu sollte man dafür einen Internet Zugang brauchen?
zppp schrieb: > Das Dieffie Hellmann scheint interesaant zu sein. nein nicht für deinen zweck. DH stellt nur sicher das niemand die Daten mitlesen kann. Es kann aber nicht sicherstellen das man mit der richtigen Gegenstelle redet. Damit ist das System sehr einfach angreifbar.
Peter II schrieb: > doch ist es. Nennt sich > > http://de.wikipedia.org/wiki/Man-in-the-middle-Angriff > > weil man nicht Prüfen kann ob man den echten Publickey hat oder eine > Fälschung Quatsch. Public Keys sind zur Veröffentlichung gedacht und da kompromittiert nichts, wenn man die veröffentlicht. Die Verifikation, ob der Public Key auch tatsächlich auch zu dem gehört der er behauptet ist eine andere Geschichte. Aber diese Problem hat man immer, auch wenn man den Public Key daheim im Tressr versteckt. Dagegen hilft es zum Beispiel die Public Keys zu signieren und eine Chain-of-Trust aufzubauen. Aber wie gesagt, andere Geschichte.
Daher lässt man sich den öffentlichen Schlüssel von jemandem vertrauenswürdigen unterschreiben. Daraus resultiert dann halt das Prinzip -> Web of Trust Oder wenn man eine zentrale Instanz für die Beglaubigung hat -> PKI Bei beiden ist eine Netzwerkverbindung nicht unbedingt erforderlich, dann können halt keine Revokelisten geprüft werden. MitM ist dann nur ein Problem, wenn der Angreifer einen Key mit einer gültigen Unterschrift der vertrauenswürdigen Stelle vorweisen kann. Eine weitere Möglichkeit ist es, die gültigen öffentlichen Schlüssel oder deren Hashkeys als Liste auf allen Controllern zu hinterlegen.
Das dürfte auch für dich interessant sein: http://www.aborisov.de/publications/Diplomarbeit-Borisov.pdf
innerand innerand schrieb: > Quatsch. > Public Keys sind zur Veröffentlichung gedacht und da kompromittiert > nichts, wenn man die veröffentlicht. > > Die Verifikation, ob der Public Key auch tatsächlich auch zu dem gehört > der er behauptet ist eine andere Geschichte. Aber diese Problem hat man > immer, auch wenn man den Public Key daheim im Tressr versteckt. > > Dagegen hilft es zum Beispiel die Public Keys zu signieren und eine > Chain-of-Trust aufzubauen. > Aber wie gesagt, andere Geschichte. er will aber sicherstellen das nicht jeder Angreifer an seine Steuerung Daten schicken kann und da hilft ihm Private/Public key ohne Zertifikate nicht weiter.
Peter II schrieb: > wer sagt das? > > Wozu sollte man dafür einen Internet Zugang brauchen? Das sagen mir unsere Linux-Fuzzies. Zertifikate haben nur eine begrenzte Laufzeit und können auch widerrufen werden.
zppp schrieb: > Das mit den individuellen Schlüssel geht leider nicht. Die müssen > ja dann irgendwie der Steuerung bekannt gemacht werden. Die müssen > ja auch abgelsen werden oder über eine unsichere Schnittstelle > übertragen werden. Wie soll das funktionieren? Woher soll die Steuerung wissen, welche Geräte "gut" und welche Geräte "böse" sind? Das muss ihr jemand sagen. 1) indem die Schlüssel o.ä. schon vorher bekannt sind 2) asymmetrische Verschlüsselung und bei der ersten Kommunikation muss jemand (wohl ein Mensch) bestätigen, dass das Gerät "gut" ist. Dann können die Geräte sich über den verschlüsselten Kanal einen symmetrischen Schlüssel vereinbaren.
zppp schrieb: > Das sagen mir unsere Linux-Fuzzies. Zertifikate haben nur eine > begrenzte Laufzeit und können auch widerrufen werden. Das kannst Du ja frei entscheiden, ob Du diese Funktionen nutzen willst. Du kannst auch unbegrenzt gültige Zertifikate erstellen. Um die Gültigkeit überprüfen zu können, bräuchte die Steuerung aber ohnehin eine nicht manipulierbare Uhr. Das gleiche gilt für widerrufene Zertifikate: Ohne Internetzugang kann diese Information natürlich nicht abgerufen werden. Das gilt aber auch für jedes andere Verfahren, das Du Dir ausdenkst. Wenn Deine Schlüssel kompromitiert sind und die Steuerung nicht am Internet hängt, kannst Du sie nur durch ein manuelles Update wieder sicher machen.
zppp schrieb: > Das sagen mir unsere Linux-Fuzzies. Zertifikate haben nur eine > begrenzte Laufzeit und können auch widerrufen werden. die Laufzeit kann man frei festlegen - also auch bis 31.12.9999 wenn man es denn will. Sperrlisten sind Optional, das System funktioniert auch ohne. Das ist dann ein Problem wenn jemand es schafft den Privatekey aus einen gerät auszulesen und damit Unfug macht. Dann müsstest du jeden gerät mitteilen das dieses Zertifikat nicht mehr gültig ist.
zppp schrieb: > > Das sagen mir unsere Linux-Fuzzies. Zertifikate haben nur eine > begrenzte Laufzeit und können auch widerrufen werden. Zertifikate können eine begrenzte Laufzeit haben, müssen aber nicht. So ein Zertifikat ist letztendlich auch nur ein Key. Sie machen ganz einfach folgendes: Jedes Ihrer Geräte bekommt einen private (geheim) und einen Public-Key (öffentlich). Deren Public-Key signieren sie mit einem separaten Private Key (der bei ihnen bleibt) und ihre Geräte bekommen den Public-Key dazu (das wäre dann praktisch das Zertifikat). Dann konfigurieren Sie ihre Geräte noch so, dass sie nur Public-Keys die mit Ihrem Private Key signiert wurden akzeptieren.
Dann sagen dir deine Linux-Fuzzis etwas falsches. Schlüssel und Zertifikate kann man auch unbegrenzt gültig signieren. Macht man in der Regel aber nicht, da der Ablauf einen Sicherheitsgewinn bringt. Im Grunde sind innerhalb einer PKI auch alle Zertifikate von der Laufzeit der CA-Zertifikate abhängig. Mache dir mal Gedanken darüber, was das Ziel deiner Aktion ist. Wenn du die Authentizität der Daten prüfen möchtest, kannst Du jedem Controller sein eigenes Schlüsselpaar fest implementieren. Dabei wirst du schon genug Probleme habe, dieses so zu machen, dass die Keys nicht ausgelesen werden können. Zusätzlich signierst Du die öffentlichen Schlüssen mit einem zentralen Schlüsselpaar, dessen öffentlichen Schlüssen du ebenfalls fest in die Controller implementieren musst. Mit dem kannst du dann die Gültigkeit angebotenen Schlüssel prüfen. So oder ähnlich mache ich das in relativ geschlossenen System. Der Vorteil daran ist, das später noch weitere Controller in das System mit eigenen Schlüsselpaaren integriert werden können und dass das Schlüsselpaar für die Signatur der öffentlichen Schlüssen im Tresor liegt.
@zppp: Andersherum rangehen: Welche Angriffsvektoren siehst du mit welcher Wahrscheinlichkeit? Welche Hardware und welche Vernetzung der Geräte ist angedacht? Beipiel: Wenn du auf DH und KeyExchange verzichtest, sondern einen fest vorprogrammierten Key im System verwendest, der in jedem Gerät gleich ist, mußt du noch immer aus dem Quelltext eines Geräts den Schlüssel extrahieren. Gesetzt den Fall, es handelt sich um CAN-Geräte mit Controllern, die einen Speicherschutz auf Hardwareebene haben, muß sich ein Angreifer schon einiges einfallen lassen um da ran zu kommen. Handelt es sich um gewöhnliche PCs und ein Angreifer hat physischen Zugriff auf die Kiste, sieht die Sache schon ganz anders aus. Achja: Eine CA ist eine willkürlich festgelegte Instanz, der nur alle Trauen müssen. Das kann z.B. an einem CAN-Bus in einem Auto auch ein definiertes Steuerteil miterledigen.
:
Bearbeitet durch User
Ich sehe da sehr wenig Angriffsvektoren. Es handelt sich dabei um System die einer Zulassung durch eine Bundesbehörde benötigen. Mehr kann ich dazu leider nicht sagen weil das alles vertraulich ist. Es geht darum Komponenten und Steuerung von verschiedenen <6 Herstellern zu vernetzen. Die Kommunikation erfolgt über RS485 seriell. Ich hatte das schon ausgearbeitet mit AES. Dabei sollte ein einziges mal ein Schlüssel übertragen werden. Das wurde aber abgelehnt. Einen fixen Schlüssel zu verwenden ist bei mehr als einem Hersteller auch nicht sinnvoll, denn wenn der die Rund macht, sind alle Anlagen kompromitiert. Die andere Frage ist natürlich, wer sich die Mühe macht solche Systeme zu hacken. Wahrscheinlich nur Beamte auf dem Papier.
>Ich sehe da sehr wenig Angriffsvektoren. Ein erfolgreicher Angriffvektor genuegt, um ein ausgerolltes System zu kompromittieren! >Es handelt sich dabei um System die einer Zulassung durch eine >Bundesbehörde benötigen. Naja, da gibt es nicht viele Bundesbehörden, die das machen... Du meintest vermutlich Zertifizierung!? Egal, die notwendige Dokumentation des TOE wird nebem dem stimmigen Konzept, der Implementierung (bzw. die notwendige Methodologiedokumentation) noch viel groessere Kopfzerbrechen machen. Der Maßstab ist dann state-of-the-art. Selbst Profis in dem Bereich greifen auf Bewährtes zurueck (z.B. openssl). >Mehr kann ich dazu leider nicht sagen >weil das alles vertraulich ist. Es geht darum Komponenten und >Steuerung von verschiedenen <6 Herstellern zu vernetzen. Die >Kommunikation erfolgt über RS485 seriell. Ich hatte das schon >ausgearbeitet mit AES. Dabei sollte ein einziges mal ein Schlüssel >übertragen werden. Das wurde aber abgelehnt. Einen fixen Schlüssel >zu verwenden ist bei mehr als einem Hersteller auch nicht sinnvoll, >denn wenn der die Rund macht, sind alle Anlagen kompromitiert. State-of-the-Art im symetrischen Verschluesselungsbereich ist, dass ein solcher Kommunikationsschluessel nach x Megabyte bzw. nach y Stunden getauscht (z.B. durch die Verwendung einer PRF analog SSL/TLS --- z.B. bestimmt durch das ausgemachte gemeinsame Mastersecret beim DH/ECDH) wird. Daher der Schluckauf der "Beamten" bei diesem Punkt. Neben den obigen kleineren Problemchen wird die Ausrollung des Systems eine Rolle spielen, danach ist die Tendenz die Entropie genau anzusehen.... >Die andere Frage ist natürlich, wer sich die Mühe macht solche >Systeme zu hacken. Wahrscheinlich nur Beamte auf dem Papier. Um ein System auf dem CCC Kongress an das Kreuz zu nageln, tun "Hacker" ganz schoen viel, auch wenn nicht $$$ dahinterstehen.
Und warum gibst du nicht jedem Hersteller oder jedem Gerät (je nach Anzahl der Geräte) einen eigenen Schlüssel? Dann kannst du, wenn der Schlüssel bekannt wird, zumindest dem Hersteller dem er gehört eine auf den Deckel geben. Du könntest das sogar mit einer asymmetrischen Verschlüsselung lösen, weil der Schlüssel dann wirklich nur im Gerät des externen Herstellers sitzt und nicht in deiner Steuerung. Alle anderen "Lösungen" die ich hier gesehen habe erhöhen zwar die Komplexität, lösen aber dein Problem nicht. Da würde ich bei KISS bleiben.
Progger schrieb: > Und warum gibst du nicht jedem Hersteller oder jedem Gerät (je nach > Anzahl der Geräte) einen eigenen Schlüssel? Dann kannst du, wenn der > Schlüssel bekannt wird, zumindest dem Hersteller dem er gehört eine auf > den Deckel geben. und wie willst du einem Gerät Daten schicken wenn du den Schlüssel nicht kennst? > Alle anderen "Lösungen" die ich hier gesehen habe erhöhen zwar die > Komplexität, lösen aber dein Problem nicht. Da würde ich bei KISS > bleiben. Welches Problem bleibt denn noch bestehen wenn man mit Zertifikaten arbeitet? Machen übrigens auch BlueRay Player - die sperrlisten werden über aktuelle Disk verteilt. Also es geht auch alles Offline.
Peter II schrieb: > und wie willst du einem Gerät Daten schicken wenn du den Schlüssel nicht > kennst? Ihm den Schlüssel vorher "sagen"? > Welches Problem bleibt denn noch bestehen wenn man mit Zertifikaten > arbeitet? Ob Zertifikate oder Schlüssel ist in diesem Fall egal. Anderer Name für die selbe Sache. Zertifikate können halt mehr und sind daher potentiell komplexer. > Machen übrigens auch BlueRay Player - die sperrlisten werden über > aktuelle Disk verteilt. Also es geht auch alles Offline. Ja, da hat auch jeder Hersteller seinen eigenen Schlüssel. So wie auch von mir vorgeschlagen.
Man sollte sich den Prozess nochmals durchgehen lassen. Ein den Controller anfragendes Geraet muss sich also gegenuber dem Controller authentifizieren. Er muss dem controller etwas erzaehlen, sodass er vom Controller als glaubwuerdig erkannt wird. Kann dieser Prozess abgehoert werden? Kann der Prozess kompromitiert werden. Dann muss man eben noch eine Ebene drueber legen. Es muss fuer das Ganze ja nicht eine volle Kryptoapplikation werden.
zppp schrieb: > Es handelt sich dabei um System die einer Zulassung durch eine > Bundesbehörde benötigen. Mehr kann ich dazu leider nicht sagen > weil das alles vertraulich ist. Also meiner (wenigen) Erfahrung mit deutschen Behörden nach waren die Hürden nach Ausschreibung lächerlich niedrig, sodaß unser entwickeltes System mal als als "Kanonen auf Spatzen schießen" abgetan wurde. (Nein, es ging um mehr als um die Stufe 'vertraulich'). Ich denke, von der Sicht her hast du es eher Bedenken wegen des Fixen Schlüssels in Hardware zu tun. Denk dir einen zyklusmäßigen individuellen KeyExchange aus und alles wird gut.
Mit ein paar Einschränkungen geht das mit symmetrischen Algorithmen (z.B. AES): Bei der ersten Inbetriebnahme verteilt die Steuerung langlebige Schlüssel an die Geräte. Damit sind Gerät und Steuerung durch ein gemeinsames Geheimnis verbunden. Im Betrieb erzeugt die Steuerung regelmäßig kurzlebige Schlüssel (oft "Sitzungsschlüssel" genannt) und schickt diese, verschlüsselt mit dem jeweiligen gemeinsamen Geheimnis als Schlüssel, an die Geräte. Die Daten werden dann mit dem aktuellen Sitzungsschlüssel verschlüsselt. Damit hat die Steuerung bei korrekt empfangenen Daten die Gewissheit, daß die Daten vom richtigen Absender kommen und aktuell sind (jedenfalls nicht älter als der letzte Sitzungsschlüsselwechsel). Dazu ist es allerdings nötig, daß niemand die Kommunikation während der Erstinbetriebenahme abhört. Kann ja sein, daß man das sicherstellen kann (Montage und Test beim Hersteller); wenn nicht, braucht's eben "höhere" Mathematik (zu hoch für z.B. AVR): Diffie-Hellmann ist schon genannt worden. Ist auch ganz praktisch, um auf Anforderung ("Wartungstaste" bei Inbetriebnahme oder nach Austausch eines Gerätes) ein gemeinsames Geheimnis zu etablieren, allerdings ist Schutz gegen man-in-the-middle nötig, z.B. könnten Steuerung und Gerät eine Prüfsumme oder einen Hash des Geheimnisses anzeigen, und der Monteur muß eben vergleichen, ob die übereinstimmen. Wenn man es noch bequemer haben will (oder kein Display an jedem Gerät hat), sind asymmetrische Verfahren nötig. Jedes Gerät hat ein Schlüsselpaar und teilt der Steuerung seinen öffentlichen Schlüssel mit, damit die Steuerung ihm damit verschlüsselte Nachrichten schicken kann, die z.B. den Sitzungsschlüssel enthalten (oder ein gemeinsames Geheimnis, wenn die Steuerung keine Lust hat, alle Nase lang asymmetrische Algorithmen zu rechnen). Bleibt die Frage, woran die Steuerung erkennt, daß der öffentliche Schlüssel, den ein Kommunikationspartner vorlegt, echt ist (d.h. zu einem berechtigten Kommunikationspartner gehört). Dazu nimmt man Zertifikate. Ein Zertifikat ist ein Datensatz aus einem öffentlichen Schlüssel und irgendeiner Identitätsangabe (z.B. Seriennummer), sowie optional noch zusätzlichen Daten (die wir hier nicht brauchen), das ganze unterschrieben mit dem secret key einer sogenannten "certificate authority" (CA). Wer den öffentlichen Schlüssel der CA kennt, kann also ein Zertifikat prüfen, und weiß dann, daß diese CA einst der Meinung war, daß ein bestimmter öffentlicher Schlüssel zu einer bestimmten Seriennummer gehört. Zweckmäßigerweise betreibt jetzt jeder Hersteller eine CA, damit er jedem Gerät zu seiner Seriennummer auch ein Schlüsselpaar und ein Zertifikat mitgeben kann. Die Steuerung muß also den öffentlichen Schlüssel jeder Hersteller-CA kennen, dann können die Geräte jeweils zu ihrem öffentlichen Schlüssel auch das Zertifikat vorlegen, damit die Steuerung ihnen glauben kann. Und: jemand muß der Steuerung die Seriennummern der angeschlossenen Geräte verraten (whitelist). Alternativ kann die Steuerung natürlich auch einfach jedes Gerät mit Zertifikat akzeptieren, es sei denn, die Seriennummer ist ausdrücklich verboten (blacklist).
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.