|
|
|
|
|
Autor |
Nachricht |
Andreas Müller
Anmeldungsdatum: 28.02.2005 Beiträge: 2493 Wohnort: Altendorf
|
Verfasst am: Mi 21 Dez 2005, 14:48 Titel: |
|
|
Juerg hat folgendes geschrieben: | wozu Verschlüsselung? Eine Zustandsmaschine die in beiden Geräten läuft tut den gleichen Zweck und ist nicht zu knacken.
Prinzip muss einfach sein, dass das eigentliche Signal eine Sequenz ist, welche aus mehreren Kommando -> Quittierung Schritten besteht und bei jedem Fehler sofort auf Anfang zurückfällt. |
Also dann spiel' ich jetzt mal den Advocatus Diaboli. Mit der Zustandsmaschine schuetzt Du Dich nicht vor Replay. Warum soll ich nicht einfach die gleichen Kommandi nochmals schicken, die ich beim letzten Start mit dem Scanner gesehen habe? Dazu muss die Zustandsmaschine einen nicht wiederholbaren Teil haben, das erreicht man mit der Seriennummer. Wenn diese aber offen uebermittelt wird, kann ich die Seriennummer aendern, d.h. ich kann Dir einen Start ausloesen in dem Moment, da Du von der Rakete zum Startpult zurueckmarschieren willst. Ob es nun genau eine Seriennummer ist oder irgend etwas anderes, was jedesmal anders ist, spielt keine Rolle. Dagegen gibt es zwei Methoden: die Uebermittlung schuetzen, oder Authentisierung. Damit das moeglichst zustandslos funktioniert, muesste man wieder jede Uebermittlung authentisieren, d.h. man braucht zum Beispiel ein Zero Knowledge Protokoll, damit die Authentisierung nicht einfach abgehoert werden kann. Oder man verschluesselt einfach, dann kann nur jemand, der den Schluessel kennt, einen Befehl formulieren, und weil die Seriennummer darin verschluesselt und mit Hash gesichert ist, kann er auch nichts daran aendern.
Das Protokoll funktioniert auch one-way, d.h. man koennte ohne Rueckwaertskanal operieren, obwohl man dann die Continuity nicht mehr so genau kontrollieren kann. Zur Sicherheit muesste man hier jedoch alle Zustandsaenderungen lease-based machen, also zum Beispiel ARM ist gueltig fuer die naechsten 8 Sekunden, wenn bis dann kein FIRE eintrifft, passiert auch nichts. Das macht man heute auch bei Fileservern oder Datenbanken so, z.B. NFSv4 verwendet lease based locking.
Natuerlich ist Verschluesselung nichts anderes als eine State-Machine, nur mit mathematisch sehr komplexem internem Zustand, so dass ohne dessen Kenntnis (den Schluessel), nur falsche Zustaende produziert werden koennen.
Auch die Enigma ist eine Zustandsmaschine, und wie die Geschichte bewiesen hat, war sie sehr wohl zu knacken, und nicht ohne Einfluss auf den Kriegsverlauf.
Fuer das Projekt: es muss ja nicht AES und SHA1 sein, einfachere Algorithmen duerften auch genuegen, aber spendier' Dir auf jedenfall etwas mehr als einen Tiny, damit Du fuer ein sicheres Protokoll genuegend Flash/RAM/CPU hast. Oder verlege diese Intelligenz ausserhalb der eigentlichen Zuendbox, in den Sender/Empfaenger. |
|
Nach oben |
|
|
|
|
|
|
|
|
|
|
Autor |
Nachricht |
Juerg Site Admin
Anmeldungsdatum: 27.02.2005 Beiträge: 4545 Wohnort: Oberengstringen
|
Verfasst am: Mi 21 Dez 2005, 15:22 Titel: |
|
|
Nö, das funktioniert anders: Die Zustandmaschine beginnt an einem zufällig gewählten Zustand, übermittelt diesen an die Gegenstation, und von dort aus gehts dann nur noch weiter, wenn man dieselbe Maschine hat.
Für "Replay" muss man da schon sehr lange zugehört haben und auch das Gehörte mit Logik verknüpfen.
Klar kann der NSA das wahrscheinlich knacken, aber dann wäre es doch noch wesentlich einfacher die Leitungen der Kabelzuleitung anzuzapfen und so den Start auszulösen.
Irgendwo hat's ja auch Grenzen was man abfangen können muss.
Dass Befehle ein "Verfalldatum" haben müssen ist sowieso eine gute Sache: Zum einen sinkt die Wahrscheinlichkeit von Fehlern, andererseits gibt es einen definierten Rückfallpunkt wenn sich irgend etwas "verheddert".
Gruss
Jürg _________________ http://www.SpacetecRocketry.com |
|
Nach oben |
|
|
|
|
|
|
|
|
|
|
Autor |
Nachricht |
Andreas Müller
Anmeldungsdatum: 28.02.2005 Beiträge: 2493 Wohnort: Altendorf
|
Verfasst am: Do 22 Dez 2005, 2:03 Titel: |
|
|
Juerg hat folgendes geschrieben: | wenn man dieselbe Maschine hat |
Voilà , hier ist die Schwäche. Wenn Du der einzige bist, der die Zustandsmaschine besitzt, ist das OK. Wenn Du die Software der Zustandsmaschine hier postest (zum Beispiel als GPL Software, vielleicht darf ich ja mithacken), oder aus dem Ding ein Produkt machst, dann stimmt die Annahme nicht mehr, die Zustandsmaschine ist nicht mehr einzigartig, jeder kann eine haben. Das Problem kennt man von Garagentoröffnern, Autoschlüsseln und gewissen drahtlosen Mäusen/Tastaturen, mit denen man Nachbars PC gleich mitbedienen kann. Du brauchst eine Möglichkeit, Paare von Zündbox/Fernsteuerbox individuell zu machen. Dann hast Du Code, der aus einer Zufallszahl (der zufällig gewählte initiale Zustand) und dem individuellen Kennzeichen einen Befehl macht. Wenn du jetzt dem individuellen Kennzeichen "Schlüssel" sagst und nochmals über "aus ... ... macht" nachdenkst, dann erkennst Du ein Verschlüsselungsverfahren. Ziemlich genau das, was ich ein paar Posts früher beschrieben habe.
Ach ja, der zufällig gewählte Anfangszustand ist auch nicht so einfach, vor allem bei einem Microcontroller, der sehr wenige Entropiequellen hat. Da ist alles deterministisch, wenn man nicht vorsorgt. Wie stellt man sicher, dass zwei Fernsteuerboxen beim Einschalten mit Wahrscheinlichkeit > 0 verschiedene Zufallszahlen wählen? Automatisch geht das kaum (ausser man baut Hardware dafür ein), vielleicht kann man die Zeit zwischen Benutzeraktionen als Entropiequelle benutzen. |
|
Nach oben |
|
|
|
|
|
|
|
|
|
|
Autor |
Nachricht |
Juerg Site Admin
Anmeldungsdatum: 27.02.2005 Beiträge: 4545 Wohnort: Oberengstringen
|
Verfasst am: Do 22 Dez 2005, 12:10 Titel: |
|
|
Andreas Müller hat folgendes geschrieben: | Voilà , hier ist die Schwäche. Wenn Du der einzige bist, der die Zustandsmaschine besitzt, ist das OK. |
Davon gehe ich mal aus.
Zitat: | Wenn du jetzt dem individuellen Kennzeichen "Schlüssel" sagst und nochmals über "aus ... ... macht" nachdenkst, dann erkennst Du ein Verschlüsselungsverfahren. Ziemlich genau das, was ich ein paar Posts früher beschrieben habe. |
Mit einem wesentlichen Unterschied: Ich brauche keine Online-Rechenleistung mehr, die "Verschlüsselung" ist beim Programmieren passiert. Ich kann ja auch eine Zustandsmaschine wählen, welche durch externe Parameter verändert wird, zb. durch ein xx-bit Wort was auf einem Dip-Switch eingestellt werden kann.
Gruss
Jürg _________________ http://www.SpacetecRocketry.com |
|
Nach oben |
|
|
|
|
|
|
|
|
|
|
Autor |
Nachricht |
Andreas Müller
Anmeldungsdatum: 28.02.2005 Beiträge: 2493 Wohnort: Altendorf
|
Verfasst am: Do 22 Dez 2005, 12:57 Titel: |
|
|
Juerg hat folgendes geschrieben: | Davon gehe ich mal aus. |
Schade. Warum nicht Open Source (klicken), dann hätten mehr etwas davon, und tatkräftige Unterstützung könntest Du auch haben (von mir zum Beispiel).
Zitat: | Mit einem wesentlichen Unterschied: Ich brauche keine Online-Rechenleistung mehr, die "Verschlüsselung" ist beim Programmieren passiert. |
Naja, zeig mir mal die Zustandsmaschine, die ohne Rechenleistung funktioniert. Der Herr Turing hätte da wohl auch noch so seine Meinung dazu. Eine Zustandsmaschine macht ja aus Bits andere Bits, und das nennt man üblicherweise "Berechnung", und macht es mit der CPU. Das Argument, dass das schon bei der Programmierung festgelegt worden sei, zieht natürlich nicht: erst wenn das Programm ausgeführt wird, wird die Zustandsmaschine auch realisiert. Führ' mal ein Programm ohne CPU aus...
Zitat: | Ich kann ja auch eine Zustandsmaschine wählen, welche durch externe Parameter verändert wird, zb. durch ein xx-bit Wort was auf einem Dip-Switch eingestellt werden kann. |
So etwas nennt man einen Verschlüsselungsalgorithmus, und das xx-bit Wort heisst dann Schlüssel. Statt des DIP-Switches könnte man den Code ja auch ins EEPROM brennen, damit spart man noch Platinenfläche und Bauteile.
Sag ich doch die ganze Zeit: Zustände + Randomisierung Verschlüsseln und übermitteln. |
|
Nach oben |
|
|
|
|
|
|
|
|
|
|
Autor |
Nachricht |
Andreas Müller
Anmeldungsdatum: 28.02.2005 Beiträge: 2493 Wohnort: Altendorf
|
Verfasst am: Do 22 Dez 2005, 13:47 Titel: |
|
|
Das würde der Herr Turing ganz konkret sagen: Die Zustandsmaschine kann durch eine Turing Maschine simuliert werden, da eine Turing Maschine jede andere Maschine simulieren kann. Da moderne Prozessoren in einem beschränkten Sinne Turing vollständig sind, sind sie äquivalent zu einer Turing Maschine, d.h. moderne Prozessoren können jede Zustandsmaschine simulieren, die Du dir ausdenken kannst. Kurz: jede Zustandsmaschine kann von einem Prozessor berechnet werden. |
|
Nach oben |
|
|
|
|
|
|
|
|
|
|
Autor |
Nachricht |
Juerg Site Admin
Anmeldungsdatum: 27.02.2005 Beiträge: 4545 Wohnort: Oberengstringen
|
Verfasst am: Do 22 Dez 2005, 14:32 Titel: |
|
|
Andreas Müller hat folgendes geschrieben: |
Naja, zeig mir mal die Zustandsmaschine, die ohne Rechenleistung funktioniert. |
Naja, etwas unscharf formuliert. Man muss da immer extrem aufpassen, wenn man mit Mathematikern diskutiert
Korrektur: Man braucht weniger Rechenleistung, weil man nicht die ganze Kommunikation verschlüsseln sondern nur den nächsten Zustand einmal errechnen muss. _________________ http://www.SpacetecRocketry.com |
|
Nach oben |
|
|
|
|
|
|
|
|
|
|
Autor |
Nachricht |
Juerg Site Admin
Anmeldungsdatum: 27.02.2005 Beiträge: 4545 Wohnort: Oberengstringen
|
Verfasst am: Do 22 Dez 2005, 14:35 Titel: |
|
|
Andreas Müller hat folgendes geschrieben: | Statt des DIP-Switches könnte man den Code ja auch ins EEPROM brennen, damit spart man noch Platinenfläche und Bauteile. |
Ja, aber dann kann man den Schlüssel nicht mehr ohne weiteres anpassen! _________________ http://www.SpacetecRocketry.com |
|
Nach oben |
|
|
|
|
|
|
|
|
|
|
Autor |
Nachricht |
Andreas Müller
Anmeldungsdatum: 28.02.2005 Beiträge: 2493 Wohnort: Altendorf
|
Verfasst am: Do 22 Dez 2005, 15:15 Titel: |
|
|
Juerg hat folgendes geschrieben: | Ja, aber dann kann man den Schlüssel nicht mehr ohne weiteres anpassen! |
Was macht genau so ein Bluetooth Device wenn es mit dem Computer gepaart wird? Genau: einen Schlüssel generieren, der zwischen den zwei geheim ist. D.h. man kann jederzeit die Schlüssel wechseln, selbst ohne DIP-Switch. Zum Beispiel so: in den ersten 5 Sekunden nach dem Einschalten wird nach neuen Partnern gesucht, sonst wird der alte verwendet. Braucht nicht einmal ein Bedienungselement. Nur auf 5 Sekunden genau gleichzeitig einschalten. |
|
Nach oben |
|
|
|
|
|
|
|
|
|
|
Autor |
Nachricht |
Andreas Müller
Anmeldungsdatum: 28.02.2005 Beiträge: 2493 Wohnort: Altendorf
|
Verfasst am: Do 22 Dez 2005, 15:24 Titel: |
|
|
Juerg hat folgendes geschrieben: | Korrektur: Man braucht weniger Rechenleistung, weil man nicht die ganze Kommunikation verschlüsseln sondern nur den nächsten Zustand einmal errechnen muss. |
Aber man muss bei jedem Start eine neue Sequenz berechnen (sonst hätte man wieder das Problem mit dem primitiven Replay). D.h. man braucht genügend Variation, der übermittelte Datenblock braucht eine gewisse Länge. D.h. aus dem zufälligen Zustand (z.B. 8 bit) muss man einen Datenblock machen, der etwa 32bit lang ist (4Bytes). Die übermittelt man dann, nicht mehr. Man nennt das einen Blockverschlüssler mit Blocklänge 32bit, und hat die ganze Kommunikation verschlüsselt. Was Du machen willst, ist Verschlüsselung, also warum nicht Code/Protokolle dafür verwenden, die getestet sind und deren Schwächen man beziffern kann? |
|
Nach oben |
|
|
|
|
|
|
|
|
|
|
Autor |
Nachricht |
Andreas Müller
Anmeldungsdatum: 28.02.2005 Beiträge: 2493 Wohnort: Altendorf
|
Verfasst am: Do 22 Dez 2005, 15:46 Titel: |
|
|
Die benötigte Rechenleistung für eine DES Implementation in einem AVR ist übrigens recht gering. Mit weniger als 2kB Code bekommt man einen Durchsatz von 32Bytes/s/MHz. D.h. mit einem 8MHz Prozessor hast 256 Bytes pro Sekunde. Da kannst Du schon ganz schön viel verschlüsseln.
Quelle: http://www.atmel.com/dyn/resources/prod_documents/doc2541.pdf, dort findet man auch den meiner Meinung nach sehr sauber geschriebenen Code dazu (des.c im zugehörigen Source Code Archiv, der GCC macht daraus 1688 Bytes Maschinencode).
Zuletzt bearbeitet von Andreas Müller am Do 22 Dez 2005, 16:30, insgesamt einmal bearbeitet |
|
Nach oben |
|
|
|
|
|
|
|
|
|
|
Autor |
Nachricht |
Reinhard
Anmeldungsdatum: 18.04.2005 Beiträge: 346
|
Verfasst am: Do 22 Dez 2005, 16:06 Titel: |
|
|
Hi,
also wenns um die Rechenleistung geht, die neuen ARMs von Atmel gibt es auch mit einer Kryptoengine für AES und 3DES . Aber im Ernst, wie sieht denn das Bedrohungsszenario überhaupt aus. Der Vergleich mit den sabotierten RC-Fliegern hinkt ein wenig, weil dort ja Standartkomponenten verwendet werden, und das KnowHow das zur gezielten Störung notwendig ist gegen Null geht (welchen Quarz brauche ich). Hier müsste ein Angreifer zumindest wissen welche Transceiver verwendet werden und wie man den verwendet. Wie viele potentielle Angreifer gibt es denn überhaupt (KnowHow+Motivation)? Die Szene ist ja auch viel kleiner als bei den Flächenfliegern.
IMHO reicht da irgendeine kleine "Security by Obscurity"-Lösung aus (auaaua, bitte nicht schlagen), die auf geringe Rechenleistung hin optimiert ist. Also alles was weniger offensichtlich als ein XOR mit dem Schlüssel ist. Andererseits ist es vermutlich kein großer Aufwand eine freie Implementierung für ein anerkanntes Verfahren zu finden.
Ein Zufallsgenerator mit einem µC ist ganz einfach zu realisieren. Man nehme einen möglichst einfachen analogen Oszillator (z.B. R+C+Inverter; mit der Frequenz f1). Dessen Spannung (im analogen Teil) wird mit dem ADC gesampelt (Samplingfrequenz f2). Wenn gilt: f1>>f2, der Oszillator unabhängig vom µC schwingt und man nur das LSB des ADC-Wertes verwendet, kommt man Dank Temperaturdrift, Bauteiltoleranzen und dem Rauschen einem idealen Zufallsgenerator schon sehr nahe, bei einem minimalen HW-Aufwand.
Meine Vorgehensweise wäre folgende.
1. Glauben alle Menschen wären gut, und ev. Platz für einen HW-Zufallsgenerator lassen.
2a) (unwahrscheinliche) negative Erfahrungen machen, oder
2b) Langweile haben (schon wahrscheinlicher)
3) dann ein Update durchführen
Gruß
Reinhard |
|
Nach oben |
|
|
|
|
|
|
|
|
|
|
Autor |
Nachricht |
Andreas Müller
Anmeldungsdatum: 28.02.2005 Beiträge: 2493 Wohnort: Altendorf
|
Verfasst am: Do 22 Dez 2005, 17:38 Titel: |
|
|
Reinhard hat folgendes geschrieben: | Aber im Ernst, wie sieht denn das Bedrohungsszenario überhaupt aus. |
Selbstverständlich können wir darüber wieder diskutieren. Wir sind uns aber einig, dass man schon etwas machen sollte. Also warum nicht die beste Lösung machen, die mit dem unvermeidlichen Minimalaufwand zu realisieren ist? Warum XOR verwenden, wenn DES genau gleich einfach zu haben ist? Warum ein schwaches Protokoll verwenden, wenn das starke bereits beschrieben ist, und genau gleich viel zu tun gibt (oder sogar weniger, weil man Code wiederverwenden kann)? Warum ein schlechte Lösung, wenn die bessere nicht teurer ist?
Zitat: | Ein Zufallsgenerator mit einem µC ist ganz einfach zu realisieren. Man nehme einen möglichst einfachen analogen Oszillator (z.B. R+C+Inverter; mit der Frequenz f1). Dessen Spannung (im analogen Teil) wird mit dem ADC gesampelt (Samplingfrequenz f2). Wenn gilt: f1>>f2, der Oszillator unabhängig vom µC schwingt und man nur das LSB des ADC-Wertes verwendet, kommt man Dank Temperaturdrift, Bauteiltoleranzen und dem Rauschen einem idealen Zufallsgenerator schon sehr nahe, bei einem minimalen HW-Aufwand. |
Sag ich doch: man muss etwas vorsehen, ein Microcontroller hat von Haus aus keine Entropie. Man könnte aber wie schon erwähnt auch den Benutzer dafür vorsehen und zum Beispiel mit einem Timer on Chip die Zeit bis zur ersten Benutzerinteraktion messen. Dann braucht man gar keine Hardware. Wir benötigen ja nicht dauernd Entropie in grosser Menge, sondern nur am Anfang etwa 32bit (das gibt dann über 4*10^9 Anfangszustände). Übrigens tragen die Bauteiletoleranzen nichts zur Entropie bei.
Zitat: | 3) dann ein Update durchführen |
Warum nicht gleich von Anfang an versuchen, es richtig zu machen? Denn
1. es kostet nichts: keine zusätzliche Hardware (wenn man die Entropie vom Benutzer nimmt)
2. es verlangt keinen zusätzlichen Programmieraufwand, eher sogar weniger, weil man wesentliche Teile der Zustandsmaschine, den Cryptocode, bereits hat
3. man erhält garantierte Eigenschaften |
|
Nach oben |
|
|
|
|
|
|
|
|
|
|
Autor |
Nachricht |
Juerg Site Admin
Anmeldungsdatum: 27.02.2005 Beiträge: 4545 Wohnort: Oberengstringen
|
Verfasst am: Do 22 Dez 2005, 18:03 Titel: |
|
|
Andreas Müller hat folgendes geschrieben: | Aber man muss bei jedem Start eine neue Sequenz berechnen (sonst hätte man wieder das Problem mit dem primitiven Replay). |
Nö, Du kannst auch auf beiden Seiten den letzten Zustand im EEProm speichern. _________________ http://www.SpacetecRocketry.com |
|
Nach oben |
|
|
|
|
|
|
|
|
|
|
Autor |
Nachricht |
Juerg Site Admin
Anmeldungsdatum: 27.02.2005 Beiträge: 4545 Wohnort: Oberengstringen
|
Verfasst am: Do 22 Dez 2005, 18:14 Titel: |
|
|
Andreas Müller hat folgendes geschrieben: | Warum nicht gleich von Anfang an versuchen, es richtig zu machen? |
Da bin ich Dir einig, aber wenn ich alles umsetzen wollte, was hier beschrieben worden ist, müsste ich froh sein auf das Members-Only ALRS hin fertig zu sein!
Ein einfaches, gegen Replay robustes Protokoll ist z.B. auch:
Sender: "Entsichern"
Pad: "Entsichert, timestamp" (Zeit hat beim Einschalten zu laufen begonnen)
Sender: "Fire, timestamp+x" (innerhalb von 20 Sek)
Pad: -> Zündung
Beim Replay würde der Zeitstempel nicht stimmen.
Sowas auszutricksen setzt dann schon sehr viel Wissen, Equipment und kriminelle Energie voraus.
Aber natürlich kann man den Kanal auch verschlüsseln.
Was damit bleibt ist die Anforderung nach einem relativ langen Zünd-Kommando um das Risiko von Uebertragungsfehlern auszumerzen. Diese wird aber wohl bereits mit dem ganzen Aufwand für die Verschlüsselung erschlagen.
Gruss
Jürg _________________ http://www.SpacetecRocketry.com |
|
Nach oben |
|
|
|
|
|
|
|
|
|
|
|
Du kannst keine Beiträge in dieses Forum schreiben. Du kannst auf Beiträge in diesem Forum nicht antworten. Du kannst deine Beiträge in diesem Forum nicht bearbeiten. Du kannst deine Beiträge in diesem Forum nicht löschen. Du kannst an Umfragen in diesem Forum nicht mitmachen. Du kannst Dateien in diesem Forum nicht posten Du kannst Dateien in diesem Forum herunterladen
|
|
|
|
|
|
|
|