mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Mikrocontroller Authentifizierung fuer Funknetzwerk


Autor: Danish B. (danishbelal)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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"

Autor: H. (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: Samuel C. (neoexacun)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Danish B. (danishbelal)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Tom (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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)

Autor: Danish B. (danishbelal)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/Zukunftssiche...

Autor: Danish B. (danishbelal)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Samuel C. (neoexacun)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/Zukunftssiche...

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.

Autor: Tom (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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).

Autor: Danish B. (danishbelal)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tom (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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 :)

Autor: John (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Alex (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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

Autor: Mark B. (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tom (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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..?

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Danish B. (danishbelal)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Moe S. (loetsinn)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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%BCsselaustau...

z.B. 
https://de.wikipedia.org/wiki/Diffie-Hellman-Schl%...

"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!

Autor: Tom (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Danish B. (danishbelal)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Mark B. (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;)

Autor: wiojlsdfl (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Danish B. (danishbelal)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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"

Autor: Danish B. (danishbelal)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Draco (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Johannes O. (jojo_2)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Alex (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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!

Autor: Draco (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
...

Autor: Draco (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Draco (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Draco (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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!

Autor: zoggl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/tutorialil...


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

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?refer...

Autor: Cyblord -. (cyblord)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: AndreasR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Danish B. (danishbelal)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :( .

Autor: AndreasR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Deren Datenblatt ist allerdings NDA :( .

smarthomatic ist open source.

Autor: Reinhard M. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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"

Autor: Danish B. (danishbelal)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Danish B. (danishbelal)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Danish B. (danishbelal)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Draco (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dennoch mit PIC? Wie gesagt, die AVR XMegas haben bereits ein Hardware 
EAS.

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.