mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Bluetooth Verbindung absichern?


Autor: Florian Rist (Firma: TU Wien) (frist)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich denke gerade folgendes Problem nach:

Ich hab ein Abrechnungsgerät und eine Maschine und ich brauche eine 
Verbindung zwischen den beiden. Es soll nämlich jede Minute, die die 
Maschine läuft etwas vom Guthaben im Abrechnungsgerät verbraucht werden.

Ich würde die Verbindung gern über RS232-Bluetooth Module realisieren, 
aber im Prinzip hab man das gleiche Problem mit einem Kabel auch.

Ich suche jetzt einen Lösungsansatz um es wenigsten halbwegs schwierig 
zu machen, den Übertragungsweg so zu manipulieren, dass kein Geld mehr 
abgebucht wird, die Maschine aber weiter läuft.

Egal, wie das Kommunikationsprotokoll zwischen den beiden Geräten 
aussieht, bei Bluetooth hätte ich schon mal die Verschlüsselung, die 
eben zu Bluetooth gehört. Nun scheint mir die ber inzwischen sehr leicht 
zu überwinden zu sein und ich würde gern noch etwas mehr tun, aber was?

Irgendwelche Ideen für eine einfache Verschlüsselung, die die immer 
gleichen Nachrichten ("Mschine läuft, jetzt Geld Abbuchen", "Geld 
abgebucht, Maschine an für die nächsten fünf Minuten", etc.) wenigstens 
vor einem einfachen Angriff durch aufzeichnen und wieder abspielen 
sichert.

Grüße
Flo

Autor: Michael W. (michael87)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Florian,

Die Möglichkeit mit den Bluetooth-Modulen halte ich für sinnvoll, da es 
meiner Meinung nach schwerer fällt, physikalisch in die Verbindung 
einzugreifen.

Erklärung: Baust du eine RS232-Verbindung über Kabel auf, könnte man ja 
das Kabel trennen und die Kommunikation nachbilden.
Bei Bluetooth-Modulen (ich denke jetzt an BTM222, da ich es bei denen 
weiß), kannst du schon über die Konfiguration bestimmen, welche zwei 
Geräte miteinander Kommunizieren können - und dies kann auch unsichtbar 
passieren. So sieht man mit einem Sniffer schon einmal nicht die Geräte 
und kann diese nicht simulieren.

Arbeitest du nun z.B. über Keys, die ausgetauscht werden und die für 
Berechnungen dienen, kannst du noch einmal etwas mehr Sicherheit 
gewinnen.

Ganz sicher wirst du eine Verbindung eigentlich nie bekommen, mit 
entsprechender Analyse der Verbindung kann man diese eigentlich immer 
umgehen.

Vllt hilft mein Ansatz ja

MFG

Autor: Florian Rist (Firma: TU Wien) (frist)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Michael,
danke für Deine Antwort.

Genau, ich dachte auch, dass Bluetooth schon mal nicht so leicht 
anzuzapfen ist wie eine einfache Leitung (und ich spare mir das verlegen 
der Leitung).

Ich würde jetzt eigentlich nur noch gern vermeiden, dass man einfach ein 
Stück der Kommunikation mitschneidet und einfach wieder abspielt. 
Software für den PC, die die das Bluetooth Paring überwindet scheint es 
zu geben, das geht wohl in ein paar Sekunden.

Drum dachte ich mir es wäre gut, die ja eigentlich immer gleichen 
Nachrichten etwa zusammen mit einem (zufälligen oder jedenfalls immer 
anderen) Seed zu hashen und den Hash zu übertragen, nur wie komm ich 
jetzt wieder an die Nachricht. Ich könnte die Seeds in beiden Geräten 
synchron pseudozufällig erzeugen, das scheint mit aber etwas riskant - 
wenn das einmal aus dem Tritt kommt ist's vorbei. Alternativ müsste ich 
das Seed mit übertragen. Hmm... Da könnte ich das Seed ja eigentlich 
einfach mit eine Key XOR Verschlösseln und das zusammen mit dem Hash 
übertragen. Dann hätte ich immer verschiedene Nachrichten und bräuchte 
auf beiden Seiten nur kurze private Schlüssel Speichen.

Das klingt eigentlich schon ganz gut. Was mein ihr. Hat jemand einen 
Vorschlag zur Hashfunktion, die sich gut auf einem der kleineren ATMegas 
implementieren lässt.

Grüße
Fl

Autor: Jasch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Florian Rist schrieb:
> Ich würde jetzt eigentlich nur noch gern vermeiden, dass man einfach ein
> Stück der Kommunikation mitschneidet und einfach wieder abspielt.

Dafür gibt es kryptographische Standardverfahren, mit Nonces, 
Zeitstempeln und einem geteiltem Geheimnis (Passwort), musst Du mal 
nachlesen.

> Drum dachte ich mir es wäre gut, die ja eigentlich immer gleichen
> Nachrichten etwa zusammen mit einem (zufälligen oder jedenfalls immer
> anderen) Seed zu hashen und den Hash zu übertragen, nur wie komm ich

Das ist das Prinzip, nur einen Zeitstempel und ein Geheimnis brauchst Du 
auch noch weil Du prüfen musst dass die Message "frisch" ist und der 
Angreifer ja nicht alles kennen darf was in die Message eingeht. Seed 
(Nonce) und Zeitstempel musst Du ja im Klartext mitübertragen, die 
Kommandocodes (Im Extremfall ja nur "Abbuchen") sind zu kurz um nicht 
einfach ausprobiert zu werden.

> jetzt wieder an die Nachricht. Ich könnte die Seeds in beiden Geräten
> synchron pseudozufällig erzeugen, das scheint mit aber etwas riskant -
> wenn das einmal aus dem Tritt kommt ist's vorbei. Alternativ müsste ich

Genau. Wobei es Lösungen gibt die genau so arbeiten, diese RSA Inc. 
Schlüsselringdinger z.B. meines Wissens, allerdings mit komplizierteren 
Verfahren um das Problem der De-Synchronisation zu umgehen.

> das Seed mit übertragen. Hmm... Da könnte ich das Seed ja eigentlich
> einfach mit eine Key XOR Verschlösseln und das zusammen mit dem Hash
> übertragen. Dann hätte ich immer verschiedene Nachrichten und bräuchte
> auf beiden Seiten nur kurze private Schlüssel Speichen.

Hehehe, um Gottes Willen, nein.

Der Angreifer faengt einfach zwei Nachrichten ab, verknüpft die per XOR 
mit dem Key verschlüsselten Seeds miteinander wieder per XOR und Bingo! 
Er hat Deinen Key. Probier es einfach mal aus ;-)

> Das klingt eigentlich schon ganz gut. Was mein ihr. Hat jemand einen
> Vorschlag zur Hashfunktion, die sich gut auf einem der kleineren ATMegas
> implementieren lässt.

Tja, das wird wohl das Problem sein. Um es einigermassen sicher zu 
bekommen brauchst Du: einen kryptographischen Zufallszahlengenerator 
(für die Nonces), z.B. mit AES aufgebaut, die aktuelle Zeit und eine 
kryptographische Hashfunktion (SHA-1, SHA-256, sowas).

Das alles auf einem kleinen µC unterzubringen dürfte eine 
Herausforderung sein, wie der an die Zeit kommen soll natürlich auch.

Autor: Jasch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jasch schrieb:
> Der Angreifer faengt einfach zwei Nachrichten ab, verknüpft die per XOR
> mit dem Key verschlüsselten Seeds miteinander wieder per XOR und Bingo!
> Er hat Deinen Key.

Uhhh, das ist natürlich Bullshit (dazu müssten die Seeds identisch sein, 
was sie nach einiger Zeit aber mal sind), der Angriff funktioniert etwas 
anders. Was der Angreifer hier rausbekommt ist Seed1 XOR Seed2 - was 
vermutlich auch schon schlechte Nachrichten sind.

Lies mal über One Time Pad (OTP) nach und die Angriffe dagegen.

Da Du ja scheinbar an der TU Wien bist: da sollte es Leute geben die 
sich mit Kryptokram befassen, einfach mal raussuchen und kontaktieren, 
dazu ist eine Uni doch optimal.

Autor: Nosnibor (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zufall ist gar nicht nötig, sofern die Maschine einen Zähler hat, der 
nicht (z.B. durch Ausschalten) zurückgesetzt werden kann (ein 
Betriebsstundenzähler wäre geeignet). Die Maschine schreibt den 
Zählerstand in ihre Anfrage-Nachricht und akzeptiert eine Antwort nur, 
wenn sie den Zählerstand der letzten Anfrage enthält. Damit stellt die 
Maschine sicher, daß die Antwort vom Abrechnungsgerät aktuell ist, 
sofern sie bei jeder Anfrage einen anderen Zählerstand benutzt hat. Das 
kann man mit einem speziellen Zähler erreichen, der bei jeder Anfrage 
weiterzählt und im EEPROM gesichert wird, oder mit einem vielleicht 
sowieso schon vorhandenen Betriebsstundenzähler, oder mit aktuellem 
Datum+Uhrzeit aus einer vertrauenswürdigen Quelle (Funkuhr),... oder 
eben mit gutem Zufall.

Außerdem muß noch sichergestellt sein, daß die übertragenen Nachrichten 
authentisch sind, d.h. es ist ein keyed hash nötig. Maschine und 
Abrechnungsgerät brauchen also ein gemeinsames Geheimnis als Schlüssel 
für den Hash. Einen keyed hash kann man mittels HMAC aus jedem 
gewöhnlichen Hash basteln. Wenn die Nachrichten alle die gleiche Länge 
haben, tut's aber auch der CBC-MAC; für den braucht man nur einen 
Blockverschlüsselungsalgorithmus (AES, XTEA,...) als Grundlage, und das 
dürfte auf einem kleinen Prozessor weniger Aufwand sein als ein guter 
Hash.

Und wenn ich die Datenmenge einer Nachricht mit der Blockgröße moderner 
Verschlüsselungsalgorithmen vergleiche... da reduziert sich der CBC-MAC 
auf einfaches Verschlüsseln.     :)

Autor: Florian Rist (Firma: TU Wien) (frist)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
danke für eure Beträge. Ich muss jetzt ertmal noch etwas lesen, danke 
für die guten Stichworte. Ich schau mal, ob die


Eine Sache noch zu der Idee eine (pseudo) Zufallszahl und einen Hash der 
Nachricht und dieser Zahl zu übertragen:

Mal angekommen ich gestalte die ganze Kommunikation bidirektional, immer 
aus Frage und Antwort wobei immer eine Zufallszahl eine fortlaufende 
Nachrichtennummer im Klartext übertragen wird und dann noch ein Hash, 
der über diese beiden Zahlen und eine geheime Nachricht gebildet wird.

Die geheime Nachricht kennen nur Sender und Empfänger, ich brauch ja nur 
nur ein paar verschiedene dieser Nachrichten.

Auf Empfänger Seite entschlüssele ich die empfangenen Daten in dem ich 
alle Hashs über die beiden Klartextteile und meine geheimen Nachrichten 
bilde und mit den empfangenen Daten vergleiche.

Da sollte dann (wenn der Hash echt eine Einweg-Funktion ist) für einen 
Angreifer unmöglich sein solche Fragen oder Antworten zu konstruieren.

Das wäre insofern praktisch, als ich nur z.B.  SHA-1 bräuchte und sonst 
nix. (Eigentlich bräuchte ich nicht mal die Zufallszahlen.)

Ich glaube ich könnte die die ungewöhnliche Tatsache ausnutzen, dass ich 
nur zwei drei verschiedene Nachrichten brauche.


Naja, jetzt versuch ich aber erst mal was zum Thema zu lesen und nicht 
was eigenes zu erfinden und schau mir mal die AVR-Crypto-Lib 
(http://www.das-labor.org/wiki/AVR-Crypto-Lib) an.

Grüße
Flo

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.