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
21.03.2014, 14:31
Beitrag #17
RE: Sichere Übertragung mit NRF24
Hallo itsy,

ich glaube wir haben jetzt alle Möglichkeiten / Unsicherheiten abgewogen und durchgesprochen. Jetzt sollten wir kurz innehalten und aufschreiben wie es nach jetzigem Stand ablaufen soll. Das ist einfach notwendig, wenn noch jemand mitmachen soll/möchte (zB. meine Wenigkeit).

Du schreibst jetzt bitte mittels Beispiel alle möglichen auftretenden Datenflüsse / Abläufe auf (Schlüsselverteilung, Befehl Master -> Slave, Antwort Slave -> Master). Ich muss das mal als "Pseudocode" sehen. Dabei bitte unbedingt auch nochmal den Aufbau der "Datensequenzen" mitgeben und die Anzeige welche Sequenzanteile womit geschlüsselt werden. Wenn machbar zu jedem Ablauf den von dir bisher gesetzten Code und kurze Info was dabei nicht funktioniert.

Nur ganz nebenbei: was hier in deinem Thread passiert ist beinahe Grundlagenforschung und somit einerseits nicht trivial, andererseits durchaus sehr nutzbringend für die Community!

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, 18:36 (Dieser Beitrag wurde zuletzt bearbeitet: 21.03.2014 19:08 von itsy.)
Beitrag #18
RE: Sichere Übertragung mit NRF24
Hallo Ricardo,

na das klingt doch super - dann fange ich gleich mal an :-)

Ich versuche es jetzt mal möglichst übersichtlich aufzubauen, damit jeder einsteigen kann!

----------------------------------------------------------------------------------------------
Einleitung:
Das System ist eine Homeautomation. Es gibt einen Master, der die Steuerung, die Verbindung ins Web und die Funkverbindung zu den Clients übernimmt. Der Vollständigkeitshalber evtl. bei der weiteren Entwicklung: Es gibt auch einen TFT-Client als mobilen Monitor mit diversen Funktionen.

Funkverbindung mit NRF24:
Der Master sendet quasi als Broadcast an alle Clients ein Array, welches immer aus 6 Feldern besteht:

12345 0 0 0 0 X

- 12345 ist in diesem Beispiel die Clientnummer, die angesprochen werden soll
- 0 steht für Anweisungen die übergeben werden
- X steht für die Art der Sendung, welche z.B. auch für den TFT-Client verwendet wird (mehr dazu später)

Dieser Broadcast ist entweder eine Abfrage auf die ein Client antworten soll (schicke mir die Temperatur Deines Sensors) oder ein Befehl auf die ein Client reagiert (schalte Dein Relais).

Die Antwort des Clients ist identisch aufgebaut, wobei der Client seine eigene Clientnummer mit an den Master zur Verifizierung zurück sendet.

Je nach zu übertragenen Daten wird als Datentyp für das Array entweder int oder float verwendet. Zur Abgrenzung werden hierfür auf 2 verschiedene Pipes verwendet.

Codierung von X:
Temperatur & Luftfeuchte: Anfrage Master: 10 / Antwort Client: 11
Strom: Anfrage Master: 20 / Antwort Client: 22
Gas: Anfrage Master: 30 / Antwort Client: 33
Funkschalter: Anfrage Master: 40 / Befehl Master: 41 / Antwort Client: 44
Alarm: Anfrage Master: 50 / Befehl Master: 51 / Antwort Client: 55

Hier wollen wir nun versuchen die Funkverbindung zwischen Master und Client abzusichern.
----------------------------------------------------------------------------------------------

Genaue Beschreibung der einzelnen Verbindungen folgt gleich ...

Viele Grüße
itsy

Die genauen Verbindungen:

Temperatur & Luftfeuchte

Anfrage von Master:
int message[6] = {TLClientFunk[zaehler],zaehler,0,0,0,10};

- TLClientFunk[zaehler] = in diesem Array sind die Clientnummern gespeichert
- zaehler = dieser Zähler dient nur dem Debugging - der Master fragt bis zu 5 mal ab, wenn er keine Antwort bekommt. Der Zähler zählt dabei hoch.

Antwort von Client:

float message[6] = {TLClientFunk,Temperatur,Luftfeuchte,0,0,11};

- TLClientFunk = Clientnummer
- Temperatur im Format xx.yy
- Luftfeuchte im Format xx.yy


Gas

Anfrage von Master:
int message[6] = {GasClient,zaehler,GasLoopID,0,0,30};

- GasClient = Clientnummer
- zaehler = dieser Zähler dient nur dem Debugging - der Master fragt bis zu 5 mal ab, wenn er keine Antwort bekommt. Der Zähler zählt dabei hoch.
- GasLoopID = das ist eine Random-ID. Diese ID wird erst geändert, wenn der Master die Daten vom Client erfolgreich erhalten hat. Der Client setzt seinen Impulszähler erst auf 0, wenn er eine neue ID erhalten hat. Damit gehen auch, wenn die Funkverbindung oder der Master mal ausfällt keine Impulse verloren. Es geht dann zwar der zeitliche Verlauf verloren, jedoch nicht die verbrauchten KWH

Antwort von Client:
int message[6] = {GasClient,GasImpulsWebconnect,0,0,0,33};

- GasClient = Clientnummer
- GasImpulsWebconnect = hiermit werden die gezählten Gasimpulse übertragen


Strom

Anfrage vom Master:
int message[6] = {StromClient,zaehler,StromLoopID,0,0,20};

Beschreibung wie Gas

Antwort Client:

float message[6] = {StromClient,StromImpulsWebconnect,MillisBetweenWebFaktor,MillisBetweenImpulseFa​ktor,0,22};

- Stromclient = Clientnummer
- StromImpulsWebconnect = Anzahl der Stromimpulse
- MillisBetweenWebFaktor = Zeit in der die Anzahl der Impulse gezählt wurden, um die Leistung zu berechnen und im Web darzustellen
- MillisBetweenImpulseFaktor = Zeit zwischen 2 Impulsen zur aktuellen Anzeige der Leistung auf dem TFT

Warum nutze ich float und warum steht "faktor" im Variablennamen?
Nun, wenn ich nicht daheim bin und alles abgeschaltet habe, dann kann die Zeit zwischen 2 Impulsen auch mal recht lang werden.Und sollte der Master mal ausfallen läuft der generelle Zeitzähler auch "voll" (in Bezug auf den Variablentypen INT). Um dennoch korrekte Zeiten zu übertragen werden diese Werte dividiert (darum float), dann gesendet und beim Master wieder mit diesem Faktor multipliziert.

Fortsetzung folgt ...
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
21.03.2014, 19:47 (Dieser Beitrag wurde zuletzt bearbeitet: 21.03.2014 19:55 von itsy.)
Beitrag #19
RE: Sichere Übertragung mit NRF24
Funkschalter

Anfrage von Master:
int message[6] = {FunkschalterClient[zaehler],zaehler1,0,0,0,40};

- FunkschalterClient[zaehler] =in diesem Array sind die Clientnummern gespeichert von der eine Clientnummer pro Anfrage gesendet wird
- zaehler1 = Dieser Zähler gibt das Relais pro Client an. Es gibt 5 Relais pro Client.

Warum erden die Relais einzeln abgefragt?
Damit habe ich die Möglichkeit die Relais auf einzelne Clients zu verteilen, so wie ich sie grade benötige. Nicht immer brauche ich 5 Relais an einem Standort. Der Client verifiziert somit zunächst die Clientnummer und dann ob das Relais dort auch aktiviert ist. Erst wenn das der Fall ist, wird geantwortet.

Antwort von Client:
int message[6] = {FunkschalterClient, got_message[1], RelaisStatus, 0, 0, 44};

- FunkschalterClient = Clientnummer
- got_message[1] = hiermit wird die angefragte Relaisnummer an den Master zurück gesendet - gleiches Prinzip wie bei der Clientnummer, hierbei findet die verifizierung aber über Clientnummer und Relaisnummer statt.
- Relaisstatus = an (1) oder aus (0). Damit stelle ich sicher, dass der Schalter wirklich den Status hat, den ich haben möchte

Befehle von Master:
int message[6] = {FunkschalterClient[zaehler],zaehler1,SollwertFunkschalter[zaehler][zaehler1],0,0,41};

Hiermit erhalten die Clients für die Einzelnen Relais entsprechende Schaltbefehle. Es ist deshalb separat und nicht bidirektional, weil das Web und andere Funktionen dazwischen geschaltet sind.


Alarm

Anfrage von Master:
int message[6] = {AlarmClient, zaehler , 0 , 0 ,0 ,50};

- AlarmClient = Clientnummer
- zaehler = das ist eine Art Sensornummer. Einem Client sind 10 Sensoren zugeordnet. Das Prinzip ist wie bei den Relais. Im Gegensatz dazu gibt es aber nur ein Sensor pro Hardwareclient.

Warum 10 Sensoren pro Clientnummer, wenn nur 1 Sensor pro Hardwareclient möglich ist?
Weil das so in der Webansicht verwaltet wird.


Antwort von Client:
int message[6] = {AlarmClient, AlarmSensor, Alarmstatus, 0, 0, 55};

Beschreibung ist äquivalent zum Funkschalter

Befehle von Master:
int message[6] = {AlarmClient,99,ClientAlarmverhalten,ClientAlarmdauerAn,ClientAlarmdauerAus,51};​

- AlarmClient = Clientnummer
- 99 = an dieser Stelle könnte man die einzelnen Sensoren separat ansprechen - das ist in der aktuellen Version allerdings noch nicht realisiert. 99 Steht dafür, dass sich alle Client angesprochen fühlen.
- ClientAlarmverhalten: Hiermit wird das Verhalten der Alarmclients übertragen. Sie können entweder autonom arbeiten d.h. schalgen sie Alarm, dann schalten den Alarmport an (z.B. für Licht, Sirene etc.) oder vom Master gesteuert. Bei der Steuerung über den Master alarmiert der Master alle Clients, wenn ein Client einen Alarm bei der Statusabfrage an den Master sendet. So könnte beim Alarm im Flur z.B. überall im Haus das Licht eingeschaltet werden. Auch könnte man überall im Haus eine Sirene schalten, was es einem Einbrecher unmöglich macht, einfach nur ein Kabel durchzuschneiden um Ruhe zu bekommen. Der Master sendet dabei nur 1 für an oder 2 für aus. Wird der Master zerstört kann er kein aus mehr senden und alles bleibt an :-)
- ClientAlarmdauerAn = wie lange soll der Alarmausgang eingeschaltet sein, wenn ein Alarm ausgelöst wird (1-9 wobei ein Faktor daraus dann z.B. 5, 10, 15 ... Sekunden macht)
- ClientAlarmdauerAus = wie lange soll der Ausgang ausgeschaltet sein (auch wenn immer noch ein Alarm anliegt) bis der nächste Alarm ausgelöst wird (gilt nur für den Alarmausgang und nicht für die Statusübertragung an den Master bzw. ins Netz).

ClientAlarmdauerAn & ClientAlarmdauerAus haben nur Auswirkung, wenn der Client autonom arbeitet - der Master selbst hat ebnfalls solche Einstellungen, womit er dann auch die Client steuern kann.

Die Einstellungen selbst werden über das Web konfiguriert, womit man dann auch den Alarm abschalten kann.

Gibt es keine Möglichkeit den Alarm ohne das Web zu schalten?
Aktuell nicht, aber es ist vorbereitet. Das Alarmsensorarray hat Felder von 0 - 10.
Moment, bei 10 ist das doch ein Feld zuviel! Richtig! Der Sensor 0 ist nämlich die Vorbereitung für eine Fernbedienung. Der Master fragt sie wie jeden Client ab, aber die Antwort von Sensor 0 wird dann einen Befehl im Master auslösen.

Wie Ihr seht, ist das Projekt schon recht umfangreich und läuft bereits ohne Probleme.
Wünschenswert wäre es bei der Herausforderung der sicheren Übertragung, wenn der Code nicht komplett umgeschrieben werden müsste.
Und bei allen Überlegungen muss berücksichtigt werden, dass es sich um eine Funkverbindung handelt und nicht immer alle Sendungen direkt ankommen müssen.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
29.03.2014, 16:48 (Dieser Beitrag wurde zuletzt bearbeitet: 29.03.2014 16:50 von rkuehle.)
Beitrag #20
RE: Sichere Übertragung mit NRF24
Hallo itsy,

es könnte sein, dass mir was sinnvolles eingefallen ist Huh
Schau dir mal die TOTP - Lib an. Siehe hier: http://www.lucadentella.it/en/totp-libre...r-arduino/
Diese Lib generiert ein sogenanntes "Time based One Time Password" aus einem hinterlegten Password und der aktuellen Zeit. -> Master / Clients müssen über gleiche Zeit verfügen
Vorstellung:
- Password wird im EEPROM hinterlegt (wie immer mit isoliertem Sketch)
- aus diesem und der aktuellen Zeit wird ein Token generiert
- mit diesem Token wird alles nach der Client-Nummer verschlüsselt
- auf Clientseite wird (die gleiche Zeit vorausgesetzt) bei Broadcastempfang das gleiche Token berechnet und damit der AES-geschlüsselte Anteil entschlüsselt.
Zum verschlüsseln habe ich hier: https://github.com/yanavery/MyDoorOpener-Arduino eine AES-Lib gefunden, die Byte-orientiert arbeitet.
Generell würde ich alle Arrays auf float mit festgelegter Anzahl Nachkommastellen umschreiben. So muss man nicht unterschiedliche Anfragen / Antworten unterschiedlich behandeln.

Grüße Ricardo

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

das klingt nach einer prima Idee :-)

Ich habe die TOTP Lib auch schon getestet (nachdem ich erstmal die funktionierenden restlichen beiden Libs gefunden und eingebunden habe ;-) ).

Ich hatte nämlich zuerst bedenken, wie genau Sender und Empfänger synchronisiert sein müssen, da mit einem Timestamp d.h. auf Sekundenbasis gearbeitet wird.
Aber es funktioniert auch, wenn die die beiden Testardus ein wenig zeitversetzt starte und auch mit einem Delay bei der Erstellung des Schlüssels :-)

Bei der swRTC Lib habe ich zwar kein Beispiel für einen direkten NTP-Server über das Netzwerk, aber eigentlich ist das auch egal, denn es muss auf den Systemen nur die gleiche Zeit eingestellt sein - egal welche. Wobei ich mal testen müsste, ob ich mit der Time Lib die Zeit über NTP einstellen und dann mit der RTC-Lib auslesen kann.

Die Herausforderung wird es jetzt wohl erstmal sein, alle Variablentypen etc. unter einen Hut zu bekommen und korrekt umzuwandeln. Die komplette Verschlüsselung fürde ich dann aber über eine Funktion einbauen - dann bleibt mein Code, wenn alles klappt, ohne große Änderung und die Sache wäre, wenn mal alles läuft, schnell implementiert -> originales Array zum Senden an die Funktion übergeben und verschlüsseltes Array zurück bekommen und das dann senden - zum Empfangen dann genau umgekehrt. Wenn sie allgemein gehalten ist, dann können auch andere Foris, die eine verschlüsselte Verbindung haben möchten diesen Schnipsel einfach nutzen.

Das wird ne Weile Dauern ;-)

Ich werde dann mal einen Testsketch hier hochladen, wenn ich alles unter einem Hut habe. Denke, jetzt geht es an die Programmierung - die Richtung ist ja jetzt klar!!

Vielen Dank dafür!
itsy
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
30.03.2014, 17:04 (Dieser Beitrag wurde zuletzt bearbeitet: 30.03.2014 17:12 von rkuehle.)
Beitrag #22
RE: Sichere Übertragung mit NRF24
Hallo itsy,

hört sich insgesamt gut an.
Zitat:Ich hatte nämlich zuerst bedenken, wie genau Sender und Empfänger synchronisiert sein müssen,
Sollte kein Problem sein, da die Token für 30 Sekunden gelten.
Zitat:Wobei ich mal testen müsste, ob ich mit der Time Lib die Zeit über NTP einstellen und dann mit der RTC-Lib auslesen kann
Ein NTP-Beispiel habe ich mal in die Tutorials gestellt. Ist zwar auf Basis DHCP, lässt sich aber schnell auf fixe Adresse umschreiben. Das dann auf den Master und mit setTime() im Setup die Zeit auf dem Master setzen. Durch setSyncInterval() wird die Zeit dann neu abgeglichen. Für die Übertragung der Zeit Master an Clients noch eine Befehlssequenz entwerfen und auf die Clients verteilen. Schon kannst du dir die RTC sparen.
Zitat: denn es muss auf den Systemen nur die gleiche Zeit eingestellt sein - egal welche
Könnte man im Sinne der TOTP - Lib soghar als Feature verwerten Smile
Zitat:alle Variablentypen etc. unter einen Hut zu bekommen und korrekt umzuwandeln
Da der Arduino vom grunde her nett ist reicht folgendes um aus int float zu machen:
Code:
int w1=2
float w2=w1*1.00

Zitat: originales Array zum Senden an die Funktion übergeben und verschlüsseltes Array zurück bekommen und das dann senden - zum Empfangen dann genau umgekehrt
Genauso muss das laufen.

Grüße Ricardo

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

die Konvertierung ist für mich anscheinend aber die Größte Hürde.
Dadurch scheint der Ardu nun überlastet (zu große Keys?). In einem vorherigen Sketch hatte alles funktioniert - durch diese Konvertierungen hängt er oder gibt zumindest auch nicht mehr alle Zeilen aus.

Hier mal der Sketch in den ich auch die todos geschrieben habe. Dabei handelt es sich ausschließlich um Konvertierungen:

Code:
// Libs
//-------------------------
#include "sha1.h"  
#include "TOTP.h"  
#include "swRTC.h"
#include "aes256.h"  
//-------------------------


// TOTP Debug
//-------------------------
#define DUMP(str, i, buf, sz) { Serial.println(str); \
                               for(i=0; i<(sz); ++i) { if(buf[i]<0x10) Serial.print('0'); Serial.print(char(buf[i]), HEX); } \
                               Serial.println(); } //Help function for printing the Output
int AESCount;
//-------------------------

// Einstellungen
//-------------------------
const int AESCodelaenge = 7;
// TOTPKeyChar - todo: Eingabe des TOTPKey als char d.h. realen Text
//-------------------------


// TOTP
//-------------------------
uint8_t TOTPKey[] = {0x4d, 0x79, 0x4c, 0x65, 0x67, 0x6f}; // Shared Key für TOTP  
TOTP totp = TOTP(TOTPKey, AESCodelaenge); // TOTPKey und Länge des generierten Code für Funktion setzen
char TOTPCode[AESCodelaenge]; // Ausgabe für generierten TOTP Code
//-------------------------


// swRTC
//-------------------------
swRTC rtc;  // RTC-Funktion starten
//-------------------------


// AES
//-------------------------
aes256_context ctxt; // AES-Funktion starten
uint8_t AESKey[AESCodelaenge]; // Key für AES-Verschlüsselung -> TOTP Code
uint8_t AESData[] = {1,2};
// todo: Vor unr Rück-Konvertierung des int-Array zum Senden über den NRF in das Array AESData zum Verschlüsseln
//-------------------------

  
  
void setup() {
  
  Serial.begin(9600);
  
  // Zeit einstellen
  //-------------------------
  rtc.stopRTC();
  
  // Adjust the following values to match the current date and time
  // and power on Arduino at the time set (use GMT timezone!)
  rtc.setDate(27, 8, 2013);
  rtc.setTime(21, 25, 00);
  
  rtc.startRTC();
  //-------------------------
  
}

void loop() {  
  
  // TOTP Code erstellen
  //-------------------------  
  long GMT = rtc.getTimestamp();
  char* newCode = totp.getCode(GMT);
  if(strcmp(TOTPCode, newCode) != 0) {
    strcpy(TOTPCode, newCode);
  //-------------------------    
    
  // Copy TOTPCode in AESKey mit konvertierung von char* to unint8_t
  //-------------------------      
    for(int n = 0; n < sizeof(TOTPCode); n++){  
      AESKey[n]=TOTPCode[n];
    }
   //-------------------------  
    
    
  // Kontrollausgabe AESKey und TOTPCode
  //-------------------------  
    Serial.print("TOTPCode:");  
    for(int n = 0; n < sizeof(TOTPCode); n++){  
      Serial.print(TOTPCode[n]);
    }
    Serial.println();
    
    Serial.print("AESKey:");  
    for(int n = 0; n < sizeof(AESKey); n++){  
      Serial.print(AESKey[n]);
    }
    Serial.println();    
    
    // todo: Copy / Konvertierung scheint nicht sauber zu funktionieren da beide Ausgaben unterschiedlich
   //-------------------------
  
    // Die Ausgabe mit diesem Dump ist allerdings identisch
    // DUMP("Key: ", AESCount, AESKey, sizeof(AESKey));
    // DUMP("Code: ", AESCount, TOTPCode, sizeof(TOTPCode));
    
    
    aes256_init(&ctxt, AESKey); // AES mit AESKey initialisieren
    delay(100);
    
    DUMP("Unencrypted data: ", AESCount, AESData, sizeof(AESData)); // Ausgabe unverschlüsselte Daten
    
    aes256_encrypt_ecb(&ctxt, AESData); // AESData verschlüsseln
    
    DUMP("Encrypted data: ", AESCount, AESData, sizeof(AESData)); // Ausgabe verschlüsselte Daten
    
    aes256_decrypt_ecb(&ctxt, AESData); // AESData entschlüsseln
    delay(100);
    DUMP("Back decrypted data: ", AESCount, AESData, sizeof(AESData));// Ausgabe entschlüsselte Daten
    
    Serial.println("---------------------------------");
    
    aes256_done(&ctxt);
  
}}


Viele Grüße
itsy

Hier ist mal der Test-Sketch, der noch richtig funktioniert hat - vielleicht habe ich ja auch noch einen anderen Fehler eingebaut:

Code:
#include "sha1.h"  
#include "TOTP.h"  
#include "swRTC.h"
#include "aes256.h"  

// TOTP Debug
#define DUMP(str, i, buf, sz) { Serial.println(str); \
                               for(i=0; i<(sz); ++i) { if(buf[i]<0x10) Serial.print('0'); Serial.print(char(buf[i]), HEX); } \
                               Serial.println(); } //Help function for printing the Output

// Shared Secret für  TOTP
uint8_t hmacKey[] = {0x4d, 0x79, 0x4c, 0x65, 0x67, 0x6f, 0x44, 0x6f};  

TOTP totp = TOTP(hmacKey, 7);  
swRTC rtc;  
char code[7];  

int AESCount;

aes256_context ctxt;

uint8_t key[7];

uint8_t data[] = {1,2,3,4,5};
  
  
void setup() {
  
  Serial.begin(9600);
  
  // Zeit einstellen
  //-------------------------
  rtc.stopRTC();
  
  // Adjust the following values to match the current date and time
  // and power on Arduino at the time set (use GMT timezone!)
  rtc.setDate(27, 8, 2013);
  rtc.setTime(21, 25, 18);
  
  rtc.startRTC();
  //-------------------------
  
}

void loop() {  
  
  long GMT = rtc.getTimestamp();
  char* newCode = totp.getCode(GMT);
  if(strcmp(code, newCode) != 0) {
    strcpy(code, newCode);
    Serial.print("TOTP Code:");
    Serial.println(code);
    
    Serial.print("Timestamp:");
    Serial.println(GMT);
    
    for(int n = 0; n < sizeof(code); n++){  
      key[n]=code[n];
    }
    
    DUMP("Key: ", AESCount, key, sizeof(key));
    DUMP("Code: ", AESCount, key, sizeof(code));
    
    aes256_init(&ctxt, key);
    DUMP("Unencrypted data: ", AESCount, data, sizeof(data));
    
    aes256_encrypt_ecb(&ctxt, data);
    DUMP("Encrypted data: ", AESCount, data, sizeof(data));
    
    aes256_decrypt_ecb(&ctxt, data);
    DUMP("Back decrypted data: ", AESCount, data, sizeof(data));
    
    Serial.println("---------------------------------");
    
    //aes256_done(&ctxt);
  
}}


Zitat:Sollte kein Problem sein, da die Token für 30 Sekunden gelten.

Theoretisch gibt es trotzdem einen Haken, wenn auch auch in der Praxis zu vernachlässigen ist. Den ersten TOTP-Token (Code) erzeugt er direkt nach Aufruf. Weitere wenn er 00, 30 etc. an den letzten beiden Stellen des Timestamp hat (der erste Code ist also nicht immer 30 Sekunden lang gültig).

Kommen wir nun zum Theoretischen Haken, der Vollständigkeit halber:
Wird 29,xx Sekunden nachdem der aktuelle Code erstellt wurde eine Nachricht verschickt, kann der Empfänger bereits in der "Zwischenzeit" durch das Delay der Verarbeitung beim Sender und Empfänger 00,30, ... im Timestamp haben und es wird ein neuer Code generiert, der die Nachricht nicht mehr entschlüsseln kann. Gleiches gilt natürlich auch bei der Antwort. Eigentlich auch logisch ;-) Man könnte es abfangen, macht aber nicht wirklich viel Sinn.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
01.04.2014, 16:53
Beitrag #24
RE: Sichere Übertragung mit NRF24
So, die Synchronisierung der Zeit auf dem Livesystem funktioniert :-) Die Bibliotheken sind auch schon eingebunden.
Für den restlichen Code hätten wir nun noch max 8k auf dem Client Platz - dann ist er allerdings auch randvoll ... wird also sportlich ;-)
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 166 10.09.2016 13:39
Letzter Beitrag: jgrothe
  Temperatur mit nrf24 übertragen jgrothe 17 675 09.09.2016 14:01
Letzter Beitrag: jgrothe
  Interrupt bei Serieller Übertragung Binatone 8 367 21.06.2016 14:09
Letzter Beitrag: Scheams
  NRF24 soll Daten empfangen und senden... MaHaI976 2 943 08.06.2015 19:36
Letzter Beitrag: MaHaI976
  float per NRF24 übertragen F2Ingo 9 1.654 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