Guten Tag, ich habe vor mehrere Mikrocontroller ueber ein Funknetzwerk zu verbinden. Diese sollen sich gegenseitig Befehle senden. Bei der Analyse trat allerdings das Problem auf, dass ein Angreifer die Funkpakete (Befehle) spoofen koennte und dann die exakt gleichen Pakete neu generiert. Damit waere es moeglich, die Anlage von aussen zu uebernehmen. Um das zu verhindern, dachte ich daran die Pakete zu verschluesseln (Microchip bietet fuer PIC ja AES-Libs an). Allerdings behebt das das Problem nicht, denn auch verschluesselte Pakete lassen sich spoofen und rekonstruieren. Das der Befehl als kryptischer Code keinen Sinn ergibt ist egal, die Funktion liesse sich von einem Beobachter durch Beobachtung empirisch ermitteln. Schlussendlich landete ich bei digitalen Signaturen (assymetr. Verschluesselung), auch hier gleiches Problem wie bei symmetr. Verschluesselung. Ich dachte kurz daran den Befehlen Primzahlen zuzuorden und diese multipliziert mit anderen (groesseren) Primzahlen als Befehl zu verschicken. Der empfaenger zerlegt diese und die kleinste Primzahl bestimmt den Befehl. Auch hier das gleiche Problem wie bei symm. Verschluesselung, bis auf das es "mehrere" Befehle gibt, die die gleiche Aktion ausloesen. Zudem wird es bei groesseren Primzahlen vermutlich Laufzeitprobleme geben. Weiss jemand, wie man dieses Problem richtig und sauber loest? Bin ja nicht der erste, der versucht ein annaehernd sicheres Funknetz aufzubauen. Habe mir uebrigens zur weiteren Einarbeitung ein Kryptographie Buch bestellt: https://www.dpunkt.de/buecher/11884/Kryptografie.html Mit freundlichen Gruessen PS: Bin nicht in DE, daher "ae", "ue", "oe" und "ss"
Willst Du es selber bauen oder suchst Du möglichst eine Lösung? Hier ein selbstkonfigurierendes Netzwerk mit AES-Verschlüsselung: https://tiny-mesh.com/index.html Gibt es auch in fertiger Modulform
Da gibt es ein paar simple herangehensweisen die mir so spontan einfallen: 1. Der Empfänger eines Befehls wird zuerst um einen zusätzlichen Schlüssel gebeten. Dieser geht in die Verschlüsselung mit ein. Bei Empfang des Befehls prüft der Empfänger, ob der übertragene Zusatzschlüssel mit dem zuvor gesendeten übereinstimmt. Für jeden Befehl wird ein neuer Zusatzschlüssel erzeugt. 2. Minimal unintuitiver, dafür ohne Austausch eines zusätzlichen Schlüssels. Die Teilnehmer einigen sich zu Beginn auf einen Startwert dieses Zusatzschlüssels (oder beginnen immer mit einem festen Wert). Für den nächsten Befehl wird einfahc der nächsthöhere Wert genommen. Natürlich gibt es deutlich ausgefeiltere und sicherere Ansätze.
H. schrieb: > Willst Du es selber bauen oder suchst Du möglichst eine Lösung? Ich moechte es selbst entwickeln/bauen. Danke allerdings fuer den Link, werde ich mir mal ansehen. Samuel C. schrieb: > 1. Der Empfänger eines Befehls wird zuerst um einen zusätzlichen > Schlüssel gebeten. Dieser geht in die Verschlüsselung mit ein. Bei > Empfang des Befehls prüft der Empfänger, ob der übertragene > Zusatzschlüssel mit dem zuvor gesendeten übereinstimmt. Für jeden Befehl > wird ein neuer Zusatzschlüssel erzeugt. Danke, klingt nach einem guten Ansatz. Allerdings koennte ein Angreifer das Protokoll analysieren und dann selbst Schluessel anfordern und verschluesseln. Gibt es hier Kryptologen? Wie lange braeuchtet ihr, um auf so einen Ansatz zu kommen?
Eine weitere Möglichkeit gegen Replay-Angriffe ist, die Wiederholung zu erkennen. Wenn Daten verschlüsselt und/oder digital signiert übertragen werden, musst du zusätzlich eine eindeutige Zahlenfolge mitsenden... Das kann eine zufällig generierte UUID sein, ein Zahleninkrement, oder ein Zeitstempel, je nach Anwendungsfall. Der Empfänger kann sich dann merken welche Pakete er schon bearbeitet hat und reagiert auf eine Wiederholung einfach nicht mehr. Ob du soetwas einsetzen kannst ist vor allem von einen Ressourcen abhängig und/oder wie häufig kommuniziert wird. Sich alle je verarbeiteten IDs zu merken schafft natürlich kein µC. Angenommen aber du hast an jedem Knoten im Netzwerk eine halbwegs genaue Uhrzeit parat und deine Knoten senden auch nicht unbedingt mehrmals pro Sekunde Daten, würde es z.B. ausreichen sich einfach den letzten Zeitstempel zu merken. Kommt dann ein weiteres Datenpaket mit gleichem oder älterem Zeitstempel, wird es verworfen. Nur jüngere Zeitstempel werden akzeptiert. Selbiges geht auch mit einem simplen Ikrement statt der Zeit, sofern du es schaffst dass alle Teilnehmer jeweils das zuletzt genutzte Ikrement kennen (z.B. weil alle der Kommunikation lauschen können). Wichtig ist also: 1) Integrität der Nachricht sicherstellen (z.B. durch digitale Signatur oder Verschlüsselung inkl. Manipulationserkennung) 2) Eindeutigkeit der Nachricht sicherstellen (z.B. durch eindeutige Werte die du als "verbrannt" markieren kannst)
Habe mir gerade mal Perfect Forward Secrecy [1] angesehen. Hier der uebertragene Ansatz: 1. Der Befehlsgeber broadcastet einen zufaellig generierten Verschluesselungskey, der assymetrisch verschluesselt ist. 2. Die Steuerungen koennen den Key entschluesseln, da sie den oeffentlichen Schluessel haben. 3. Daraufhin werden alle Befehle/Informationen mit diesem Key symmetrisch verschluesselt. Ab diesem Punkt tritt wieder die Reproduktionsproblematik auf, ein Angreifer koennte Pakekte lesen und exakt so erneut senden. Daher wird der Schluesselaustausch (1-2) ca. alle 10min wiederholt. Ich denke diese Unsicherheit ist hinnehmbar. Was haltet ihr von diesem Ansatz? Hauptproblem wird vermutlich die Implementierung von assymetrischer Verschluesselung. [1] http://www.heise.de/security/artikel/Zukunftssicher-Verschluesseln-mit-Perfect-Forward-Secrecy-1923800.html
Tom schrieb: > Eine weitere Möglichkeit gegen Replay-Angriffe ist, die Wiederholung zu > erkennen. [...] Auch ein sehr schoener Ansatz. Vielen Dank, ich lasse mir das alles noch ein wenig durch den Kopf gehen.
Danish B. schrieb: > Habe mir gerade mal Perfect Forward Secrecy [1] angesehen. Hier der > uebertragene Ansatz: > [...] > Ab diesem Punkt tritt wieder die Reproduktionsproblematik auf, ein > Angreifer koennte Pakekte lesen und exakt so erneut senden. > Daher wird der Schluesselaustausch (1-2) ca. alle 10min wiederholt. Ich > denke diese Unsicherheit ist hinnehmbar. > > Was haltet ihr von diesem Ansatz? > > Hauptproblem wird vermutlich die Implementierung von assymetrischer > Verschluesselung. > [1] > http://www.heise.de/security/artikel/Zukunftssicher-Verschluesseln-mit-Perfect-Forward-Secrecy-1923800.html Und diese Vorgehensweise könntest du doch jetzt zum Beispielt mit sich ständig ändernden Metadaten kombinieren. Gleich die ganzen Schlüssel zu ändern ist unnötig hoher Aufwand und schützt dich innerhalb dieser 10 Minuten nicht.
Danish B. schrieb: > Ab diesem Punkt tritt wieder die Reproduktionsproblematik auf, ein > Angreifer koennte Pakekte lesen und exakt so erneut senden. > Daher wird der Schluesselaustausch (1-2) ca. alle 10min wiederholt. Ich > denke diese Unsicherheit ist hinnehmbar. > > Was haltet ihr von diesem Ansatz? Je nach Einsatzszenario nicht viel... Denk z.B. an den Funkschlüssel eines Autos der ggf. einfach nur ein Toggle-Signal sendet (also das selbe für auf und zu, weil man das Ergebnis eh besser am Blinken/Tuten des Autos überprüft). Wenn ich da aufzeichnen kann wie jemand sein Auto absperrt und dann 10min Zeit habe es durch Replay wieder aufzusperren, ist das schon ein großes Problem :D > Hauptproblem wird vermutlich die Implementierung von assymetrischer > Verschluesselung. Richtig, für µCs mag das schon sehr kostspielig sein... Asymetrische Kryptographie braucht es aber nicht... Es reicht ein MAC (message authentication code) mit einer billigen Hash-Funktion wie MD5 oder SHA-1. Beispiel-Implementierung: Alle Teilnehmer kennen einen geheimen Schlüssel namens "SECRET". Nun möchte ich als Sender "TÜR AUF" senden. Ich sende nun "TÜR AUF" zusammen mit dem MAC von "TÜR AUF" der z.B. einfach aus dem MD5-Hash meiner Nachricht und dem Geheimnis gebildet wird. Nehmen wir also an das Ergebnis von MD5("TÜR AUF + SECRET") wäre "BEEF0815", sende ich "TÜR AUF BEEF0815"... Der Empfänger schaut sich das an und kann den MAC prüfen, weil er ja die Nachricht "TÜR AUF" bekommen hat und auch den MAC "BEEF0815", den er zur Kontrolle einfach selbst aus der Nachricht "TÜR AUF" und dem Geheimnis, das er ja auch kennt, bildet und abgleicht. Stimmt der MAC, ist Bedingung 1) erfüllt, nämlich dass diese Nachricht garantiert von einem authentischen Absender generiert wurde. Nicht sichergestellt ist aber, dass diese Nachricht nicht ggf. jemand kopiert und erneut gesendet hat, denn auch dann ist der MAC ja eben gültig. Jetzt kommt eben noch die eindeutige Zahl ins Spiel. Statt "TÜR AUF" sende ich hald "TÜR AUF 42". Der Empfänger merkt sich dann, dass er für "42" (und kleiner) schonmal die Tür geöffnet hat ud macht dies künftig nur für "43" und größer usw... Der Sender erhöht jedes mal seinen Wert wenn er sendet. Schon kann eine kopierte Nachricht nicht mehr verwendet werden. Das kommt ohne Verschlüsselung aus und ist auch auf einem µC relativ einfach zu implementieren. Je nach Anwendungsfall gibts aber natürlich weitere Dinge die man beachten muss... Wenn man mehrere Teilnehmer hat, muss man dafür sorgen dass alle stets die ID kennen die als nächstes verwendet werden soll. Wenn die möglichkeit besteht Nachrichten abzufangen, muss man überlegen ob es ein Problem sein kann wenn diese eingespielt werden.... (Analog zum Auto kann ich z.B. eine Türöffner-Nachricht aufzeichnen und dann auch tatsächlich nutzen, sofern das Auto selbst die erste Nachricht nicht empfangen hat und somit nicht verbrannt hat).
Tom schrieb: > Beispiel-Implementierung: > > Alle Teilnehmer kennen einen geheimen Schlüssel namens "SECRET". > Nun möchte ich als Sender "TÜR AUF" senden. > Ich sende nun "TÜR AUF" zusammen mit dem MAC von "TÜR AUF" der z.B. > einfach aus dem MD5-Hash meiner Nachricht und dem Geheimnis gebildet > wird. Nehmen wir also an das Ergebnis von MD5("TÜR AUF + SECRET") wäre > "BEEF0815", sende ich "TÜR AUF BEEF0815"... Genialer Ansatz, allerdings muss der Befehlsgeber, dann zu jedem Befehl und der aktuellen ID den entsprechenden Hash-Generieren. Aber niemand hat gesagt, dass Sicherheit umsonst ist... Vielen Dank an alle.
Ich bin schon sehr beeindruckt dass du überhaupt so weit denkst. 99% der heute im Umlauf befindlichen IoT Geräte etc. haben solche Gedanken vor der Implementierung vermutlich nie genossen :D Großes Daumen hoch :)
Aus der Anfrage gehen drei Anforderungen hervor: - Verschlüsselung der Kommunikation - Integrität der Kommunikationsstrecke - Integrität der Daten Verschlüsselung kann man mit der erwähnten AES Lib machen. Bei der Integrität der Kommunikationsstrecke geht es darum, dass man sicherstellen will, dass die Kommunikationspartner tatsächlich berechtigt sind, miteinander zu kommunizieren. Bei der Integrität der Daten geht es darum, dass die Daten unverfälscht hin und her gehen. -> üblicherweise eine Checksumme Vorschlag Integrität der Kommunikationsstrecke: Asymetrisch verschlüsseln - Jede Komponente hat die öffentlichen Schlüssel der anderen Komponenten. Sender verschlüsseln die Daten mit ihrem privaten Schlüssel. Entschlüsselt wird mit dem öffentlichen Schlüssel. Um Replay- oder Spoofing-Angriffe zu vermeiden, kann man (im einfachsten Fall) einen Botschafts-Zähler in die verschlüsselte Botschaft aufnehmen Problem beim Zähler: Was ist, wenn eine Botschaft nicht empfangen wird und wiederholt werden muss.
Danish B. schrieb: > Genialer Ansatz, Kindergarten-Ansatz... Kann man simpelst aufzeichnen und beliebig wieder abspielen. Ohne Rollcode ist das Bullshit - und selbst ein Rollcode ist eigentlich schwach, muss man nur ein paar mal mitschneiden und dann kann man den nächsten berechnen. Ohne Verschlüsselung wird das nix
Danish B. schrieb: > ich habe vor mehrere Mikrocontroller ueber ein Funknetzwerk zu > verbinden. Diese sollen sich gegenseitig Befehle senden. Diesen Ansatz würde ich einmal überdenken. In einem verteilten Sytem ist es an und für sich nicht üblich, dass jedes Subsystem jedem anderen Subsystem Befehle erteilen kann.
Alex schrieb: > Danish B. schrieb: >> Genialer Ansatz, > > Kindergarten-Ansatz... > Kann man simpelst aufzeichnen und beliebig wieder abspielen. > Ohne Rollcode ist das Bullshit - und selbst ein Rollcode ist > eigentlich schwach, muss man nur ein paar mal mitschneiden und dann > kann man den nächsten berechnen. Ohne Verschlüsselung wird das nix Eine Ahnung und keine Argumente haben, aber große aufplustern :D So Leute sind dann schuld dran, wenn eine "total sicheres System, weil nutzt ja AES-65537" innerhalb von Sekunden zerlegt wird... Verschlüsselung war hier weder eine Anforderung des TE, noch löst sie irgendein Problem. Verschlüsselung schützt weder vor Replay-Angriffen, noch vor Manipulation der Daten. Und gerade bei so trivialen Datenübertragungen wahrt sie nicht einmal die Vertraulichkeit. Der TE schreibt ja selbst, dass man weiss was das Datenpaket tut, ohne es überhaupt sehen zu müssen. Verschlüsselung ist hier vermutlich totaler Blödsinn und in Anbetracht der Kosten für einen µC purer - wenn nicht unbezahlbarer - Luxus. Du hast recht, eine Nachricht mit MAC kann kopiert und beliebig oft wiederverwendet werden. Allerdings war das ja auch nur ein Teil des Konzeptes, das du offensichtlich nicht verstanden hast. Erst durch die ID werden Replay-Angriffe unterbunden. Und wenn du mit "Rollcode" die von mir genannte ID meinst, sei dir versichert, es ist völlig egal ob der Angreifer die nächste ID kennt. Was hilft es ihm, wenn er weiss, dass die nächste gültige ID nach 42 die 43 ist? Rein Garnichts, denn er kann zwar die Nachricht "TÜR AUF 43" konstruieren, aber ohne das Geheimnis zu kennen, kann er für diese Nachricht keinen MAC erzeugen. Somit ist auch kein Angriff möglich.
Tom schrieb: > Verschlüsselung war hier weder eine Anforderung des TE, noch löst sie Äh - lies nochmal oben: "Um das zu verhindern, dachte ich daran die Pakete zu verschluesseln " Das, was du - lieber Tom - vorgeschlagen hast (MAC, MD5, Secret) ist untauglich. Das nehme ich auf und spiele es wieder ab und die Tür ist auf. Eine ID hast du weiter oben mal erwähnt, aber nicht in dem von mir kritisierten Vorschlag. Also was willst du eigentlich..?
Alex schrieb: > Äh - lies nochmal oben: > "Um das zu verhindern, dachte ich daran die Pakete zu verschluesseln " Richtig, er dachte daran zu verschlüsseln, weil er dachte, das wäre eine Lösung. Kurz darauf hat er selbst festgestellt, dass ihn das aber nicht zum Ziel bringt. Ich wiederhole: Verschlüsselung war keine Anforderung des TE. Es war ein von ihm versuchter und nicht mit erfolg gekrönter Lösungsversuch, weshalb er hier um Hilfe bat. > Das, was du - lieber Tom - vorgeschlagen hast (MAC, MD5, Secret) ist > untauglich. Das nehme ich auf und spiele es wieder ab und die Tür ist > auf. (MAC, MD5, Secret) ist untauglich, ja. Mein Vorschlag aber nicht, denn der besteht us mehr. > Eine ID hast du weiter oben mal erwähnt, aber nicht in dem von mir > kritisierten Vorschlag. Also was willst du eigentlich..? Der von dir kritisierte Vorschlag enthält aber mehr. Du hast dich nur auf das Teil-Zitat bezogen. Das für sich genommen war nicht ausreichend, ja. Aber es war eben nur ein Teil-Zitat. Im Gegensatz zu dir hat der TE aber wohl mein Gesamtes Konzept gelesen und sich nicht nur auf Teil-Zitate daraus bezogen.
Mark B. schrieb: > Diesen Ansatz würde ich einmal überdenken. In einem verteilten Sytem ist > es an und für sich nicht üblich, dass jedes Subsystem jedem anderen > Subsystem Befehle erteilen kann. Doch. CAN, Z-Wave, Ethernet...
Alex schrieb: > Kindergarten-Ansatz... > Kann man simpelst aufzeichnen und beliebig wieder abspielen. > Ohne Rollcode ist das Bullshit - und selbst ein Rollcode ist > eigentlich schwach, muss man nur ein paar mal mitschneiden und dann > kann man den nächsten berechnen. Ohne Verschlüsselung wird das nix Alex schrieb: > Das nehme ich auf und spiele es wieder ab und die Tür ist > auf. Ok, dann erklaer mir bitte wie. Hier der Mitschnitt. Im Gegensatz zur verbauten Hardware bin ich noch so guetig, dir zu sagen, dass ich mit diesen Befehlen 3mal die Tuer oeffne (ohne zwischendurch zu verriegeln). md5 14e230c8e1ee79b93be28f04cd0d3656 md5 f43e7097616e2b119f157bd610995e86 md5 74946e2420ccd8e71aeb93f6396e4ee7 Bitte nenne mir den naechsten Hash, der die Tuer oeffnet.
Meine 2 Pfennig: "Don't roll your own crypto" (unless you have a team of cryptographers)! Das Problem ist algorithmisch schon lange erfolgreich gelöst: https://de.wikipedia.org/wiki/Zero-Knowledge-Beweis "...Bei einem Zero-Knowledge-Protokoll kommunizieren zwei Parteien (der Beweiser und der Verifizierer) miteinander. Der Beweiser überzeugt dabei den Verifizierer mit einer gewissen Wahrscheinlichkeit davon, dass er ein Geheimnis kennt, ohne dabei Informationen über das Geheimnis selbst bekannt zu geben..." und https://de.wikipedia.org/wiki/Schl%C3%BCsselaustauschprotokoll z.B. https://de.wikipedia.org/wiki/Diffie-Hellman-Schl%C3%BCsselaustausch "Der Diffie-Hellman-Schlüsselaustausch [...] ist ein Schlüsselaustauschprotokoll. Dieses ermöglicht, dass zwei Kommunikationspartner über eine öffentliche, abhörbare Leitung einen gemeinsamen geheimen Schlüssel in Form einer Zahl vereinbaren können, den nur diese kennen und ein potenzieller Lauscher nicht berechnen kann. Der dadurch vereinbarte Schlüssel kann anschließend für ein symmetrisches Kryptosystem verwendet werden (beispielsweise Data Encryption Standard oder Advanced Encryption Standard)." Der erste Kontakt mit Kryptographie ist immer "kann so schwer nicht sein, hab das Paper gefunden", nach den folgenden 5 Jahren an Flüchen kommt die Erkenntnis: Nimm was fertiges. Programmier den Algorithmus selber, guck dir an, was wo zusammenarbeitet, schmeiß es weg und lade eine Crypto-Lib runter. Ist zugegeben im embedded-Bereich schwieriger als auf dem PC, wo es massig Speicher und CPU-Zyklen gibt. Aber machbar! Ein gut gemeinter Tipp: Wenn das ganze industriell sein soll, lass es von einer Fachfirma in und auswändig prüfen! Ich drück dir beide Daumen und sämtliche Zehen!
Moe S. schrieb: > Meine 2 Pfennig: "Don't roll your own crypto" (unless you have a > team of > cryptographers)! Meine 2 cent dazu... Wenn man die Krypto nicht versteht, sollte man auch keine fertigen Libs anwenden. Wenn man das tut, kommen z.B. so beliebte proprietäre Funk-Tastaturen bei raus, die zwar jeden Tastenanschlag einzeln verschlüsseln (mit bewährter Crypto-Lib), dadurch aber trotzdem nicht sicherer sind als würden sie gleich im Klartext senden... :) Klar sollte man etablierte Mechanismen anwenden, dazu zählen eben Hashes, MACs, digitale Signaturen, Asymetrische kryptographie usw... aber man muss auch verstehen sie korrekt anzuwenden.
Moe S. schrieb: > Der erste Kontakt mit Kryptographie ist immer "kann so schwer nicht > sein, hab das Paper gefunden", nach den folgenden 5 Jahren an Flüchen > kommt die Erkenntnis: Nimm was fertiges. > Programmier den Algorithmus selber, guck dir an, was wo > zusammenarbeitet, schmeiß es weg und lade eine Crypto-Lib runter. > Ist zugegeben im embedded-Bereich schwieriger als auf dem PC, wo es > massig Speicher und CPU-Zyklen gibt. Aber machbar! > Ein gut gemeinter Tipp: Wenn das ganze industriell sein soll, lass es > von einer Fachfirma in und auswändig prüfen! Ja, da hast du Recht. Allerdings habe ich mittlerweile einen grossen Respekt vor Kryptographie. Sollte ich wirklich einen Algorithmus selbst implementieren muessen, dann wuerde ich mir vorher entsprechende Literatur besorgen. z.B. Das hier: https://www.schneier.com/books/applied_cryptography/ Der Lerneffekt ist bei selbst-programmierten Loesungen auch deutlich hoeher... Eigentlich wollte ich gerade schreiben "Kann mir nicht vorstellen, dass der Vorschlag von Tom irgendwie geknackt werden soll". Aber das ist ja das Problem, das du ansprichst. Als nicht-kryptograph kann man sich das alles nicht vorstellen. Vielen Dank fuer deinen warnenden Kommentar.
Alex schrieb: > Mark B. schrieb: >> Diesen Ansatz würde ich einmal überdenken. In einem verteilten Sytem ist >> es an und für sich nicht üblich, dass jedes Subsystem jedem anderen >> Subsystem Befehle erteilen kann. > > Doch. > CAN, Z-Wave, Ethernet... Du redest von Bussystemen. Ich rede von einer Architekturentscheidung.
Danish B. schrieb: > Eigentlich wollte ich gerade schreiben "Kann mir nicht vorstellen, dass > der Vorschlag von Tom irgendwie geknackt werden soll". > Aber das ist ja das Problem, das du ansprichst. Als nicht-kryptograph > kann man sich das alles nicht vorstellen. Deswegen mach frühzeitig das was ich hier auch gemacht habe: Mach das gesamte Konzept völlig öffentlich. Nur so wird man einen ggf. doch existierenden Fehler auch halbwegs zuverlässig finden ;)
Wenn du auf jedem Controller eine genaue Uhrzeit hast, kannst du auch die Zeit in die Verschlüsselung einfließen lassen. Zeit und Schlüssel mit XOR verknüpfen und dann mit AES verschlüsseln. Somit ist jeder Schüssel nur eine Sekunde gültig. Du könntest die Zeit auch auf 5 oder 10 sec runden, dann hast du mehr Spielraum bei der Zeitgenauigkeit.
Danish B. schrieb: > Bitte nenne mir den naechsten Hash, der die Tuer oeffnet. Nochmal für dich: Ich bezog mich auf die Aussage >MD5("TÜR AUF + SECRET") Deine komischen Beispiele haben noch mindestens einen Wert, der sich von Befehl zu Befehl ändert. Bei dem Beispiel >MD5("TÜR AUF + SECRET") kommt aber immer der gleiche MD5 Hash raus. Ist das denn so schwer...
Alex schrieb: > Ist das denn so schwer... Nein, aber Alex schrieb: > Ohne Rollcode ist das Bullshit - und selbst ein Rollcode ist > eigentlich schwach, muss man nur ein paar mal mitschneiden und dann > kann man den nächsten berechnen. Ohne Verschlüsselung wird das nix "paar mal mitschneiden, nächsten berechnen"
Mark B. schrieb: > Danish B. schrieb: >> ich habe vor mehrere Mikrocontroller ueber ein Funknetzwerk zu >> verbinden. Diese sollen sich gegenseitig Befehle senden. > > Diesen Ansatz würde ich einmal überdenken. In einem verteilten Sytem ist > es an und für sich nicht üblich, dass jedes Subsystem jedem anderen > Subsystem Befehle erteilen kann. Habe mich falsch ausgedrückt. Es soll nur einen Master geben, der Rest ist Slave.
Und was ist wenn man mehrere Schlüssel verwendet?! Mehrere Schlüssel im Rollover? - Client: Hat eine Liste von, was weiß ich, zehn Schlüsseln. Die ersten Zwei Byte zur verifikation, dann folgen die Nutzerbyte, daraus der MD5. Das alles wird dann mit einem Schlüssel aus dem Pool zufällig verschlüsselt. - Master: Hat ebenfalls die Liste von den zehn Schlüsseln. Empfängt das Paket und entschlüsselt das Paket zehnmal, einmal je Schlüssel. Findet er das Verifikations-Paket - war es der richtige Schlüssel. Kommt in nacheinander (z.b. dreimal) ein falsches Paket, wird der Client für eine gewisse definierte Zeit gesperrt. Ein Problem habe ich mit einem Roll-Code der fortläuft. Sollte mal ein Client die Roll-Code nicht mitbekommen, die Übertragung gestört sein, oder whatever - empfängt dann der Master garkeins mehr. Das lässt sich sicherlich mit viel Geduld auch knacken, aber sicherlich auch ein Ansatz den man sich mal anschauen könnte.
Draco schrieb: > Hat eine Liste von, was weiß ich, zehn Schlüsseln. Die ersten Zwei Byte > zur verifikation, dann folgen die Nutzerbyte, daraus der MD5. Das alles > wird dann mit einem Schlüssel aus dem Pool zufällig verschlüsselt. Ich komme grade nicht mit... wenn du endlich Schlüssel hast und irgendeiner davon gültig ist, dann ist auch zweimal derselbe hintereinander gültig. Also was verhindert das Replay? > Ein Problem habe ich mit einem Roll-Code der fortläuft. Sollte mal ein > Client die Roll-Code nicht mitbekommen, die Übertragung gestört sein, > oder whatever - empfängt dann der Master garkeins mehr. Fortlaufende Codes sind nicht so wirklich ein Problem... Aber das kommt eben aufs Szenario an. Wenn der Sender Code 42 sendet, der Empfänger das bekommt und tut was er eben tut, dann der Sender 43 sendet, der Empfänger es NICHT bekommt und nix tut und der Sender dann 44 sendet, dann tut der Empfänger trotzdem wieder, denn er erwartet ja nach 42 nur 43 oder größer (was 44 ist). Ebenso anders rum: Wenn der Sender 42 sendet und der empfänger tut, dann der Sender Schluckauf hat und nochmal 42 sendet und der empfänger nix tut (weil 43+ erwartet) und dann der Sender 43 sendet, geht es auch wieder. Klar, in beiden Fällen empfängt der Empfänger was und tut aber nix. Ob das ein Problem ist, hängt von der Anwendung ab... Wieder zum Beispiel Autoschlüssel: Da ist es kein Problem. Ich merke ja wenns ned geht und drück einfach n zweites mal. Soll ein System das automatisch erkennen, dann brauchts hald irgendeine Rückmeldung vom Empfänger zurück zum Sender, ob die Daten nun OK waren oder nicht. Aber lösbar ist es allemal...
Hier wird sehr viel mit Fachwörter um sich geworfen. Was leider fehlt ist ein ganzheitliches Sicherheitskonzept. Es gibt nicht mal eine vollständige Beschreibung deiner Anwendung und WAS du alles schützen musst und vor WELCHEN Angreifern. Es werden immer wieder einzelne Probleme / Angreifer diskutiert, neue Vorschläge gemacht und dann wieder auf andere Probleme hingewiesen. Aber brauchbare Lösungen sind hier eher nicht dabei. Grundsätzlich hast du hier auch noch das Problem, dass du von der Rechenpower und vom Speicher stark eingeschränkt bist, was die Sache nochmal deutlich schwieriger macht. Trivial ist das Problem keinesfalls! Kurzum gesagt: So wird das nichts. Krypto im Eigenbau ist eine ganz ganz schlechte Idee, die praktisch immer schief geht. Oft genug gesehen. Viele Firmen sind leichtsinnig: Hier und da ein wenig pseudo-crypto, so dass es auf den ersten Blick gut aussieht. Da sind sie erst mal glücklich. Irgendwann hat dann irgendwer irgendwie ein wenig Zeit und zerlegt das System auf katastrophale Weise. ;-) Dann darf die Entwicklertruppe antanzen, bekommt die Liste der Vulnerabilities präsentiert und darf die Software dann nochmal neu entwickeln - aber dieses mal sicher. Falls das ein Hobbyprojekt ist: Probiere weiter herum, mach dir Gedanken, lies die Bücher, so lernst du es. Da ist es vertretbar, mach dir keinen Stress. :-) Falls das kommerziell verwendet werden soll: Hol dir professionelle Hilfe. Und zwar so früh wie möglich im Projekt. Ja, das kostet. Aber noch mehr kostet es, wenn du später nochmal sicher entwickeln darfst. Falls du Geld in die Hand nehmen kannst zur Lösung des Problems, schreib mir eine PN, dann kann ich Kontakt herstellen.
Danish B. schrieb: > Hier der Mitschnitt. > Im Gegensatz zur verbauten Hardware bin ich noch so guetig, dir zu > sagen, dass ich mit diesen Befehlen 3mal die Tuer oeffne (ohne > zwischendurch zu verriegeln). mit MD5 kann man nur hashen. Wenn du also den Befehl "Tür auf + Rollcode" hashst, kann der Empfänger rein gar nichts damit anfangen, weil er nicht zurückrechnen kann, um den Befehl rauszuholen - DU EXPERTE!
Tom schrieb: > Ich komme grade nicht mit... wenn du endlich Schlüssel hast und > irgendeiner davon gültig ist, dann ist auch zweimal derselbe > hintereinander gültig. Also was verhindert das Replay? Naja, mann kann ja den letzten Key dann blocken, oder man kann solange die Keys blocken bis der Liste halt durch ist. Oder halt eine Kombination aus Rollkeys ( deiner >=42 ) und der Liste der endlichen Keys. Is halt nicht ganz so einfach das ganze irgendwie :-D Oooooder - Um das zu verhindern das man einen Schlüssel relayen kann: (Ich komm von meiner Liste der mehrfachen Keys nicht weg :-D) 1. Client sucht sich ein Schlüssel aus seiner Liste, Sperrt den Schlüssel, sendet verschlüsselt. Und setzt ein Zeitfenster 2. Master entschlüsselt (Schlüssel zu n). Sperrt den Schlüssel für die nächste Übertragung. Sendet das Paket mit einem eigenen, zufälligen Schlüssel zurück. Setzt ein Zeitfenster. 3. Client bekommt das Paket, entschlüsselt es und sendet dann wieder das Paket mit einem zufälligen Schlüssel zurück. 4. Master bekommt das Paket, checkt ob das Zeitfenster im Rahmen war, prüft ob die Werte bzw. der Hash des entschlüsselten Paketes gleich ist und gibt sein Okay. So nutzt es nichts wenn ein Paket doppelt gesendet wird, denn der jenige weiß ja schon welches Paket mit welchem Hash da und dran war. Das Zeitfenster gibt dann noch eine zusätzliche Sicherheit. Gerne natürlich auch noch mit deinem Rollkey.
Ob du nun eine Übertragung mit N möglichen Keys oder zwei kombinierte Übertragungen mit jeweils M Keys machst, ändert nichts daran dass man nach etwa N oder M² Mitschnitten alle möglichen Kombinationen kennt und dann das System geknackt hat. Ausser, wie du sagst, man verwendet eine eindeutige ID oder Zeitstempel mit im Paket. Da diese aber alleine auch ausreichend ist, kann man sich die Verschlüsselungsorgie dann auch sparen... Wir reden hier immernoch von µCs mit begrenzem Speicher und beschränkter Rechenkapazität. N bzw. M gemeinsame Schlüssel vorzuhalten und ein Paket N bzw. M mal zu entschlüsseln wäre da ja absoluter Wahnsinn. Hinzu kommt die notwendige bidirektionale Kommunikation, von der wir noch garnicht wissen ob die im Einsatz überhaupt gewünscht ist oder immer möglich ist. Und auch eine RTC (wegen Zeitfenster) ist eine sehr luxuriöse Annahme. Mit einem MAC (Message Authentication Code) und einer NONCE (number only used once) kommt man eben auch auf schwachbrüstigen µCs sehr weit und nutzt auch hier etablierte Mechanismen. Es klappt mit simpler Mathematik, ist zuverlässig, kommt mit nur einer Nachricht aus und geht auch bei nur unidirektionaler Kommunikation. Einschränkungen gibt es natürlich, aber um darauf einzugehen braucht man mehr von der Anwendung: *) Sind die Teilnehmer stationär oder mobil? (bsp. Autoschlüsel) *) Lassen sich Nachrichten provozieren? (bsp. Türklingel) *) Geht aktive bidirektionale Kommunikation oder ggf. nur eine Empfangsbestätigung *) Wie häufig wird kommuniziert ...
Ein NONCE musst du abgleichen. Das heißt du musst die genutzten Nummern ja irgendwo speichern - im Client und im Server. Wie willst du das denn auf einem µC bewerkstelligen?! Bei 16 Bit musst du ja mindestens 65.000 Nummern irgendwo ablegen können.
Muss ich? Ich hab mich jetzt nicht im Detail eingelesen was die exakte Definition von "NONCE" ist. Ich bezog mich streng auf "Number only used once"... Ich muss also nur sicherstellen, dass jede Nummer nur einmal verwendet wird. Das ist das wovon ich immer schreibe. Das kann ich einerseits, indem ich mir jede merke die genutzt wurde, aber das geht natürlich nicht auf einem µC. Ich kann es aber auch sicherstellen, indem ich ein Inkrement verwende. Wenn ich weiss dass ich grade 42 verwendet habe und als nächstes was größeres kommt, dann brauch ich mir nicht alle Zahlen von 1 bis 41 separat merken... Wenn eine NONCE tatsächlich, per definition, nur durch merken "verbrannt" werden kann und nicht durch eine Logik wie ein Inkrement, dann sorry, dann ist NONCE die falsche Bezeichnung für das was ich meinte...
P.S. Wikipedia listet einen Zähler ausdrücklich als valide Möglichkeit eine NONCE zu erzeugen. Also ist es valide sich nur den Zählerstand zu merken und nicht alle bis dahin verbrannten werte ;) https://de.wikipedia.org/wiki/Nonce
Das mit dem Nonce ist wirklich eine garnicht mal so schlechte Idee. Man kann den Nonce ja übermitteln der gestellt wurde. (Weil ich seh da halt immernoch Probleme bei: >>ich habe vor mehrere Mikrocontroller ueber ein Funknetzwerk zu >>verbinden. Diese sollen sich gegenseitig Befehle senden. Bei einer fortlaufenden Nummer müsste ja jeder Teilnehmer die aktuelle Nummer bekommen oder es gehen halt n-Teilnehmer Datenpakete verloren weil der Nummer durch einen anderen schon weitergeführt wurde. Aber wie bei dem Bild oben kann man ja die Nummer anfordern die aktuell ist, oder für die jeweilige Conversation. Diese muss man ja natürlich auch verschlüsseln und als Paket bekommen: 1. Client->Server: [[ID Client][GetNonce][Rand Fülldaten][md5] AES] 2. Server->Client: [[ID Client][SetNonce][Nonce Nummer][md5] AES] 3. Client->Server: [[ID Client][Nonce][Nutzerdaten][md5] AES] 4. Server->Client: [ACK] z.b. Aber ich hab mich mal umgeschaut, was AES doch für nen heiden Aufwand / µC-Zeit ist, um diesen auf nem 8-Biter umzusetzen o.O. Aber da man die Randbedingungen nicht kennt: - Eingesetzte µCs - WAS wird überhaupt übertragen?! Nutzdaten oder immer der gleiche Wert (Türschloss)? - Anzahl der Clients? - Was müssen die Clients noch nebenbei tun? - Wie ist die Datenrate? Das ist dann ein rumstochern im Dunkeln irgendwie.
Bei der AVR-Crypto-Lib braucht AES-128 in C zum verschlüsseln ~20.000 Takte und zum Entschlüsseln ca. ~40.000 Takte. Das sind ja dann bei 16Mhz ~1,2ms zu verschlüsseln und 2,4ms zum entschlüsseln - das ganze braucht dann 2kb Flash. Ist schon deftig!
Kommt auf die Anwendung an, aber die gibt es inzwischen auch in HW. http://www.atmel.com/Images/doc8405.pdf (gibt sicher auch andere) aber auch diese sind unsicher: http://www.newae.com/sidechannel/cwdocs/tutorialilyaxmega.html Worum geht es? und wie sicher muss es sein? kann man mit minimierten Verlusten leben (nur ein Teilschlüssel geht verloren; zb: aus einem Masterschlüssel wird pro Sitzung ein zufälliger Sitzungsschlüssel abgeleitet. => Masterschlüssel wird nur 1 mal pro Sitzung verwendet; Kizhvatov benötigt zb ca 1000 Botschaften, um den Schlüssel zu stehlen) sg
Eine gute Technologie zur Authentifizierung von Nodes bietet Atmel schon länger an http://www.atmel.com/devices/ATECC508A.aspx Der ECC508A wird inzwischen auch schon von Amazon Cloud Services verwendet,gab kürzlich eine News dazu. Der Coprocessor löst genau diese Probleme, mit dem erledigst du die notwendigen Signierung/Verifizierung von Paketen (ECDSA), sicheren Schlüsseltausch (ECDH) und die Privaten Schlüssel sind im gesicherten HW Bereich abgelegt und verlassen das System nie. Dazu gibt es schon gute App notes und Libraries im Source Code, die die Portierung auf die gewünschte Prozessor Architektur erlaubt. http://www.atmel.com/about/news/release.aspx?reference=tcm:26-82397
Alex schrieb: > Danish B. schrieb: >> Hier der Mitschnitt. >> Im Gegensatz zur verbauten Hardware bin ich noch so guetig, dir zu >> sagen, dass ich mit diesen Befehlen 3mal die Tuer oeffne (ohne >> zwischendurch zu verriegeln). > > mit MD5 kann man nur hashen. Wenn du also den Befehl "Tür auf + > Rollcode" hashst, kann der Empfänger rein gar nichts damit anfangen, > weil er nicht zurückrechnen kann, um den Befehl rauszuholen - DU > EXPERTE! Wenn es nur wenige Befehle gibt, kann der Empfänger alle Befehle + aktuelle Nonce durchprobieren bis der Hash übereinstimmt. Alternative: Der Befehl wird davor noch mal im Klartext mitgesendet. Die Nahricht ist ja nicht geheim, es geht ja nur um die Signatur des Senders.
Wie wäre es mit SmartHomatic? - https://www.smarthomatic.org - läuft mit AVR und RFM12 - verschlüsselt und sichert Integrität - hat bereits fertige Telegramme für alle möglichen Geräte definiert
Draco schrieb: > Naja, mann kann ja den letzten Key dann blocken, oder man kann solange > die Keys blocken bis der Liste halt durch ist. Klingt mir ein wenig nach Overkill xd. Tom schrieb: > *) Sind die Teilnehmer stationär oder mobil? (bsp. Autoschlüsel) > *) Lassen sich Nachrichten provozieren? (bsp. Türklingel) > *) Geht aktive bidirektionale Kommunikation oder ggf. nur eine > Empfangsbestätigung > *) Wie häufig wird kommuniziert Teilnehmer sind stationaer. Ja, Nachrichten lassen sich provozieren. Bei Threaderstellung dachte ich nur an die Befehle. Sprich unidirektional. Ich moechte aber auch Statusmeldungen, Energieverbrauch, etc. anzeigen lassen. Dafuer benoetige ich dann bidirektionale Verbindungen. Der Hash-Ansatz ist aber natuerlich nur in eine Richtung moeglich, bzw. es lassen sich nur Befehle senden, die beide vorher kennen. Keine "Daten". Dementsprechend favorisiere ich wieder die Perfect Forward Secrecy. Die Implementierung wird allerdings extrem schwierig. Es sei denn, ich nutze die Kryptomodule, die Stefan vorgeschlagen hat. Deren Datenblatt ist allerdings NDA :( .
> Deren Datenblatt ist allerdings NDA :( .
smarthomatic ist open source.
Angehängte Dateien:
-
vortrag_cte4214_raster.gif
15 KB -
vortrag_cte4215_raster.gif
16 KB
Danish B. schrieb: > Es sei denn, ich nutze die Kryptomodule, die Stefan vorgeschlagen hat. > Deren Datenblatt ist allerdings NDA :( . Vorschlag: Dokument = Befehl + Zeitstempel Wenn als KeyPair eine elliptische Kurve verwendet wird, könnten die oben genannten Chips als CoProcessor einsetzt werden. Wobei ein C-Implementierung gerade auf einem µC Sinn macht. (kürzere Schlüssel bei gleicher Sicherheit gegenüber RSA) Die Kurvenparameter sind veröffentlicht und werden als sicher angesehen. Suchstichwort "ECC FIPS"
AndreasR schrieb: > Wie wäre es mit SmartHomatic? - https://www.smarthomatic.org Habe ich mir jetzt mal angesehen: SmartHomatic nutzt symmetrische Verschluesselung (AES). Zum Schutz gegen Replay, enthaelt jeder AES-Block einen Zaehler (Rollkey). Die folgenden Bloecke werden mit dem ersten kombiniert, daher brauchen sie keinen eigenen Zaehler (CBC [1]). Man muesste dann jedem Modul den Key vorher mitteilen. Das AES wuerde ich nicht selbst implementieren, das gibt es von Microchip fertig (fuer PIC16 und PIc18, PIC24 haben das teils in Hardware). Dieser Ansatz scheint erprobt zu sein und zu funktionieren, was haltet ihr davon? [1] https://de.wikipedia.org/wiki/Cipher_Block_Chaining_Mode [2] https://www.smarthomatic.org/basics/features_in_detail.html Ich habe vor, das Projekt mit PIC-Mikrocontrollern durchzufuehren (PIC16 oder PIC18).
Reinhard M. schrieb: > Vorschlag: > > Dokument = Befehl + Zeitstempel > > Wenn als KeyPair eine elliptische Kurve verwendet wird, > könnten die oben genannten Chips als CoProcessor einsetzt werden. > > Wobei ein C-Implementierung gerade auf einem µC Sinn macht. > (kürzere Schlüssel bei gleicher Sicherheit gegenüber RSA) > > Die Kurvenparameter sind veröffentlicht und werden als sicher > angesehen. > > Suchstichwort "ECC FIPS" Muss ich mich ein erst ein wenig einlesen, aber danke fuer den Hinweis.
Danish B. schrieb: > Das AES wuerde ich nicht selbst implementieren, das gibt es von > Microchip fertig (fuer PIC16 und PIc18, PIC24 haben das teils in > Hardware). Das muss ich zurueckziehen. Die Source-Codes sind nicht verfuegbar, die Application-Notes, die diese Beschreiben allerdings schon. [1] http://ww1.microchip.com/downloads/en/AppNotes/00953a.pdf [2] http://ww1.microchip.com/downloads/cn/AppNotes/cn_00821a.pdf
Danish B. schrieb: > Der Hash-Ansatz ist aber natuerlich nur in eine Richtung moeglich, bzw. > es lassen sich nur Befehle senden, die beide vorher kennen. Keine > "Daten". Nene, Moment! Natürlich geht der Hash-Ansatz mit beliebigen Daten: Der Hash (eigentlich der MAC) sichert ja nur die Datenintegrität. Die Daten selbst kannst/musst du aber schon auch mitsenden. Du sendest ja folgendes: PACKET_UID+DATEN+MAC Wobei MAC = HASH(PACKET_UID+DATEN+SECRET) Das eignet sich sehr wohl für beliebige Daten, nicht nur für einen festgelegten Befehlssatz. Und es geht auch beliebig im Netz hin und her, solange du im Netz einen Mechanismus hast die UID auf Eindeutigkeit zu prüfen...
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.