Forum: HF, Funk und Felder Funkübertragungen verschlüsseln


von Andreas R. (blackpuma)


Lesenswert?

Meine Frage betrifft wie schon im Betreff zu erkennen die 
Verschlüsselung von Funkübertragungen.

Mir geht es genau gesagt um die Sicherstellung das der Empfänger nur 
Daten akzeptiert die vom richtigen Sender kommen. Es sollen keine Daten 
von einem anderen Sender akzeptiert werden.

Weiß jemand von euch wie man das anstellen kann?

LG
Andreas

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Ja, mit einer kryptografischen Prüfsumme, auch message authentication
code (MAC) bzw. teilweise (wegen Verwechslung mit dem MAC-Layer im
Sinne von `medium access layer') MIC genannt (message integrity code).

Im einfachsten Falle verkettest du ein geheimes Passwort mit der
Nachricht, lässt bspw. einen AES-Algorithmus über alles laufen und
schickst dessen Ergebnis zur Gegenseite.  Die Gegenseite führt die
analoge Operation ebenfalls durch und vergleicht die Ergebnisse.
Das Passwort selbst wird dabei nie ,,über die Luft'' übertragen.

Das geht natürlich in dieser einfachen Form nur, solange das Passwort
und die Nachricht weniger als einen AES-Block (16 Byte) lang sind.
Für längere Kombinationen braucht man kompliziertere Algorithmen, die
du dir im Netz nachlesen kannst (bspw. im CCM*-Algorithmus in IEEE
802.15.4).

von Peter (Gast)


Lesenswert?

Das ist aber nicht der Sinn einer verschlüsselung. Was du suchst ist 
einen Authendifikation bzw eine Signatur.
Also die Frage ist welche Hardware vorhanden ist. Wenn genug Leistung 
vorhanden ist dann wird die nachricht mit einen Private-Key signiert und 
der empfänger kann mit dem public-key prüfen ob sie von dem richtigen 
Sender ist. Damit können aber noch nachrichten abgefangen werden und 
erneut gesendet werden - soll das auch verhindert werden?

von Andreas R. (blackpuma)


Lesenswert?

Eine Authentifizierung würde schon mal ausreichen. Hat jemand eine 
Lösung für so ein Private-Public Lösung? Kann man sie einen Key auf ein 
EEProm brennen und von dort lesen damit der leicht ausgetauscht werden 
kann?

von Andreas (Gast)


Lesenswert?

Ich nehme an du meinst Komunikation nur in eine Richtung, also wie beim 
Garagentor.

Dafür gibt es eine Appnote von Atmel, deren Name mir gerade nicht 
einfällt :)

Prinzipiell:
eine Zählvariable wird vom Sender bei jeder Übertragung um 1 
inkrementiert. Diese Zählvariable und Daten wird mit z.B. AES 
verschlüsselt und mitgesendet. Den Schlüssel kennt auch der Empfänger.

Der Empfänger merkt sich den letzten Zählerstand und akzeptiert nur 
Pakete die "jünger" als das letzte empfangene Paket sind. Somit wird 
mitlauschen und erneut senden vereitelt.

"jünger" liegt aber im Ermessen des Programmierers:
-Überlauf des Zählers möglich? (-> großer Zähler)
-Verlorene Pakete berücksichtigen(Empfänger muss Sprünge im Zähler 
tolerieren)
-Empfänger sollte nicht beliebig große Sprünge tolerieren, das würde die 
Sicherheit reduzieren

von Wolfgang Horn (Gast)


Lesenswert?

Hi, Andreas,

die Teufel lauern auch bei Deiner Aufgabe im Detail. In dem, was der 
Entwickler ins seiner Konzentration auf die vermeintlichen 
Hauptschwierigkeiten übersieht.
Insbesondere Rauschen, Störungen durch andere Sender, 
Mehrwellenausbreitung.

Vor eigenen Entwürfen empfehle ich daher die intensive Beschäftigung, 
Nachbau und Experimente mit dem Amateur-Packet Radio. Oder mit anderen 
bewährten und gut dokumentierten Lösungen.

Um Dir noch etwas mehr heilsame Angst zu machen: Was bewirken Störungen, 
die in eine verschlüsselte Übertragung einfallen?

Ciao
Wolfgang Horn

von Peter (Gast)


Lesenswert?

das Verfahren von Adreas ist aber nicht sicher. Man kann jede Nachricht 
mit jedem Schlüssel entschlüsseln (bei AES) - man bekommt immer etwas 
raus weiss aber nicht ob das ergebniss richtig ist. Somit kann ein 
"falscher" Sender vieles schicken und es ist gar nicht so 
unwahrscheinlich das der Counter richtig ist, aber der Rest nur müll 
enthält, womit der Controller irgendwas macht
Das wichtigste fehlt: eine Verifikation und dafür braucht es keine 
Verschlüsselung mit AES.

Wenn du in google einfach mal nach Public-key signatur suchst sollte 
sich doch was finden lassen.

von Reinhard (Gast)


Lesenswert?

Da muss ich doch mal einiges richtigstellen, der letzte Beitrag bringt 
zuviel durcheinander. Dass hier gesicherte Folgenummern zur Vermeidung
von Replay-Attacken erwähnt werden, ist schon mal sehr gut.

Der "Trick" ist einfach, sowohl über die Absenderkennung, über die 
Nachricht als auch über die Folgenummer eine kryptografische Prüfsumme 
zu bilden. Das ist im einfachsten Fall der sog. CBC-MAC, und wenn die 
Nachrichtenlänge im Header enthalten ist, reicht auch der einfache 
CBC-Mode - man nimmt den letzten Block bzw. einen Teil davon als 
Prüfsumme (wer Details braucht: Schneiers Angewandte Kryptografie, oder 
mein "Abenteuer Kryptologie", ist auf der Heise-Security-CD als PDF 
enthalten).

Verschlüsselt wird hierbei nichts, es geht nur um den Integritätsschutz,
also zu verhindern, dass jemand die Nachricht verfälscht oder unerkannt 
erneut sendet. Man braucht nur AES-Verschlüsselung dazu, das geht auch 
auf 8-Bit-Prozessoren schnell und braucht wenig Platz (Richtwert: 2-3KB 
Programm). Integritätsschutz ist in der Regel wichtiger als 
Verschlüsselung.

Nachteil: Der gemeinsame Schlüssel muss auf anderem Weg übermittelt 
werden. In der Praxis ist das jedoch meist nicht das Problem. Wenn doch, 
dann braucht man erhebliche Rechenressourcen (RSA ist langsam!) und 
nicht zu unterschätzendes Know-How, um keine Sicherheitslücken 
aufzureißen. Wie gesagt, in der Regel Overkill.

CCM* ist nicht sonderlich elegant, aber etwas einfacher zu 
implementieren, als es scheint. Wie gesagt - CBC-MAC reicht in den 
meisten Fällen.

Reinhard

von Peter (Gast)


Lesenswert?

Hallo,
> Verschlüsselt wird hierbei nichts, es geht nur um den Integritätsschutz,
> also zu verhindern, dass jemand die Nachricht verfälscht oder unerkannt
> erneut sendet. Man braucht nur AES-Verschlüsselung dazu,

wie soll man mit AES alleine ein Integritätsschutz erreichen?

Leider hat der Threadersteller ja nicht geschrieben um welche Hardware 
es geht, kann ja auch an jedem ende ein Quard-Core sein.
Und wenn es auf einen µC umgesetzt werden soll, dann gibt es ja 
mittlerweise signaturkarten die in Hardware RSA können - sollte doch 
nicht das große Problem sein die anzusteuern.
Auch wurde uns verschwiegen wie sicher das ganze sein soll.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Peter wrote:

> wie soll man mit AES alleine ein Integritätsschutz erreichen?

Um das zu erfahren genügt es, dass du das von Reinhard erwähnte
Stichwort «CBC-MAC» in Google eintippst und dann den entsprechenden
Wikipedia-Artikel liest.

von Andreas R. (blackpuma)


Lesenswert?

Ich möchte das mit einem PIC umsetzten. Es geht um die Kommunikation mit 
einem Modellflugzeug. In das möchte ich eine Kamera einbauen und diese 
Steuern.

Ist schon klar, dass das nicht sicher sein muss aber nachdem mich das 
interessiert möchte ich das gleich mit einbauen.

Sicherheit ist Definitionssache. Es sollen nur Packete von einem Sender 
entgegengenommen werden und die Daten sollen nicht im klartext 
übertragen werden.

LG
Andreas

von Peter (Gast)


Lesenswert?

> Um das zu erfahren genügt es, dass du das von Reinhard erwähnte
> Stichwort «CBC-MAC» in Google eintippst und dann den entsprechenden
> Wikipedia-Artikel liest.
Gut man kann es auch dafür verwenden, aber das ganze beruht dann wieder 
auf dem geheimniss des Schlüssels (welche schon mindestens 2 Leute 
kennen) und das reicht für den Zweck bestimmt auch raus, aber am Anfang 
des Threads war nicht ersichtlich was wirklich gefordert war.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Er schrob irgendwo was davon, dass er es in Erwägung zieht, den
Schlüssel auf einem EEPROM zu verteilen.  Damit war eigentlich
der Weg klar.

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
Noch kein Account? Hier anmelden.