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
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
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
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.
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.
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. :)
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.