Im Beitrag "EnOcean und Verschlüsselung" wurde ja schon über den Sinn einer solchen Verschlüsselung diskutiert. Trotzdem möchte ich meine Funkstrecken für ähnliche Anwendungen mit einem NRF24L01+ so aufbauen, dass möglicht auch der letzte Bedenkenträger meint, dass man das Protokoll bedenkenlos für beliebige Zwecke einsetzen kann, also auch dort, wo mit „Angriffen” zu rechnen ist. In Wikipedia steht zu ZigBee: "Eine Entschlüsselung des ZigBee-Keys geht sehr schnell". Sowas wollte ich - wenn möglich - vermeiden. Nun kenne ich mich mit Verschlüsselung nicht so gut aus. Ich kenne von PGP das „Public-Key-Verfahren” und könnte mir vorstellen, dass jeder Funk-Knoten einen "private key" im EEPROM hat. PGP gilt ja wohl als ziemlich sicher. Bin ich auf dem richtigen Weg? Oder hat jemand einen Tipp, wo eine geeignete Verschlüsselung beschrieben ist, die ich implementieren könnte? Klar, wenn jemand die Hardware in die Hand bekommt, gibt's immer Möglichkeiten. Wenigstens der Funk sollte sicher sein.
:
Bearbeitet durch User
Torsten C. schrieb: > Hat jemand einen Tipp, wo eine geeignete Verschlüsselung beschrieben > ist, die ich implementieren könnte? Wenn du einmal einen Rundumschlag haben willst dann schau dir die aktuellen Empfehlungen des BSI an: >https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102_pdf.pdf?__blob=publicationFile Ob du asymmetrische oder symmetrische Verfahren nutzen kannst/willst hängt maßgeblich von den zur Verfügung stehenden Ressourcen ab, asymmetrische Verfahren sind im Allgemeinen deutlich langsamer und ressourcenfressender als symmetrische Verfahren. Und denk nicht einmal daran irgendeines der Verfahren selber implementieren zu wollen, dafür gibt es spezielle Krypto-Bibliotheken wie Keyczar oder cryptlib.
Und neben Vertraulichkeit solltest du dir auch Gedanken um Integrität und Authentizität machen ...
Daniel H. schrieb: > schau dir die > aktuellen Empfehlungen des BSI an Sorry, aber das ist der absolut letzte Laden, den man empfehlen kann, wenn es um Sicherheit geht! Man möchte da nur mal an sachen erinnern wie: "Verschlüsselung XY ist nicht sicher und sollte sofort ersetzt werden. Unsere Server setzen aber selber Verschlüsselung XY ein, und zwar ohne alternative. Aber wir haben Ahnung von Sicherheit und setzen sie konsequent um!" Wie ernst kann man eine staatliche Institution nehmen, die Regeln und Vorschläge zur Sicherheit macht, sich aber selbst in keinster weise daran hält? Das ist so als wenn dir dein Arzt erzählt du solltest mit dem Rauchen aufhören, während er das sagt aber gerade selbst ne Fluppe im Mund hat. Sorry, aber so einen Laden kann man schlicht weg nicht ernst nehmen! Da gibt es kein wenn und aber!
Kaj schrieb: > Sorry, aber das ist der absolut letzte Laden, den man empfehlen kann, > wenn es um Sicherheit geht! Was für einen Laden? Ich habe ein Dokument empfohlen in dem das BSI nach aktuellem Stand sichere kryptographische Verfahren empfiehlt. Nach deiner Logik wäre der AES jetzt nur deswegen weniger sicher weil er vom BSI in diesem Dokument erwähnt wird. Ganz davon ab, dass es dem geneigten Leser natürlich offen steht die dortigen Empfehlungen anhand weiterer Quellen zu verifizieren. Gerne kann ich aber nur für dich auch auf die Ergebnisse von ECRYPT verweisen, die leider nicht mehr ganz aktuell sind: > http://www.ecrypt.eu.org/documents/D.SPA.20.pdf Aber vielleicht sind auch die böse, weil da Universitäten und Firmen (KOMMERZ!) dran beteiligt waren. Einen Verweis auf Empfehlungen des NIST habe ich mir ohnehin schon gespart. Kaj schrieb: > Man möchte da nur mal an sachen erinnern > wie: "Verschlüsselung XY ist nicht sicher und sollte sofort ersetzt > werden. Unsere Server setzen aber selber Verschlüsselung XY ein, und > zwar ohne alternative. Aber wir haben Ahnung von Sicherheit und setzen > sie konsequent um!" Ja, peinliche Sache. Aber schonmal darüber nachgedacht dass die IT nicht unbedingt immer dann springt wenn der Experte "Hopp" sagt? Da müssen Prozesse durchlaufen und evaluiert werden und irgendwann schaltet dann der Admin die empfohlenen Ciphersuites "scharf". Für eine staatliche Institution erfolgte das sogar recht flott nachdem die Kritik aufkam. Da gibt es andere staatliche Institutionen die langsamer sind und denen ich noch weniger vertraue. Kaj schrieb: > Wie ernst kann man eine staatliche Institution nehmen, die Regeln und > Vorschläge zur Sicherheit macht, sich aber selbst in keinster weise > daran hält? Offensichtlich waren sie aber immerhin in der Lage dies zu erkennen, einzusehen und zu ändern. Vermutlich hat jeder schonmal Regeln oder Vorschläge gemacht und diese letzlich selbst nicht gehalten (sogar ein CCC oder eine Piratenpartei). Nach der Logik dürfte man also sowieso niemandem mehr trauen.
stmz schrieb: > Und neben Vertraulichkeit solltest du dir auch Gedanken um Integrität > und Authentizität machen Ich hoffe, ich bin jetzt nicht zu naiv: Aber wenn eine Nachricht nach der Entschlüsselung einen gültigen CRC hat: Das müste doch genug Authentizität und Integrität nachweisen, oder? Ansonsten kommt's m.E. auf die Daten an. Z.B. bei isochronen Daten (ohne Retry usw.) werden ungültige Datenpakete eh verworfen und sich nicht weiter gekümmert.
Zwar keine direkte Antwort zu diesem Beitrag. Aber ein interasster Beitrag des CCC zu diesem Thema: http://www.youtube.com/watch?v=1dhCDJ_LVuY
Kaj schrieb: > Sorry, aber das ist der absolut letzte Laden, den man empfehlen kann, > wenn es um Sicherheit geht! Man möchte da nur mal an sachen erinnern > wie: "Verschlüsselung XY ist nicht sicher und sollte sofort ersetzt > werden. Unsere Server setzen aber selber Verschlüsselung XY ein, und > zwar ohne alternative. Aber wir haben Ahnung von Sicherheit und setzen > sie konsequent um!" Erzähl mal! Falls es dir um SSL-Ciphersuites ging: da war die Empfehlung, künftig auf bestimmte Algorithmen zu verzichten, was zum damaligen Zeitpunkt jedoch nicht möglich war, weil die Browserunterstützung noch nicht gegeben war. Und das andere Mal in ähnlicher Situation wurde vor Problemen mit einem Algorithmus gewarnt, dieser aber dennoch eingesetzt, weil die anderen verbreiteten Varianten noch schlimmer waren (weiß gerade nicht mehr, ob das zu BEAST- oder CRIME-Zeiten war).
Torsten C. schrieb: > Ich hoffe, ich bin jetzt nicht zu naiv: Aber wenn eine Nachricht nach > der Entschlüsselung einen gültigen CRC hat: Das müste doch genug > Authentizität und Integrität nachweisen, oder? Wenn man es genau nimmt nein, da der CRC, genau wie die Verschlüsselung, per Definition keine Authentizität liefert. Ein solches Konstrukt kann ein gewisses Maß an Authentizität liefern, muss es aber nicht. Willst du die Authentizität absichern dann musst du aus sicherheisttechnischer Sicht auch ein dafür gewähltes Verfahren nehmen, also beispielsweise MACs. Und auch dabei hast du wieder mehrere Optionen: 1. Erst den MAC über die Nachricht berechnen und dann Nachricht und MAC zusammenfassen und verschlüsseln und das Chiffrat übertragen 2. Den MAC über die Nachricht berechnen, dann die Nachricht verschlüsseln und beides übertragen 3. Erst die Nachricht verschlüsseln, dann den MAC über das Chiffrat berechnen und beides übertragen Und nur für letztere Variante kann allgemein bewiesen werden, dass sie sicher ist, sofern die kryptographischen Primitiven sicher sind. Zum Teil ist das sicherlich Erbsenzählerei, aber im Bereich der Sicherheit ist das unerlässlich. Alles, was nicht beweisbar sicher ist bzw. dessen Sicherheit noch nicht bewiesen wurde muss als unsicher angesehen werden. Konstuktionen wie die von dir vorgeschlagene können funktionieren, müssen aber nicht. Ein Beispiel ist WEP auch hier wurde u.a. der CRC eingesetzt um die Integrität zu sichern, was gründlich in die Hose gegangen ist: > http://de.wikipedia.org/wiki/Wired_Equivalent_Privacy#CRC32_als_Message_Authentication_Code_.28MAC.29 Viele Grüße Danel
:
Bearbeitet durch User
Torsten C. schrieb: > Ich hoffe, ich bin jetzt nicht zu naiv: Aber wenn eine Nachricht nach > der Entschlüsselung einen gültigen CRC hat: Das müste doch genug > Authentizität und Integrität nachweisen, oder? > Bei einem asymetrischen Verfahren hast du erstmal keine Gewissheit ueber die Authentizität des Versenders da es um die Nachricht zu verschluesseln es genuegt sich des oeffentlichen Schuessel des Empfaengers zu bedienen. (Der Versender muesste dann also eine Signatur mitschicken welche der Empfaenger aber wiederum selbst beim Versender verifizieren muss.) "Funkstrecken für ähnliche Anwendungen" ist halt etwas unbestimmt. Wenn man dem Sender den public-key des empfaenger gleich mitgibt und er anderweitig nicht in Erfahrung zu bringen ist sollte mann schon annehmen koennen dass das eine gewisse Sicherheit gibt. Oder?
Torsten C. schrieb: > Ich hoffe, ich bin jetzt nicht zu naiv: Aber wenn eine Nachricht nach > der Entschlüsselung einen gültigen CRC hat: Das müste doch genug > Authentizität und Integrität nachweisen, oder? Und wenn der Angreifer das CRC Verfahren kennt ?
Torsten C. schrieb: > Ich hoffe, ich bin jetzt nicht zu naiv: Aber wenn eine Nachricht nach > der Entschlüsselung einen gültigen CRC hat: Das müste doch genug > Authentizität und Integrität nachweisen, oder? Eine CRC ist dafür ungeeignet, da muss ein anderes Verfahren verwendet werden: https://en.wikipedia.org/wiki/Cryptographic_hash_function
:
Bearbeitet durch User
328882#postform schrieb: > "Funkstrecken für ähnliche Anwendungen" ist halt etwas unbestimmt. > Wenn man dem Sender den public-key des empfaenger gleich mitgibt und er > anderweitig nicht in Erfahrung zu bringen ist sollte mann schon annehmen > koennen dass das eine gewisse Sicherheit gibt. Das ist doch gerade die Eigenschaft des Public-Keys, jeder darf ihn kennen ohne dass die Sicherheit gefährdet ist. Was du meinst ist, denke ich, die Sicherstellung der Authentizität eines Public-Keys den man aus einer unbekannten Quelle erhält. An dieser Stelle kommen dann signierte, digitale Zeritfikate zum Einsatz, bei denen z.B. eine allgemein bekannten Root-Authority die Echtheit eines Public-Keys und die Identität von dessen Inhaber bestätigt.
Torsten C. schrieb: > Ich hoffe, ich bin jetzt nicht zu naiv: Aber wenn eine Nachricht nach > der Entschlüsselung einen gültigen CRC hat: Das müste doch genug > Authentizität und Integrität nachweisen, oder? Fortsetzung: Authentifizierung geht mit einem Hash allein aber nicht. Der Trick an Verfahren wie PGP besteht in der inversen Anwendung der öffentlichen und privaten Schlüsseln in Verbindung mit einer solchen kryptografischen Signatur. > Ansonsten kommt's m.E. auf die Daten an. Z.B. bei isochronen Daten (ohne > Retry usw.) werden ungültige Datenpakete eh verworfen und sich nicht > weiter gekümmert. Da reicht es aus, festzustellen ob ein Frame intakt ist. Von wem er ist wird nicht festgestellt.
Bevor jetzt wieder die Kryptokeule rausgeholt wird. Ein Verfahren mit preshared key mit einem symetrischen Cipher und keyed hashing, wo der Hashkey auch preshared ist, sollte für für Anwendungen ala Licht einschalten ausreichen. Auch für Kryptokram gilt: Aufwand, Nutzen und möglicher Schaden sollten in einem vernüftigen Verhältniss stehen.
Alice schrieb: > Bevor jetzt wieder die Kryptokeule rausgeholt wird. Nur ist es gerade die Kryptokeule, mit der dieser Thread überhaupt erst gestartet wurde.
A. K. schrieb: > Nur ist es gerade die Kryptokeule, mit der dieser Thread überhaupt erst > gestartet wurde. Aus dem ersten Post: > Oder hat jemand einen Tipp, wo eine geeignete Verschlüsselung > beschrieben ist, die ich implementieren könnte?
Ich lerne gerade viele neue "Vokabeln" und potenzielle Suchbegriffe. Danke. :-) Wenn ich weiter über meine Fragestellung nachdenke, war ich vielleicht etwas auf dem Holzweg. Im Grunde geht es hier vielleicht gar nicht um Verschlüsselung (Geheimhaltung), sondern nur um Authentizität. Die Daten (wann wird eine Tür aufgeschlossen, welches Fenster ist auf, wieviel Grad hat der Thermostat usw.) sind m.E. gar nicht geheim. Oder sollte man hier mit Bedenkenträgern rechnen, die das Protokoll schlecht reden, weil die Daten nicht verschlüsselt sind? 328882#postform schrieb: > "Funkstrecken für ähnliche Anwendungen" ist halt etwas unbestimmt. Ein gutes Beispiel ist ein Garagentoröffner. Aber im Grunde geht es mir um fast alles, was man sich im Rahmen des "Internet of Things" und der Hausautomatisierung vorstellen kann. WLAN ist mir dafür nur zu teuer, denn es kostet etwa das 10-fache pro Knoten gegenüber einem NRF24L01+. Und ZigBee ist auch ziemlich teuer und die Verschlüsselung scheinbar unsicher (s.o.). Fred schrieb: > weil die Browserunterstützung noch nicht gegeben war. Zum Glück entfallen hier solche Probleme oder tauchen nur in einer Bridge zum Internet ins Gewicht. Ich befürchte, das Protokoll wird ziemlich proprietär. Oder macht es im Zusammenhang mit dem NRF24L01+ Sinn, irgendeine standardisierte Implementierung für den Presentation Layer (OSI Schicht 6) zu verwenden? Gibt's da was? Ich hätte dazu gerade keine Idee. Daniel H. schrieb: > asymmetrische Verfahren sind im Allgemeinen deutlich langsamer und > ressourcenfressender als symmetrische Verfahren. Gut, also symmetrisch! Die Schlüssel können per USB ins EEPROM geschrieben und das Auslesen erschwert werden. Wenn z.B. mal eine Funkfernbedienung verloren geht, muss man halt - um sicher zu gehen - überall neue Schlüssel programmieren. Ich denke, das wäre akzeptabel. Wenn es also nur um Authentizität geht, also z.B.: ► Ist der Sender berechtigt, das Garagentor zu öffnen? ► Ist die gemessene Temperatur tatsächlich die von der gewünschten Wetterstation? ► Ist die Meldung "Das Fenster ist zu" tatsächlich die Meldung vom Original-Sensor, oder will ein Einbrecher der Alarmanlage ein geschlossenes Fenster vorgaukeln? ► usw. Dann dürfte das m.E. gar nicht so kompliziert werden, denke ich.
:
Bearbeitet durch User
Torsten C. schrieb: > Gut, also symmetrisch! Die Schlüssel können per USB ins EEPROM > geschrieben und das Auslesen erschwert werden. Wäre jetzt auch mein Vorschlag gewesen, solange du alles unter deiner Kontrolle hast ist es denke ich recht einfach mit symmetrischen Verfahren zu hantieren. Man darf natürlich nicht vergessen, dass so ein EEPROM ausgelesen werden kann. Aber dazu muss der Angreifer erst einmal eine weitere Hürde überwinden, indem er physikalischen Zugriff erlangt. In jedem Fall wäre das schon einmal sicherer als gar nicht zu verschlüsseln und zu authentisieren. Verschlüsselung z.B. mit AES-128, Authentisierung mit HMAC unter Nutzung eines kryptographisch sicheren Hashs (z.B. SHA-256). Wichtig ist, dass du zuerst verschlüsselst und dann den MAC über das Chiffrat berechnest. Aber wie schon gesagt, für sowas gibt es Kryptobibliotheken, die solltest du auch nutzen, da sie dir das Leben sehr vereinfachen.
Daniel H. schrieb: > Wichtig ist, dass > du zuerst verschlüsselst und dann den MAC über das Chiffrat berechnest. Und wenn ich gar_nicht verschlüssele und nur einen Nachrichtenauthentifizierungscode (MAC) berechne: Ist die Authentizität dann gefährdet? PS: Damit wäre doch auch schon sicher, dass kein Einbrecher der Alarmanlage ein geschlossenes Fenster vorgaukelt oder das Garagentor öffnet, oder bin ich nun zu naiv? Verschlüsselung könnte man ja bei Bedarf immer noch ergänzen, falls jemand Angst um seine Privatsphäre oder den Datenschutz hat.
:
Bearbeitet durch User
Daniel H. schrieb: > Man darf natürlich nicht vergessen, dass so ein EEPROM ausgelesen werden > kann. Aber dazu muss der Angreifer erst einmal eine weitere Hürde > überwinden, indem er physikalischen Zugriff erlangt. In jedem Fall wäre > das schon einmal sicherer als gar nicht zu verschlüsseln und zu > authentisieren. Welche andere Kryptoverfahren löst dieses Problem?
Alice schrieb: > Welche andere Kryptoverfahren löst dieses Problem? Am Ende keins, also m.E. keine Diskussion erforderlich. Es soll ja sogar möglich sein, die Bits auf einem Chip mit einem Mikroskop zu verfolgen ...
Torsten C. schrieb: > Alice schrieb: >> Welche andere Kryptoverfahren löst dieses Problem? > > Am Ende keins, also m.E. keine Diskussion erforderlich. Korrekt. An dieser Stelle muss man dann mit Hardwaresicherheit arbeiten, also z.B. Speicherbereiche die speziell gegen physischen Zugriff gesichert sind und sich bei erkannter Manipulation selbst löschen. Oder dass die verwendeten Controller sich ihren Takt und die Versorgungsspannung selbst erzeugen (Stichtwort: Seitenkanalangriffe) usw. Ob man das benötigt hängt vom Schutzbedarf ab. Wenn ich nicht möchte, dass mir der Nachbar das Licht per Funk ausschaltet reicht Verschlüsselung und Hinterlegen des Schlüssels im EEPROM in der Regel aus. Er könnte jetzt zwar in meine Wohnung einbrechen, die Lampensteuerung klauen/analysieren und dann vielleicht mein Licht per Funk ausschalten, die Hürde dafür ist aber deutlich höher.
:
Bearbeitet durch User
Nun war ja die Frage nach einer "geeigneten Verschlüsselung". Und der NRF24L01+ hat eine maximale Paket-Größe von 32 Bytes. Daniel H. schrieb: > Authentisierung mit HMAC unter Nutzung > eines kryptographisch sicheren Hashs (z.B. SHA-256). Bei fast allen kryptologischen Hashfunktionen wird wird die Länge der Nachricht zu Beginn auf ein ganzzahliges Vielfaches von 512 gebracht. Das heißt, allein um den Befehl "Garagentor auf" zu senden, müsste man mindestens 16 Pakete senden??? Wie schwierig wäre es denn, z.B. ein HMAC mit 128bit Secret (= geheimer Schlüssel) und einem "32-bit CRC" als "Hash-Funktion" zu knacken? Damit hätte ich nur 4 Byte "Overhead" für die Verschlüsselung. http://de.wikipedia.org/wiki/Keyed-Hash_Message_Authentication_Code Die Kombination "128bit Secret" und "32-bit CRC" sind dabei nur ein Beispiel für eine praktikable Lösung. 16 Byte Overhead würde man m.E. auch noch verkraften. Torsten C. schrieb: > Und wenn ich gar_nicht verschlüssele … Ist die Authentizität > dann gefährdet? OK, ich lese gerade: MACs schützen nicht vor Replay-Angriffen, also ergänze ich noch einen Zeitstempel oder eine Sequenznummer. Aber dann sollte es doch reichen, oder?
:
Bearbeitet durch User
A. K. schrieb: > Torsten C. schrieb: >> Ich hoffe, ich bin jetzt nicht zu naiv: Aber wenn eine Nachricht nach >> der Entschlüsselung einen gültigen CRC hat: Das müste doch genug >> Authentizität und Integrität nachweisen, oder? > > Fortsetzung: Authentifizierung geht mit einem Hash allein aber nicht. > Der Trick an Verfahren wie PGP besteht in der inversen Anwendung der > öffentlichen und privaten Schlüsseln in Verbindung mit einer solchen > kryptografischen Signatur. Authentizität heißt ja, dass die Nachricht von dem kommt, der es aufgrund des Key auch ist. Daher wäre hier zusätzlich zu nennen, dass für jedem öffentlichen Schlüssel auch geprüft wurde, dass sich dahinter auch der korrekte Empfänger verbirgt. Desweiteren sollte bei allen Verfahren geschaut werden, wer die Keys erzeugt. Ist ja in vielen Fällen nicht so einfach echt zufällige Keys für eine solche Verwendung zu erzeugen.
Torsten C. schrieb: > Bei fast allen kryptologischen Hashfunktionen wird wird die Länge der > Nachricht zu Beginn auf ein ganzzahliges Vielfaches von 512 gebracht. Stop. Die Nachricht wird in 512 _Bit_-Blöcke aufgeteilt, also 64 Byte. Das ist aber nicht die Ausgabelänge. Die Ausgabelänge z.B. bei SHA-2 ist, je nach Variante, 224 bis 512 Bit also 28 bis 64 Byte. Das ist natürlich erst einmal doof, da du damit bei HMAC mit SHA-256 schon auf 32 Byte kommst. Nun ist es aber zulässig, z.B. die Ausgabe eines MACs zu beschneiden. Das BSI empfiehlt hier als absolutes Minimum 64 Bit, besser 96 Bit. Wenn du Letzteres nimmst kommst du sogar mit einem Paket aus und hast sogar noch 20 Byte für Nutzdaten frei. Da könnte man z.B. noch einen AES-verschlüsselten Block (16 Byte) unterbringen. Damit blieben sogar noch vier weitere Byte übrig. Die könnte man dann z.B. noch für den MAC nutzen (der dann effektiv 128 Bit hat). Torsten C. schrieb: > OK, ich lese gerade: MACs schützen nicht vor Replay-Angriffen, also > ergänze ich noch einen Zeitstempel oder eine Sequenznummer. Aber dann > sollte es doch reichen, oder? Idealerweise macht man hier Challenge-Response, d.h. der Empfänger schickt dem Sender erstmal einen Zufallswert. Diesen muss der Empfänger dann in seine Antwort einbauen, beispielweise in die MAC-Berechnung. Die Verifizierung der Antwort führt der Empfänger dann unter Berücksichtigung des von ihm gesendeten Wertes durch und kann somit sicher gehen, dass der Sender auch tatsächlich über den geheimen Schlüssel verfügt. Wichtig ist, dass der gesendete Wert sich nicht (oder nicht zu oft) wiederholt, ansonsten wäre ein Replay-Angriff mit höherer Wahrscheinlichkeit wieder erfolgreich.
:
Bearbeitet durch User
Steffen Rose schrieb: > … dass für jeden öffentlichen Schlüssel auch geprüft wurde … Schön, dass das noch klar gestellt wurde. Aber ich denke, mit einem asymmetrischen Verfahren war ich auf dem Holzweg. Steffen Rose schrieb: > Ist ja in vielen Fällen nicht so einfach echt zufällige Keys > für eine solche Verwendung zu erzeugen. Wenn man sich nicht auf einen bestimmten Generator festlegt - um so besser. Für UUIDs bzw. GUIDs gibt es z.B. online-Generatoren und viele andere Möglichkeiten. Das kann dann ja jeder so machen, wie er denkt. Hauptsache ist erstmal, die Firmware ist sinnvoll implementiert. Daniel H. schrieb: > Wenn du Letzteres nimmst kommst du sogar mit einem Paket aus und hast > sogar noch 20 Byte für Nutzdaten frei. Da könnte man … Das klingt nach einem guten Tipp. Danke, Daniel. :-) Daniel H. schrieb: > Idealerweise macht man hier Challenge-Response Ah, auch cool. :-) Klingt nicht sehr aufwendig. Ich denke, so wird das eine "runde Sache" und besser, als die z.B. KFZ-Funkschlüssel, die öfter mal im TV für peinliche Berichte sorgen.
:
Bearbeitet durch User
Torsten C. schrieb: > Daniel H. schrieb: >> Wenn du Letzteres nimmst kommst du sogar mit einem Paket aus und hast >> sogar noch 20 Byte für Nutzdaten frei. Da könnte man … > Das klingt nach einem guten Tipp. Danke, Daniel. :-) Ich setze noch einen Drauf: Der NRF24L01+ kann ja "slow FH (= SFH)", siehe http://de.wikipedia.org/wiki/Frequency_Hopping_Spread_Spectrum Dadurch habe ich noch was gefunden: "… es lässt sich deswegen nicht abhören, weil ein Außenstehender nie weiß, auf welcher Trägerfrequenz sich nach dem nächsten Hop das Signal befindet." Mit dem HMAC-Schlüssel könnte ich z.B. einen "Mersenne Twister" initialisieren und damit eine individuelle aber bei Sender und Empfänger identische Kombination aus SFHSS und THSS ableiten. Ganz schön verschlüsselt … Jetzt muss ich mir nur noch überlegen, wie ich damit ein "Adaptive Frequency Hopping Spread Spectrum" realisiere, siehe http://de.wikipedia.org/wiki/Frequenzspreizung#Adaptive_Frequency_Hopping_Spread_Spectrum "Solche … Funknetzwerke … werden proprietär implementiert, bis heute ist keine allgemeine Lösung standardisiert." Aus http://de.wikipedia.org/wiki/Bluetooth#Systemarchitektur Dann muss ich mir wohl selbst was ausdenken, siehe Siehe Beitrag "randsample Random Dissolve randIntNoRep - wie geht das?"
:
Bearbeitet durch User
für challenge/response gibt es ganz gute Produkte wie den atsha204 - derjenige der eine nachricht versenden will generiert einen zufallswert (mit interner HW der MCU oder des ATSHA204) - man generiert einen hash mit diesem random number + eines schlüssels aus einem der 16 slots - nun schickt man einen check befehl an den empfänger mit dem generierten random number und der nummer des verwendeten key slots - auf der empfängerseite generiert man nun einen hash mit dem empfangenen random number und dem key im slot nr. x (x=die nummer die empfangen wurde) - den Hash schickt man an den versender zurück - der versender checkt nun ob das resultat gleich ist, wenn ja dann war die authentifizierung erfolgreich das ganze erfordert dass alle systeme dieselbe information im atsha204 gespeichert hat. der atsha hat auch andere funktionen wie passwort check, checkmac, rolling keys, usw. um die authentifizierung gegen replay attacken zu schützen wird der random number wert benötigt am besten wenn man zusätzlich noch jedesmal einen anderen slot wählt
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.