INFO: Dieses Forum nutzt Cookies...
Cookies sind für den Betrieb des Forums unverzichtbar. Mit der Nutzung des Forums erklärst Du dich damit einverstanden, dass wir Cookies verwenden.

Es wird in jedem Fall ein Cookie gesetzt um diesen Hinweis nicht mehr zu erhalten. Desweiteren setzen wir Google Adsense und Google Analytics ein.

Antwort schreiben 
 
Themabewertung:
  • 1 Bewertungen - 5 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
Sichere Übertragung mit NRF24
18.03.2014, 15:08
Beitrag #9
RE: Sichere Übertragung mit NRF24
Hallo itsy,

Zitat:Mein aktueller Code nutzt jedoch zum Senden und Empfangen entweder ein int- oder ein float-Array (je nach zu übertragenen Werte).
Diese Zeichenkette kann ich jetzt natürlich nicht mit einem int oder float übertragen. Also muss ich entweder meinen kompletten Code umschreiben (was aber zu viel Arbeit wäre) oder eine andere Lösung suchen ...
Das hört sich nicht gut an Huh
Würde es was bringen wenn du vor dem Senden itoa() bzw. ftoa() benutzt und nach dem Empfang atoi() bzw. atof() ?
Dann sollte sich die Codeänderung doch in Grenzen halten, oder?

Grüße RK

Nüchtern betrachtet...ist besoffen besser Big Grin
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
18.03.2014, 21:21 (Dieser Beitrag wurde zuletzt bearbeitet: 18.03.2014 22:18 von itsy.)
Beitrag #10
RE: Sichere Übertragung mit NRF24
Hi Ricardo,

also wenn das klappen würde, dann wären wir schon einen Schritt weiter :-)

Versuche es die ganze Zeit schon zu testen, aber irgendwo habe ich einen Denkfehler. Da ich den Befehl nicht kenne habe ich mich im Netz eingelesen und nun bekomme ich zumindest keine Fehlermeldung mehr. Aber alleine bei der Konvertierung zu int, bekomme ich kein vernünftiges Ergebnis (0). Was mache ich falsch?

Code:
#include <AESLib.h>
#include <stdlib.h>

uint8_t key[] = {1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16};
char data[] = "0123456789015325"; //16 chars == 16 bytes
uint32_t zeit;
int intconvert;

void setup() {
  Serial.begin(9600);
}

void loop() {
  zeit = millis();
  aes128_enc_single(key, data);
  Serial.print("encrypted:");
  Serial.println(data);
  intconvert = atoi(data);
  Serial.print("intconvert:");
  Serial.println(intconvert);
  aes128_dec_single(key, data);
  Serial.print("decrypted:");
  Serial.println(data);
  Serial.println(millis()-zeit);
  delay(3000);
}

Viele Grüße
itsy

Hier mal ein Screenshot

   

Ich glaube, dass ich auch einen Denkfehler bei dem ganzen System gemacht habe ...

Eine verschlüsselte Variable als Authentifizierung mitzusenden macht ja gar keinen Sinn Big Grin

Eigentlich müsste ich in einem separaten Schritt als spezielle Schlüsselübertragung vom Master an die Clients das verschlüsselte Char-Array senden. Der Client entschlüsselt dann mit dem im Client hinterlegten Key diese empfangenen Daten. Dann sendet der Master seine Befehle mit der entschlüsselten Variable als Authentifizierung mit der normalen Sendung mit. Stimmt diese Variable mit dem was entschlüsselt wurde überein (im Client) dann regiert der Client.

Aber auch das hat einen Haken ... sende ich einfach mit einem fremden Master eine verschlüsselte Variable - egal was, dann entschlüsselt es der Client und wird folglich von meinem Master keine Befehle mehr annehmen, weil ja ein falscher Schlüssel hinterlegt ist. Die Clients sind damit quasi blockiert!

Und wenn ich nun auch die Richtung Client -> Master absichern möchte (sonst könnte einfach jeder beim mir z.B. einen Alarm auslösen) müsste jeder Client mit dem Master die gleiche Authentifizierung vornehmen. Das gleiche Spiel dann auch nochmal mit dem Schalter ... puuuhhh - vielleicht dann besser in einem Schritt die schlüssel gegenseitig austauschen ...

Das Sicherheitsproblem bleibt aber ...

Mittlerweile glaube ich, dass wir das nicht hinbekommen - zumindest nicht, wenn der aktuelle Gedanke so weitergeführt wird :-(

Viele Grüße
itsy

ok, nächste Idee, bis ich einen Haken finde ;-)

Voraussetzung ist, dass ich das verschlüsselte Char-Array in Int umwandeln kann!

char data[] = "0123456789012345" - hier wird die unverschlüsselte Variable hinterlegt - ist immer 16 Bytes groß.
Also würde ich z.B. ab data[5] meine Clientnummer hinterlegen:
char data[] = "012345CLIENT2345" - die anderen Stellen würde ich mit Random-Zahlen füllen.
Dann -> verschlüsseln -> umwandeln in int -> statt der Clientnummer im normalen Code mitsenden
Beim Empfänger dann -> umwandeln in char -> entschlüsseln und schauen, ob von char[5] bis char[11] meine Clientnummer steht.

Ob das funktioniert ? Oder gibt es dort wieder einen Haken? Dann braucht man auch keinen Schlüssel austauschen, sondern nur ein mal hinterlegen.

Viele Grüße
itsy
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
18.03.2014, 22:24
Beitrag #11
RE: Sichere Übertragung mit NRF24
... wieder ein Denkfehler, da man auch die verschlüsselte Datei genau wie die unverschlüsselte Clientnummer nutzen kann :,-(
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
19.03.2014, 08:27
Beitrag #12
RE: Sichere Übertragung mit NRF24
Moin itsy,

ich gehe jetzt mal nicht richtig tief in deine Posts rein (habs eilig), schreibe lieber mal mein Denkmodell auf, basierend auf dieser Aussage:
Zitat:Master sendet Array als Broadcast: 12345 0 0 0 0
Die Clientnummer 12345 ist für eine Temperaturabfrage hinterlegt.
Der Client auf dem diese Nummer eingetragen ist antwortet dann mit:
12345 22.5 45 - also seiner Clientnummer Grad in Celsius und Luftfeuchte
Wir hatten davon gesprochen noch eine Authentifizierung zu hinterlegen, also sollte aus "12345 0 0 0 0" dann sowas wie "12345 0 0 0 0 x" werden.
Wenn wir es in ein "Netzwerk-Modell" umdenken und Broadcast voraussetzen, ergeben sich folgende Bestandteile der Sequenz:
a) "12345" - ist die theoretische "Ip-Adresse"
b) "0 0 0 0" - ist der eigentliche Befehl
c) "x" - ist die Authentisierung

Nur b) kann verschlüsselt werden!!! a) und c) bleiben lesbar, es sei denn du realisierst 2a) und 3a) - weiter unten -.

Mein Denkmodell:
(Erstmal ohne Beachtung der Befehlsformate (int/float), die sind eine reine Frage der Programmierung, haben aber nix mit dem Datenfluss an sich zu tun!

1. auf Server und Client "Hauptschlüssel" mit getrenntem Sketch in EEPROM ablegen (um den Hauptschlüssel zu finden müsste man den Arduino klauen und den EEPROM auslesen)
2. Server sendet zyklisch einen festgelegten mit dem Hauptschlüssel verschlüsselten Befehl an alle Clients zur Änderung des eigentlichen Datenschlüssel
2a. Alternativ kannst du für c) einen "Authentifizierungsschlüssel" auf allen Clients hinterlegen. Dann kann die Authentifizierung auch geschlüsselt werden.
3. Vor dem Senden der Standardbefehle wird in jedem Fall b) mit dem aktuellen Datenschlüssel geschlüsselt
3a. Wenn genutzt, wird auch die Authentifizierung geschlüsselt

Beim Empfang werden b) und - wenn genutzt c) - entschlüsselt.

Damit würdest du erreichen, dass:
1. Die Start-/Zieladressen lesbar sind (das muss auch sein, da sich sonst die Geräte nicht angesprochen fühlen)
2. Der eigentliche Befehl wird verschlüsselt
3. Die Authentifizierung wird verschlüsselt - wenn 2a) und 3a) genutzt -

Hier muss man jetzt die Frage stellen ob wir vom gleichen reden. Wenn nicht, korrigiere mich und versuche es mal in gleicher Manier zu schreiben.

Die Codierung ist dann die kleinere Herausforderung!

Grüße Ricardo

Nüchtern betrachtet...ist besoffen besser Big Grin
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
20.03.2014, 20:24
Beitrag #13
RE: Sichere Übertragung mit NRF24
Hallo Ricardo,

leider habe ich es gestern nicht mehr geschafft zu antworten.

Fangen wir gleich mal mit dem größten Problem hierbei an.
Ich habe ein int-Array aus 6 Feldern. Das erste Feld ist die Clientnummer, die nicht verschlüsselt wird - bleiben also noch 5. Auch benötige ich nicht bei jeder Übertragung 5 Felder.Allerdings muss das Data-Array der Verschlüsselungs-Lib 16 Bytes groß sein (das ist vorgegeben und man kann auch nicht davon abweichen). Der max. Payload mit der NRF24-Lib von maniacbug ist 32 Bytes. Wenn ich also alleine den Client übertrage, dann kann ich max 1 Feld noch verschlüsseln, was nicht ausreicht.

Bleibt also eigentlich nur die Möglichkeit ein einziges Feld zu verschlüsseln und das wäre dann die Authentifizierung oder wie immer wir das nennen möchten.

Dieses Feld, egal wie es ver- und entschlüsselt wird, muss ermöglichen, dass der Empfänger damit sicherstellen kann, dass der Datensatz von meinem System stammt.

Gehen wir als Beispiel von 5 Relais und 5 Alarmclients aus, die permanent abgefragt werden (hierbei möchte man ja keine Verzögerung haben).

Dieses Feld muss eigentlich für jeden Client unterschiedlich sein und auch ständig geändert werden, denn wenn immer die gleiche Authentifizierung gesendet wird, könnte man einfach nur dieses Feld, verschlüsselt wie es ist an einen fremden Befehl hängen und hätte damit auch die Authentifizierung, wodurch es keine Authentifizierung mehr ist.

Also was sollte jetzt zur Authentifizierung verschlüsselt und versendet werden, wenn man diese Vorgaben im Kopf hat?

Aber vielleicht gibt es auch eine andere Möglichkeit ...

Viele Grüße
itsy
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
21.03.2014, 10:10
Beitrag #14
RE: Sichere Übertragung mit NRF24
Heute habe schön nen Tag Resturlaub - also Zeit sich weiter Gedanken zu machen :-)

Wir haben also 12345 0 0 0 X

Mit X müssen wir sicherstellen, dass es sich um eine eigene Abfrage / einen eigenen Befehl handelt.

X muss sich dabei ständig ändern damit ihn ein Angreifer nicht so einfach empfangen und erneut verwendet werden kann.

Eine neue Idee, um das zumindest einzuschränken:

Wir gleichen die Zeit oder einen Zeitstempel auf allen Systemen regelmäßig ab.

X ist dabei der aktuelle verschlüsselte Zeitstempel, der bei jedem Senden mit übermittelt wird. Der Empfänger entschlüsselt den Zeitstempel und bekommt damit die aktuelle Zeit vom Sender. Nun kann der Empfänger überprüfen, ob diese Zeit mit der Zeit des eigenen Systems übereinstimmt +- X Sekunden / Millisekunden.

Damit würde ich einen Schlüssel generieren, der nur für kurze Zeit Gültigkeit hat.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
21.03.2014, 12:32
Beitrag #15
RE: Sichere Übertragung mit NRF24
Hallo itsy,

wenn ich dich richtig verstehe, gehst du (gezwungener Maßen) von der Verschlüsselung des eigentlichen Befehls weg zur Authentifizierung, also Sicherstellung, dass die "Sequenzen" nur an/von den zugehörigen Geräten gesendet/empfangen werden. Soweit ist die Idee io.
Zitat:X ist dabei der aktuelle verschlüsselte Zeitstempel, der bei jedem Senden mit übermittelt wird. Der Empfänger entschlüsselt den Zeitstempel und bekommt damit die aktuelle Zeit vom Sender. Nun kann der Empfänger überprüfen, ob diese Zeit mit der Zeit des eigenen Systems übereinstimmt +- X Sekunden / Millisekunden.
Damit würde ich einen Schlüssel generieren, der nur für kurze Zeit Gültigkeit hat.
Allerdings interpretiere ich das so, dass du einen statischen Schlüssel benutzen würdest!?
So eigenartig es klingt, sollte man es komplexer machen um hier mehr Sicherheit zu bekommen. Idee:
- wieder der Hauptschlüssel, mit gesondertem Sketch im EEPROM überall abgelegt
- mit diesem Hauptschlüssel einen zeitlich begrenzt gültigen randomisierten "Seesion-Schlüssel" verschlüsseln und zyklisch überall ablegen
- Solange dieser "Session-Schlüssel" gilt, mit diesem den Zeitstempel verschlüsseln
Ist das sinnvoll? Huh

Grüße Ricardo

Nüchtern betrachtet...ist besoffen besser Big Grin
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
21.03.2014, 13:14
Beitrag #16
RE: Sichere Übertragung mit NRF24
Hi Ricardo,

ich denke, das wäre dann dir Kür :-)

Einen Schlüssel zyklisch zu ändern, denke ich wäre das wenigste - aber eine gute Idee!

Mit dem System haben wir glaube ich aber jetzt erst einmal ein relativ sicheres System (Lücken gibt es hierbei wahrscheinlich immer - aber eben nicht so große).

Jetzt ist es wohl die nächste Herausforderung dies umzusetzen.

Das Problem hierbei ist, dass die Lib zum NRF24 ein Array zum Senden vorsieht:

int messagex[6] = {0,0,0,0,0,0};
radio.write( &messagex, sizeof(messagex));

Aber die verschlüsselte Datei ist größer als ein int und wenn ich das Array aus Typen erstelle, welches die verschlüsselte Datei aufnimmt, dann ist das gesamte Array größer als der max. Payload ...

Viele Grüße
itsy
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
Antwort schreiben 


Möglicherweise verwandte Themen...
Thema: Verfasser Antworten: Ansichten: Letzter Beitrag
  nrf24 an Mega 2560 jgrothe 2 163 10.09.2016 13:39
Letzter Beitrag: jgrothe
  Temperatur mit nrf24 übertragen jgrothe 17 671 09.09.2016 14:01
Letzter Beitrag: jgrothe
  Interrupt bei Serieller Übertragung Binatone 8 364 21.06.2016 14:09
Letzter Beitrag: Scheams
  NRF24 soll Daten empfangen und senden... MaHaI976 2 941 08.06.2015 19:36
Letzter Beitrag: MaHaI976
  float per NRF24 übertragen F2Ingo 9 1.650 14.04.2015 21:21
Letzter Beitrag: F2Ingo
  Accelerometerwert Übertragung via Bluetooth??? Brauche HIlfe Techniker2012 2 4.775 03.07.2014 18:21
Letzter Beitrag: rkuehle

Gehe zu:


Benutzer, die gerade dieses Thema anschauen: 1 Gast/Gäste