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.
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.
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
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.
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.
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).
