Und noch eine Frage hinterher. Wie bekomme ich beim Start eines AVR-Controllers eine wirklich echte Zufallszahl, die nicht irgendwie berechnet und daher bei jedem Start die gleiche ist? Kennt jemand da eine einfache Möglichkeit? Ansonsten mache ich's mit dem ADC, rotiere/addiere eine große Anzahl Messungen des Batteriespannungs-messenden Kanals und hoffe auf ein paar Bitwackler... wobei mir die aber eigentlich zu selten auftreten. Die Entstörung ist leider bereits auf Lochraster ziemlich gut geworden. :-/ Danke...
Wie wärs mit der Messung eines offenen(floatenden) AD-Kanals?
Das hatte ich auch überlegt, geht leider nicht (mehr), alle ADC-Eingänge sind belegt. Daher der meiner Meinung nach am stärksten wackelnde Eingang. Es liegen auch keine Eingänge zuverlässig auf annähernd gleichem Spannungsbereich, ansonsten hätte ich welche mit hoher Verstärkung gemessen, daß die unteren Bits schön flattern. Aber ich glaube alles würde nur den Verstärker übersteuern und dann klebe ich an einem der Endwerte fest.
Hab an meiner Appl. eine RTC, nutze einfach die aktuelle Zeit als Startwert. mfg Achim
Daniel schrieb: > Wie wärs mit der Messung eines offenen(floatenden) AD-Kanals? Dieser wird sich, bedingt durch Leckstöme, auf GND bzw. VCC aufladen und dann konstant 0x0000 oder 0xFFFF liefern. Es reicht ein hochohmiger Flußmittelrest oder fettiger Fingerabdruck an der richtigen Stelle.
Ben B. schrieb: > Und noch eine Frage hinterher. Wie bekomme ich beim Start eines > AVR-Controllers eine wirklich echte Zufallszahl, die nicht irgendwie > berechnet und daher bei jedem Start die gleiche ist? > > Kennt jemand da eine einfache Möglichkeit? Indem man den Zufallsgenerator immer laufen läßt, z.B. in einem 100Hz Interrupt. Die Anwendung/State machine starte dann zufällig in einem beliebigen Augenblick, damit ist der Zufallsgeneratorstartpunt zufällig.
Falk B. schrieb: > Indem man den Zufallsgenerator immer laufen läßt, z.B. in einem 100Hz > Interrupt. Die Anwendung/State machine starte dann zufällig in einem > beliebigen Augenblick, damit ist der Zufallsgeneratorstartpunt zufällig. Da braucht das Programm aber ein nicht deterministisches Element, wie z.B. eine Benutzereingabe. Sonst bringt das gar nichts.
Ein echter Zufallsgenerator wäre ein Rauschen, z.B. das Rauschen einer Diode verstärken und auf der ADC geben. Siehe https://de.wikipedia.org/wiki/Rauschgenerator Eine fertige, erprobte Schaltung habe ich aber nicht :-(
Yep, wie schon geschrieben, geht nicht weil ich keinen ADC-Eingang für ein zusätzliches Rauschsignal mehr frei habe. Andere Idee: Wie kann man am einfachsten einen digitalen Pin flattern lassen, bzw. wie bekommt man ein möglichst chaotisches Signal an einem digitalen Pin zustande? Irgendein Kippschwinger mit ein paar kHz? Hab was: Das geht sogar ganz einfach mit einem RC-Glied an einem Pin. Ich kann mit dem Pin die Zeit messen bis der Pin auf high kippt und kann den Kondensator über den Pin entladen. In der Zeit wo der Kondensator aufgeladen wird kann ich intern mit hoher Frequenz (der wird mit einigen Mhz zählen) einen 8-Bit Zähler laufen lassen. Den Zyklus ein paar hundert Mal durchlaufen lassen, die Ergebnisse auf 128 Bit addieren oder sonstewie durchrotieren... Das sollte doch zufällig genug werden, oder?
Cyblord -. schrieb: > Da braucht das Programm aber ein nicht deterministisches Element, wie > z.B. eine Benutzereingabe. Sonst bringt das gar nichts. Man könnte den dafür zuständigen Timer mit einer vom Systemtakt unabhängigen Taktquelle versorgen, indem man den Watchdog Timer dafür verwendet.
Thomas E. schrieb: > Man könnte den dafür zuständigen Timer mit einer vom Systemtakt > unabhängigen Taktquelle versorgen, indem man den Watchdog Timer dafür > verwendet. Und in wie fern ergibt das irgendwie Zufall?
Schau dir das letzte Bit von dem ADC Eingang an, welcher am stärksten rauscht. Den sampelst du 8 mal und schiebst das letzte Bit des ADC Wertes immer eine Stelle weiter in deine Zufallszahl. Somit hast du eine 8 Bit Zufallszahl.
Cyblord -. schrieb: > Und in wie fern ergibt das irgendwie Zufall? Gar nicht, denn die Jungs kennen den Unterschied zwischen Toleranz (der Frequenz) und (gleichverteiltem) Zufall nicht. Denn selbst wenn die Frequenz des Watchdogs eine mehr oder minder große Streuung hat, so ist sie für einen IC relativ konstant, wenn Versorgungsspannung und Temperatur konstant bleiben.
Chris K. schrieb: > Schau dir das letzte Bit von dem ADC Eingang an, welcher am stärksten > rauscht. Den sampelst du 8 mal und schiebst das letzte Bit des ADC > Wertes immer eine Stelle weiter in deine Zufallszahl. Somit hast du eine > 8 Bit Zufallszahl. Die alles andere als gleichverteilt ist . . .
Man sollte erstmal klären, wofür diese Zufallszahl denn wirklich gebraucht wird (schon klar, als Startwert des Pseudozufallsgenerators). Und ob externe Ereignisse (Eingangssignale, Nutzereingaben) existieren. Wenn ja, ist die Methode des "warmlaufen lassen" des Zufallsgenerators sehr einfach und wirksam.
Ben B. schrieb: > Das hatte ich auch überlegt, geht leider nicht (mehr), alle ADC-Eingänge > sind belegt. Benutzt du den internen Temperatursensor deines AVRs (beim Atmega328P an ADC Kanal 8)? Wenn nicht kannst du doch das Rauschen vom dem benutzen als "Zufallsgenerator" ;)
Ich überlege wie ich es am besten hinbekomme, den Kommunikationsweg vom Terminal zur Zentrale meiner AlarmSau zu verschlüsseln, um zu verhindern, daß jemand an dem Punkt mit einem Keylogger oder so mitlesen kann, was da eingegeben wird. Da Benutzereingaben nicht ohne diese Kommunikation möglich sind, muß das anlaufen bevor Benutzereingaben möglich sind. Was meint ihr zu der Idee oben mit dem RC-Glied am digitalen Eingang?
Kann man nicht jede 100000ste (oder so) Zufallszahl als Reinitialisierungswert für den nächsten Reset ins EEPROM speichern?
Ben B. schrieb: > Ich überlege wie ich es am besten hinbekomme, den Kommunikationsweg vom > Terminal zur Zentrale meiner AlarmSau zu verschlüsseln, um zu > verhindern, daß jemand an dem Punkt mit einem Keylogger oder so mitlesen > kann, was da eingegeben wird.# Mal abgesehen vom nicht wirklich vorhandenen Nutzwert und Notwendigkeit, macht man sowas, wenn es denn WIRKLICH was taugen soll, mit bestehenden, nachweislich sicheren Verfahren. Denn alles Selbstgestrickte, "hippe" und "mal schnell ADC-Rauschen messen" ist zu 99,9% Bastlerschrott. Denn die bestehenden Verfahren wurden sowohl von Kryptogaphieprofis als auch IT-Profis entworfen und getestet. > Was meint ihr zu der Idee oben mit dem RC-Glied am digitalen Eingang? Bastlerschrott.
Falk B. schrieb: > Chris K. schrieb: >> Schau dir das letzte Bit von dem ADC Eingang an, welcher am stärksten >> rauscht. Den sampelst du 8 mal und schiebst das letzte Bit des ADC >> Wertes immer eine Stelle weiter in deine Zufallszahl. Somit hast du eine >> 8 Bit Zufallszahl. > > Die alles andere als gleichverteilt ist . . . Das sollte nicht das Problem sein. Die Verteilung einer Zufallsvariable laesst sich transformieren. Problematisch wird eher sein ob das letzte Bit nicht doch einem gewissen Determinismus unterliegt. Haengt auch ganz von der Anwendung ab wie viel Zufall man wirklich braucht.
Na dann mach mich doch mal schlau, wie es die Profis machen. Bin gespannt, das zu hören.
Ben B. schrieb: > Ich überlege wie ich es am besten hinbekomme, den Kommunikationsweg vom > Terminal zur Zentrale meiner AlarmSau zu verschlüsseln, um zu > verhindern, daß jemand an dem Punkt mit einem Keylogger oder so mitlesen > kann, was da eingegeben wird. "Kommunikationsweg" und "Keylogger" sind 2 paar Schuhe. Keylogger sind dazu da, die Nutzereingaben aufzuzeichnen (waere also am Terminal installiert). Da hilft eine Verschluesselung des Kommunikationsweges (Terminal -> Zentrale), wie z.B. TLS, gar nichts. Also, was willst du? Willst du dich gegen Keylogger und/oder MitM schuetzen?
Ben B. schrieb: > Na dann mach mich doch mal schlau, wie es die Profis machen. Bin > gespannt, das zu hören. Schau doch mal wie man heute digitale Verbindungen im Netz verschlüsselt. Zertifikate, also PPK/Asymetrische Verschlüsselung z.B. RSA für die Authentifizierung des Gegenüber. Darüber dann Schlüsseltausch via Diffie-Hellman. Dann die eigentliche Datenverschlüsselung symmetrisch z.B. AES. Für einfachere Dinge, wie schlichte Befehle von einem Terminal könnten auch Challenge-Response Verfahren reichen. Aber auch hier mit asymmetrischen Verfahren.
:
Bearbeitet durch User
Ich meine einen Hardware-Keylogger, der die Kommunikation auf den USART-Leitungen aufzeichnet. Der würde die Eingaben so ziemlich im Klartext erhalten. Das Terminal ist auch nichts auf PC-Basis, sondern das ist eine zweite Platine, auf der mir ein ATMega88 ein Display und ein 4x3-Tasten-Feld RS232-tauglich machen. Da könnte man nur mechanisch was draufbasteln, wie bei den Skimming-Angriffen an Bankautomaten.
Falk B. schrieb: > Gar nicht, denn die Jungs kennen den Unterschied zwischen Toleranz (der > Frequenz) und (gleichverteiltem) Zufall nicht. Und die alten Säcke tun sich schwer mit dem verstehen (wollen).
Das Problem mit den beiden Thread von Ben ist einfach: Er ist sich überhaupt nicht im Klaren darüber welche Angriffsvektoren er absichern will. Da wird wild alles durcheinander gewirbelt und außer Aktionismus fällt da nichts bei raus. @Ben: Jetzt nimm dir mal die Zeit und überlege WAS du da genau schützen willst. Welche Szenarien schweben dir vor. Dann erst kann man über eine Lösung nachdenken.
Warum nicht 'einfach' eine CA erstellen, Eine private Zertifikats-Autorität, mit der du Asymetrische Schlüssel von deinem Master-Server signierst. Der Client kann dann mit deinem Master Zertifikat die unterzertifikate auf Ihre glaubwürdigkeit überprüfen. Ich glaube ein 512Bit Key (auch wenn mittlerweile gut knackbar) ist ausreichend, da zu aufwendig. Bzw. falls der Chip nicht die leistung hat, kann man eine Synchrone Verschlüsselung benutzen.
@Cyblord Da die Sache mit dem EEPROM abgehakt ist, geht es mir nur noch um die Verschlüsselung der Kommunikation vom Terminal zur Zentrale. Der Rückweg ist nicht wichtig, da werden nie sensible Daten übertragen. Was ich damit verhindern will? Die (rein hypotetische) Möglichkeit, daß jemand mit einem einfachen RS232-Logger die Tastenanschläge mitliest und/oder aufzeichnet.
Ben B. schrieb: > Was ich damit verhindern will? Die (rein hypotetische) Möglichkeit, daß > jemand mit einem einfachen RS232-Logger die Tastenanschläge mitliest > und/oder aufzeichnet. Dafür reicht eine einfache Verschlüsselung. Der Schlüssel kann dann fest auf beiden Seiten eincompiliert sein. Denn die Gefahr dass jemand dein Flash ausliest siehst du ja nicht als gegeben. Dir geht es ja nur um die Strecke. Wenn du auch ausschliest dass jemand in die Kommunikation reinfummelt, fallen auch Replay Attacken usw. flach.
Bei einem AD-Wandler ist doch meist das letzte Bit immer am flackern. Stabile AD-Werte habe ich noch nie gesehen. Einfach das letzte Bit nehmen, dann etwas warten, nehmen ... und damit 16 oder 32 Bit generieren.
PittyJ schrieb: > Bei einem AD-Wandler ist doch meist das letzte Bit immer am flackern. > Stabile AD-Werte habe ich noch nie gesehen. Ohje, wie schlecht sind denn deine ADC-Aufbauten? Also ganz ohne Anstrengung bekomm ich den internen ADC des AVRs bis aufs letzte Bit stabil hin, das ist nun bei 10 bit auch alles andere als schwer.
Natürlich kann man das "richtig" machen mit CA Handshake protokollen usw usf.. Aaber.. wieso kein vordefinierter key? Du generierst eine SemiPrime am heimischen Rechner (sagen wir 479bit weil es ne ätzende länge ist [auch prim]) Den private key dazu brennste ins EEprom der Sender und verschlüsselst damit die Datenpakete die gesedet werden. Pakete pumpst Du auf 512bit auf, damit der MitM die exakte Länge nicht erkennt; Empfänger bekommt den public key dazu, kürzt was ankommt auf 479 bit und entschlüsselt was übrig bleibt. Protokoll dazu kann man sich ja aussuchen.. wenn man den public key nun auch als private denkt (und geheim hält) sollte das ne Weile halten Bei bidirektionaler Übertragung kann der public ver- und der private entschlüsseln; ganz wie gewohnt. Absurde bitlängen sind deswegen schön, weil man sie so schön mit Unfug füllen kann zB dem Rauschen auf nem analogen Pin ;) Und wenn man sich jedes Jahr ne neue SemiPrime sucht ist man mE nach geschützt genug.
Anscheinend schickt das Terminal die Tastendrücke direkt an die Sau. Ob der hypothetische Keylogger jetzt im Klartext die PIN „1234“ mitliest, oder das als verschlüsselten Text „§/)(€93(…4@A“, ist Wurscht. Beides kann der Keylogger mitschneiden, und dann jederzeit an die Sau senden, worauf hin die dann die Tür aufmacht (oder so). Ist allerdings nur ein hypothetisches Problem, denn kein Einbrecher dieser Welt kommt mit einem Keylogger. Oliver
Oliver S. schrieb: > Beides kann der Keylogger mitschneiden, und dann jederzeit an die Sau > senden, worauf hin die dann die Tür aufmacht (oder so). Exakt. Darum Challenge-Response. Mit Timestamp oder Zufallszahl drin. Nur hat der TE das eben nicht korrekt formuliert. Er schrieb er will ein MITLESEN verhindern. Also schließt er eine Manipulation oder ein Senden durch den Angreifer aus. Was aber ja nicht korrekt ist. Darum schrieb ich ja: Er muss sich über die tatsächlichen Szenarien mal klar werden. Aber das will er ja nicht. Stattdessen müssen wir dieses häppchenweisen Unsinn lesen. > Ist allerdings nur ein hypothetisches Problem, denn kein Einbrecher > dieser Welt kommt mit einem Keylogger. Natürlich. Dieses ganze Projekt ist Humbug hoch drei.
:
Bearbeitet durch User
Übrigens: Garagentoröffner mittels Pin Terminal machen das recht elegant: Die Senden einfach nur nach korrketer Pin Eingabe ihre feste Seriennummer per Funk, so wie jede andere Funkfernbedienung für dieses Tor auch. Das Gerät ist zusätzlich noch vergossen und wird über einen 9V Block versorgt. Ein Angriff über das Gerät selbst wird sehr schwer. Also dem Chip da drin dahin zu bringen, den Code ohne korrekte Pin Eingabe zu senden. Bleibt nur das heimliche mitschneiden des Funk-Codes wenn der Besitzer öffnet. Das geht aber bei jeder Fernbedienung genau so. Das Code-Schloss hat diesbezüglich keine Nachteile.
Ich hatte mal ein gerät gebaut, dass per Tastendruck aus dem Sleep Modus erweckt wird. Ich habe dort die Dauer des Tastendrucks als Initialisierungswert für den Zufallszahlen-Generator verwendet.
M. K. schrieb: > Also ganz ohne > Anstrengung bekomm ich den internen ADC des AVRs bis aufs letzte Bit > stabil hin, das ist nun bei 10 bit auch alles andere als schwer. Das hat mich auch mal geärgert, daß der nicht rauscht. Ich wollte man eine 3000V Anzeige basteln mit Mittelwert über 256 Messungen. Die Anzeige wechselte aber stur in 3V Schritten, d.h. die 10Bit standen wie Ast.
Oliver S. schrieb: > Beides kann der Keylogger mitschneiden, und dann jederzeit an die Sau > senden, worauf hin die dann die Tür aufmacht (oder so). Naja sicherheitsrelevante Befehle ohne timecode zu senden ist auch ziemlicher Blödsinn.. timecode sei dank ist das auch recht schmalbandig zu senden Und wenn der Tunichtgut am 29.Januar um 17:30 aufzeichnet kann er am 30sten um 14:00 nix damit anfangen ;)... ich sag nur
Cyblord -. schrieb: > Bleibt nur das heimliche mitschneiden des Funk-Codes wenn der Besitzer > öffnet. Das geht aber bei jeder Fernbedienung genau so. Bei den primitiven magst du Recht haben. Ansonsten guckst du hier: https://de.wikipedia.org/wiki/Rollingcode
Ben B. schrieb: > Na dann mach mich doch mal schlau, wie es die Profis machen. Bin > gespannt, das zu hören. Genau wie beschrieben. Eine Rauschquelle per ADC sampeln und damit die Zuffallsszahl erstellen. Stichwort True Random Number Generator https://en.wikipedia.org/wiki/Hardware_random_number_generator Die Kunst ist für die Entscheidung 1 oder 0 möglichst 0.5 für die Wahrscheinlichkeit zu erreichen. http://robertnz.net/true_rng.html
@Cyblord Ich habe keine Ahnung wo Dein Problem liegt, eigentlich dachte ich, daß Du zu konstruktiven Beiträgen fähig bist. Das scheint aber auch von echtem Zufall abzuhängen. Schade. Natürlich mache ich mir Gedanken drüber, daß replay-Attacken schwierig werden. Ich glaube aber, das bekommt man nur über einen Schlüsselaustausch hin, etwa sowas wie daß die Zentrale dem Terminal einen Startwert für einen Zufallszahlengenerator übermittelt. Den von der Zentrale gesendeten Zufallswert als Startwert kann der Angreifer nicht beeinflussen und kann dadurch ohne Kenntnis des zweiten Teilschlüssels im Flash keine korrekten Codes senden. Für eine Replay-Attacke dagegen bräuchte man dann Tabellen für jeden Startwert. Ich glaube wenn man das alles mit 256 Bit ausführt und überträgt, würden diese Tabellen so groß, daß niemand sie mit vertretbaren Mitteln auch nur speichern könnte. Wenn man diesen Startwert dann noch alle paar Minuten wechselt, veralten "frische" Einträge in solchen Tabellen auch so schnell, daß man damit effektiv nichts anfangen kann.
Beitrag #5718493 wurde von einem Moderator gelöscht.
Der Controller, der den echten Zufallswert als Startwert liefern müsste ist ein ATMega1284. Der hat leider keinen Temperatursensor.
Hallo,
Anton M. schrieb im Beitrag #5718493:
> ... und hast keine Ahnung wie pseudo-zufällig diese Werte wirklich sind.
Du solltest dir besagte Funktion mal näher ansehen...
rhf
Ben B. schrieb: > Und noch eine Frage hinterher. Wie bekomme ich beim Start eines > AVR-Controllers eine wirklich echte Zufallszahl, Daran haben sich schon genug Mathematiker die Zähne ausgebissen. Kannst du vergessen. Für eine gute Pseudo-Zufallszahl findest du sicher etwas in den AVR-Applikationen. Reicht für den Bastler locker.
Beitrag #5718522 wurde von einem Moderator gelöscht.
Ach, wie groß setzt du die Zahlentiefe an? Aber über die Mengenlehre und Wahrscheinlichkeitsrechnung. Sag jetzt aber nicht, es ist keine Mathematik.
Mit Amateurmitteln ist "Zufall" nicht so einfach. Man darf davon auch keine "unknackbare" Verschlüsselung erwarten. Fassen wir mal die Ideen zusammen: - Die "beiliegende Zufallsfunktion" ist Mist: Das ist oft nur eine Modulo-Funktion, die bei gleichen Startbedingungen den gleichen Startwert liefert. Wenn sie halbwegs gut ist, erwartet sie einen Startwert (SEED), den man ja auch erst mal "zufällig" erzeugen muss... - Der offene ADC-Eingang liefert nur Zufallswerte, wenn man es nicht erwartet. Oft wird er gegen MAX oder MIN gezogen, oder verhält sich erstaunlich stabil. - Die interne Temperaturmessung bei Atmel gibt nur ca. 1 LSB/°C, ist also unbrauchbar. - Eine Rauschdiodenschaltung kann ECHTE Zufallswerte liefern, benötigt aber ein paar zusätzliche Bauelemente, eine gute Schirmung und einen ADC-Kanal, den du ja nicht mehr frei hast. - Also: Aufforderung zum Taste-drücken. Startet man einen 16-Bit-Zähler mit F = F-CPU, wird es schon schwer, jedesmal zum gleichen Zählerstand die Taste zu drücken. - Wenn es ohne Nutzereingabe, loslaufen soll, käme ja wirklich nur der temperaturabhängige Frequenz-Offset des Watchdog-Timers gegenüber deiner Quarz-Frequenz in Frage. Da sollte man aber ordentlich Zeit (einige Sekunden bis Minuten!) einplanen, damit sich der Offset deutlich mehrstellig zeigt.
Nochmal: Was ich gerade als Idee habe ist, ein RC-Glied mit einem digitalen AVR-Pin umzuladen und während der Umladezeit einen kleinen 8Bit-Zähler laufen zu lassen. Der Zähler läuft extrem schnell, wird mehrere Mhz erreichen und sollte in der Umladezeit auch etliche Male überlaufen. Das Ergebnis dieses Zählers kann man dann in einen Zufallswert reinaddieren, schieben, XORen was immer man möchte, möglichst chaotisch halt. z.B. 1..10nF Kondensator zwischen Pin und Masse, aufladen über den internen PullUp-Widerstand. grobe Überlegung:
1 | start: |
2 | <PinXY auf Eingang, PullUp aktiv> |
3 | count: inc r16 |
4 | sbrs PortX,Y |
5 | rjmp count |
6 | <PinXY auf Ausgang, aktiv low> entlädt den Kondensator |
7 | wait: sbrc PortX,Y |
8 | rjmp wait |
9 | <Ergebnis in R16 verwursten> |
10 | <if counts<1000 rjmp start> |
Das ganze vielleicht 1000mal durchlaufen lassen. Der Zähler läuft mit etwa 3Mhz, läuft in einer Sekunde also 11718mal über. Wenn die Spannung am Kondensator mit 1kHz schwingt (dann dauern 1000 Durchläufe etwa eine Sekunde), dauert das ganze etwa eine Sekunde. Mich würde sehr wundern, wenn da jemand immer auf die gleichen Messergebnisse käme. Vielleicht auch nur die unteren zwei Bits einer jeden Zählung verwenden. Wie hoch ist die Chance, daß da ein berechenbares, wiederholbares Ergebnis herauskommt?
Beitrag #5718543 wurde von einem Moderator gelöscht.
Beitrag #5718550 wurde von einem Moderator gelöscht.
Ben B. schrieb: > Der Controller, der den echten Zufallswert als Startwert liefern müsste > ist ein ATMega1284. Der hat leider keinen Temperatursensor. Aber einen RTC-Timer. Wenn man da einen Uhrenquarz dranhängt, kann man dessen Einschwingverhalten (im Vergleich zum Systemtakt) als Entropiequelle benutzen. Außerdem hat der Mega1284 16kRAM, der beim PowerOn nicht initialisiert ist. Auch eine ganz brauchbare Quelle für Entropie. Eine weitere Möglichkeit: der Analog-Komparator. Wenn man einen der beiden AINx offen läßt und das Potential des anderen über einen Zweipunktregler mit PWM-Ausgang "regelt", wird auch ein Haufen Zufall geliefert.
Ben B. schrieb: > Und noch eine Frage hinterher. Wenn dieser Satz der erste Satz des ersten Artikels im Thread ist, finde ich das schon lustig :-)
Ben B. schrieb: > @Cyblord > > Ich habe keine Ahnung wo Dein Problem liegt, eigentlich dachte ich, > daß Du zu konstruktiven Beiträgen fähig bist. Das scheint aber auch von > echtem Zufall abzuhängen. Schade. Bei dir ist leider alles zu spät. Du scheinst einfachste Einwürfe gar nicht zu verstehen. > Natürlich mache ich mir Gedanken drüber, daß replay-Attacken schwierig > werden. Ja? Wo steht das? > Ich glaube aber, das bekommt man nur über einen > Schlüsselaustausch hin UNSINN. Für den Schutz gegen Replay Attacken reicht eine vom Host generierte ID oder ein Timestamp. Erfordert aber bidirektionale Kommunikation. Daher Challenge/Response Verfahren. Hab ich jetzt schon drei mal erwähnt. Benutzer gibt PIN im Terminal ein. 1.) Terminal sendet KOMMANDO an Zentrale (z.B. Alarmanlage aus). 2.) Zentrale erzeugt eine ID/Timestamp und sendet an Terminal. 3.) Terminal erzeugt HASH (ID+KOMMANDO+PIN) und sendet an Zentrale 4.) Zentrale erzeugt ebenfalls diesen HASH und vergleicht. 5.) Wenn korrekt wird die Alarmanlage ausgeschaltet. Die einfache HASH Funktion kann man durch das HMAC verfahren ersetzen. Ein Angreifer kann durch mithören und manipulieren der Daten nichts erreichen. Replay durch die ID ausgeschlossen. PIN wird niemals im Klartext übertragen und kann nicht durch mitloggen rekontruiert werden. Es gibt keine Geheimnisse im Terminal die ein Angreifer auslesen könnte. -> Terminal muss nicht gesondert geschützt werden. Hat man mehrere Nutzer kann die Zentrale alle PINS durchprobieren oder man sendet die Benutzerkennung noch im Klartext mit, sofern diese dem Terminal bekannt ist. Ich denke aber bei dir reichts leider nicht für eine kontruktive Diskussion zu diesem Thema. Daher fühlst du dich auch angepisst. Kann ich aber nichts dafür. Und ja, leider ist das Zufallszahlproblem in Wirklichkeit gar nicht dein Hauptproblem. Für dein Szenario kommt man ohne Zufall aus.
:
Bearbeitet durch User
Nimm dir drei Inverter (mit Schmitt-Trigger-Eingang) und schalte die als schnellen Ringoszillator im Kreis. An einer Stelle baust du noch einen RC als Frequenzbremse ein, damit du die Inverter nicht überforderst. Als Abgriff nimmst du ein Latch, damit du die setup/hold-Zeiten vom AVR nicht verletzt. Braucht zwei Pins. Die Oszillatorfrequenz ist temperaturabhängig und instabil, daher der Zufall.
Stefanus F. schrieb: > Ich habe dort die Dauer des Tastendrucks als > Initialisierungswert für den Zufallszahlen-Generator verwendet. Ich hab mal einen Würfel so aufgebaut. Die Drückdauer als Zufall funktioniert sehr gut.
@Cyblord Letzte Bemerkung an Dich: Wenn Du mich nicht verstehen willst dann gratuliere ich Dir zu Deinem tollen Erfolg! @Rest Danke für eure Beiträge, denke ich probiere die Methode mit dem RC-Glied einfach mal aus, scheint mir am vielversprechendsten. Beim RAM weiß ich nicht inwiefern das beim Start des Controllers wirklich rein zufällige Werte enthält. Darüber habe ich auch nichts zu lesen gefunden, ansonsten wäre es klasse, wenn man den kompletten RAM-Inhalt einfach einmal zusammenaddieren könnte. Hat das schon jemand durchprobiert?
Ben B. schrieb: > Darüber habe ich auch nichts zu > lesen gefunden, ansonsten wäre es klasse, wenn man den kompletten > RAM-Inhalt einfach einmal zusammenaddieren könnte.
1 | unsigned int get_seed() |
2 | {
|
3 | uint16_t seed = 0; |
4 | uint16_t *p = (uint16_t*) (RAMEND+1); |
5 | extern uint16_t __heap_start; |
6 | while (p >= &__heap_start + 1) |
7 | seed ^= * (--p); |
8 | return seed; |
9 | } |
Ben B. schrieb: > Beim RAM weiß ich nicht inwiefern das beim Start des Controllers > wirklich rein zufällige Werte enthält. Fertigungsunterschiede können eine Vorzugslage bewirken. Wenn man einen uninitialisierten RAM mal als Bild ausgibt, ergibt das oft sehr regelmäßige Muster. SRAM kann seine Daten noch viele Sekunden ohne VCC behalten.
wie was? 8bit; Was machste denn damit? wie lange glaubst Du braucht ein Angreifer um 256 Werte durchzuprobieren mit einem zweiten Microprozessor als Klon, wenn Dein Zähler in der Sekunde 11718mal überläuft? Jaja Initialwert... aber ernsthaft, ausgehend von einer sniffing Attacke... und seiner Kompetenz den zugrundeliegenden Code strukturell zu erahnen halt ich das für keinen wirklich relevanten Sicherheitsaspekt. Ich bleib dabei p/p keypair krummwertiges RSA macht mehr Sinn
Beitrag #5719218 wurde von einem Moderator gelöscht.
Ben B. schrieb: > @Cyblord > Letzte Bemerkung an Dich: Wenn Du mich nicht verstehen willst dann > gratuliere ich Dir zu Deinem tollen Erfolg! Undank ist der Welten Lohn.
@Cyblord Das hat nichts mit Undank zu tun. Du unterstellst mir Sachen die nicht stimmen und das dann auch noch auf eine Weise, die mich als grenzdebil erscheinen lassen. Was hast Du denn gedacht, daß ich mich darüber freue und Luftsprünge mache, oder was?! Genau wie sid ... vielleicht weiß er es nicht besser, aber könnte man sich nicht selbst denken, daß mir ein Schlüsselraum von 8 Bit bei weitem nicht reicht? Nöö, da wird erstmal unterstellt, ich bin mit 256 verschiedenen Werten hoch zufrieden. Was soll das? Das mit den Mustern im RAM kenne ich noch vom C64. Wenn man da in den Grafikmodus (HiRes) schaltete ohne vorher was ins RAM zu schreiben, ergab das regelmäßige Streifen von jeweils 8 Bit Länge, deren Zustand meistens horizontal und vertikal wechselte. Man konnte quasi die einzelnen Kästchen des Buchstabenrasters noch erkennen. Ich weiß aber nicht, ob der C64 das RAM vorher (oder beim Setzen des HiRes Mode) mit irgendwas initialisiert hat, es sah aber nicht so aus, als ob er es benutzt hätte. Edit @Cyblord: Übrigens hat das Terminal mit Absicht null Intelligenz. Es kennt die PIN-Codes nicht und kann demzufolge auch keine Kommandos senden. Das einzige Kommando was es senden kann ist eine Anforderung beim Start, doch bitte den aktuellen Zustand zu übermitteln, falls es mal einen Reset an einer länger laufenden Zentrale durchläuft. Der Rest sind nur die 12 Tasten, die direkt in die Ziffern und "#" und "*" gewandelt sind.
:
Bearbeitet durch User
Ben B. schrieb: > Danke für eure Beiträge Hier ein echt zufälliger Generator: Geigerzählrohr o.ä. auf Halbleiterbasis und ein Körnchen Plutonium. Wäre doch eine echt spannende Bastleraufgabe und nicht sinnloser als alles andere. Georg
Anton M. schrieb im Beitrag #5719218: > Peter D. schrieb: >> Wenn man einen uninitialisierten RAM mal als Bild ausgibt, ergibt das >> oft sehr regelmäßige Muster. > > Das möchte ich auch bestätigen. Ich nicht. Klar sind gelegentlich leichte Muster erkennbar, aber das ist noch nicht mal das Schlimmste, es sind dann bei jedem Kaltstart desselben Exemplars auch noch sehr ähnliche Muster. Der Kernpunkt aber: es ist immer auch eine starke Zufallskomponente enthalten. Man muss den Kram also nur durch eine Hash-Funktion nudeln, um einen relativ gut zufälligen Wert zu erhalten, insbesondere dann, wenn man die Daten aus dem RAM auch noch mit denen aus anderen (unabhängigen) Entropiequellen mixt. Ich habe in meinem Posting zwei Mögliche genannt, die auf einem Atmega ohne großen Aufwand verfügbar gemacht werden können, die eine davon (RTC an Timer2) haben viele Anwendungen sowieso schon onboard, sie muss in der Startphase nur ein bissel anders genutzt werden, d.h.: reine Softwareänderungen können in diesem Fall den Job erledigen... Wen ein konkretes Beispiel für die RAM-Geschichte interessiert: https://hackaday.com/2015/06/29/true-random-number-generator-for-a-true-hacker/ Das stellt ziemlich genau dasselbe dar, was auch ich beobachtet habe. > Als Zufallsquelle eher nicht geeignet. Jaja, du hast mehr Ahnung als z.B. die Leute, die OpenSSL machen, ist schon klar...
Beitrag #5719472 wurde von einem Moderator gelöscht.
Den zweiten externen Oszillator zu beschalten würde ich mir gerne ersparen. Spricht denn irgendwas dagegen, einfach einen 1..10nF Kondensator an einen oder zwischen zwei Pins zu hängen und diesen 500..1000mal umzuladen während man mit 3Mhz die "Zeit misst", die ein Umladevorgang dauert und sich aus den unteren Bits davon eine Zufallszahl bastelt? Oder von mir aus auch 1..10nF in Reihe mit einem 1k Widerstand, dann rauscht's noch ein wenig mehr...
Man könnte auch einfach einen Kondensator per I/O Pin auf LOW legen und danach den Pin als Eingang mit Pull-Up konfigurieren. Dann warten, bis er HIGH Pegel erreicht hat. Wenn dafür kein Pin mehr frei ist, kann man den Pin auch doppelt belegen, zum Beispiel mit einem Schalter oder einem analogen Sensor kombinieren.
@Stefanus Hast Du diesen Beitrag von mir überhaupt gelesen: Beitrag "Re: AVR: Zufallszahlengenerator - zufälliger Startwert" ??
Ben B. schrieb: > Spricht denn irgendwas dagegen, einfach einen 1..10nF Kondensator an > einen oder zwischen zwei Pins zu hängen Wenn du sowieso zwei Pins frei hast, kann ich nur die Sache mit dem Analog-Komparator empfehlen, das hat in meinen Versuchen mit diversen, mit der vorhandene Hardware einfach zu implementierenden Entropiequellen die mit weitem Abstand besten Ergebnisse geliefert. Musst du halt schlimmstenfalls die Funktionen von zwei Pins verlagern, um eben die AINx-Pins frei zu bekommen, dann bedeutet es Hardware-Änderungen.
AIN0 und AIN1 sind beide noch frei und liegen "günstig" in der Nähe des GSM-Moduls mit seinen 1..2W Sendeleistung. Kannst Du Deine Idee bitte nochmal erläutern oder beschreiben, wie Du das Problem damit gelöst hast?
Ben B. schrieb: > Autor: > > Ben B. > (Firma: Funkenflug Industries) > (stromkraft) > > > > > > > > > Datum: 01.02.2019 18:49 Ich habe jetzt schon jede Menge Threads zu Deiner "AlarmSau" gesehen. Kann es sein, dass Du nur Werbung dafür machen möchtest? Irgendwie drängt sich mir das auf - Du kannst mich gerne korrigieren.
Ben B. schrieb: > @Stefanus > Hast Du diesen Beitrag von mir überhaupt gelesen: > Beitrag "Re: AVR: Zufallszahlengenerator - zufälliger Startwert" ?? Ähhhhhhh - Nein. Erwischt.
Dieter F. schrieb: > Ich habe jetzt schon jede Menge Threads zu Deiner "AlarmSau" gesehen. > Kann es sein, dass Du nur Werbung dafür machen möchtest? Das glaube ich kaum. Was ich bisher zu dieser "AlarmSau" gelesen habe, würde mich zumindest jedenfalls ganz sicher eher davon abhalten, das Teil zu kaufen, selbst wenn ich Bedarf für so eine Lösung hätte...
Dieter F. schrieb: > Kann es sein, dass Du nur Werbung dafür machen möchtest? Er hat mal geschrieben, dass es sich dabei um ein Hobbyprojekt ist. Für ein kommerzielles Gerät hätte er einen gediegeneren Namen gewählt. Offensichtlich ist er sehr Stolz auf seine AlarmSau - warum auch nicht?
ich für meinen Teil denke mir nur, dass BIS Du einen 'sicheren' Wert generiert hast (den dann mit der Gegenstelle abgeglichen hast) hast Du mehr Zeilen Code verbraten als Du für ein fixed pair gebräucht hättest; vorallem der Abgleich mit der Gegenstelle stellt ein zusätzliches Risko dar (von wegen replay und sniffing und so) Gleichst Du nicht mit der Gegenstelle ab, müsste der KeyCode einem 'bekannten' Muster entsprechen, dann rennst Du wieder in dasselbe Problem, weil jeder Code der demselben Muster entspricht ebenfalls valid wäre. (und damit ist ein bisschen raten alles was es braucht) Aber nun, Du willst random; prima.. sag nur nicht dass Du es brauchst um die Datenübertragung zu sichern; den preshared keys sind da deutlich sicherer (und kürzer/effizienter im Programmablauf) Rauschen ist super wenn Du 'EINMALIG' den Zufall erzeugen musst zur erstellung des keys, dann wiederum hilft aber notfalls random.org ;) Naja, vielleicht bin ich da engstirnig, vermutlich sogar; liegt am Job ... ignorier mich einfach wenn Du magst. Ich lass Dich jetzt auch in Ruhe hier weitertüfteln ;)
Werbung für die AlarmSau... kicher Da es bislang keine konkreten Pläne gibt, das Ding irgendwo zu verkaufen, weiß ich nicht was das für einen Sinn machen sollte. Stolz... ich vertrete gerne meine Standpunkte. Die AlarmSau ist einer. Ich will das Ding einfach nur so gut machen, wie es mit Hausmitteln möglich ist. Und auch wenn viele das hier für Blödsinn halten oder für Overkill oder mir Debilität unterstellen - ich wette das Ding kann mit kommerziellen Lösungen mehr als mithalten. > Das glaube ich kaum. Was ich bisher zu dieser "AlarmSau" gelesen habe, > würde mich zumindest jedenfalls ganz sicher eher davon abhalten, das > Teil zu kaufen, selbst wenn ich Bedarf für so eine Lösung hätte... Dann würdest Du auch kein Wasser trinken wenn Du wüsstest, daß 8 Liter davon definitiv tödlich wären. Übrigens danke für Deine Erläuterung. Egal, sehe schon ich werds selbst mit meiner RC-Variante probieren müssen. Danke allen Leuten, die konstruktive Beiträge geliefert haben!
Ben B. schrieb: > AIN0 und AIN1 sind beide noch frei und liegen "günstig" in der Nähe des > GSM-Moduls mit seinen 1..2W Sendeleistung. Das ist egal. Die Gewinnung des Startwerts für einen RNG geschieht beim Startup des Systems. Da dürfte das GSM-Modul noch nicht senden. Und das ist auch gut so, denn das würde die Entropie eher deutlich verringern. > Kannst Du Deine Idee bitte nochmal erläutern oder beschreiben, wie Du > das Problem damit gelöst hast? Ist doch simpel: du schnappst dir dem PWM-Ausgang eines Timers (wird nur in der Startup-Phase benötigt, kann dann zur eigentlichen Laufzeit der Anwendung ganz andere Funktionen erfüllen). Den Ausgang legst du über einen hochohmigen Widerstand (Größenordnung 100kOhm..1MOhm, bildet zusammen mit den parasitären Kapazitäten von AINx einen Tiefpass) entweder an AIN1 oder AIN0, das ist egal. Der verbleibende AINx bleibt offen, die digitale Eingangschaltung dafür sollte über DIDRx abgeschaltet werden. Das war die Hardware, der Rest ist Software. Der Timer wird für Fast-PWM mit Systemtakt konfiguriert. Bit Null von TCNTx ist letztlich das Nutzdatum. Nun läßt du einen primitiven Zweipunktregler laufen, der entsprechend dem Status von ACO zu dem OCRx des Timers entweder eins addiert oder eins subtrahiert (je nachdem, ob du AIN0 oder AIN1 mit dem Timerausgang verbunden hast). Natürlich muss das mit "gesättigter" Arithmetik passieren. Nun muss du nur noch jedesmal, wenn der Regler seinen Aktor-Increment zwischen +1 und -1 umschaltet das unterste Bit von TCNTx auslesen und an die Hash-Funktion verfüttern. Idealerweise läßt du den ganzen Salat parallel zur der Gewinnung der Entropie aus dem RAM laufen und fütterst das Bit in diesen Prozess mit ein. Sprich: du ersetzt einfach irgendein Bit des nächsten an die Hashfunktion zu verfütternden RAM-Bytes durch das TCNTx-Bit 0. Natürlich sollte die ganze RAM-Sache erst dann starten, wenn der Regler das erste Mal umschaltet. Sollte (hoffentlich) klar sein...
Anton M. schrieb im Beitrag #5719472: > Man sollte aber aufpassen, um die Erzeugung von Zufallszahlen kein > unnötig großes Brimborium zu veranstalten! Aha. Du bist nicht zufällig der Debian-Maintainer für OpenSSL? Nein. Der hat ja wenigstens noch versucht, sich aufzuschlauen, bevor er den ultimativen Schaden angerichtet hat. Er hat also zumindest eine Ahnung davon gehabt, wie wichtig ein zuverlässiger Zufall ist. So weit bist DU offensichtlich noch nicht einmal näherungsweise...
c-hater schrieb: > Aha. Du bist nicht zufällig der Debian-Maintainer für OpenSSL? Du müsstest mal erklären wo wir hier OpenSSL brauchen. Wirst bestimmt gleich mit einer tollen Idee überraschen! c-hater schrieb: > Timer wird für Fast-PWM > primitiven Zweipunktregler > Natürlich mit "gesättigter" Arithmetik > Hash-Funktion > Gewinnung der Entropie aus dem RAM > Ist doch simpel Nein. Ist Brimbamborium. Aber wenns Spaß macht... Wenn man einem (alten) AVR schon den Zufall zuführen muß besorgt man sich einen halbwegs zufälligen Puls, greift damit seine Werte in schönster Gleichverteilung von einem schnell laufenden Timer ab und spart sich damit überdrehte Software-Krämpfe. Der Einschalt-Zustand des SRAM lässt sich ja vielleicht noch als individuelle Signatur gebrauchen.
Anregungen:
TRNG: Kombiniere mehrere Entropiequellen, z.B.:
- ADC Noise: Wenn dein ADC differentiell ist und eine Gain Stage hat,
dann kannst du eine Messung an beiden Kanälen vom selben Pin machen
(ggf. geht auch intern GND). Dann ein Gain einstellen. Theoretisch sieht
die Gain Stage dadurch 0V, praktisch ist es etwas anderes. Die
differentielle Messung erlaubt dir zudem unabhängig von externen
Eingaben zu sein (Angreifer könnte z.B. Pin auf GND legen); der konkrete
Wert am ADC-Eingang kann dir egal sein. Dadurch misst du den Fehler der
Differenz und der Gain Stage, der idealerweise Toleranzen aus dem
Fertigungsprozess und Temperatur unterworfen ist.
- Watchdog Jitter vs. Main Oscillator: Messe den Fehler zwischen
Watchdog und CPU Oscillator, z.B. Timer starten und bei WDT Interrupt
auslesen. WDT ist relativ großen Toleranzen aus Fertigung und Temperatur
unterworfen. Qualität aber nicht überschätzen, mglw. langt das nur für 1
bit/s (z.B. weil Temperatur relativ konstant).
- EEPROM/Flash seed: bringt nicht viel für die Sicherheit, lässt sich
aber leicht einrichten.
- Validiere deine Entropiequellen, teste verschiedene Konfigurationen:
siehe NIST Special Publication 800-22
Dies erlaubt dir auch, gute Einstellungen z.B. für das Gain zu finden,
oder welche Bits vom Timer zu verwenden sind.
PRNG:
- Hashfunktion: AES 128 oder z.B. Keccak-f[200]
- Kontinuierlich auf einen Zustand anwenden
- Wenn neue TRNG-Werte verfügbar, auf PRNG-Zustand xoren ("re-seedable
PRNG")
- PRNG Entropie ("Sicherheitsniveau") sollte zu deinem Cryptoverfahren
passen (nicht: tolle Crypto mit 3 Bit PRNG). Bei AES 128 also > 128 bit
Entropie.
- PRNG mit NIST-Tools validieren (s.o.)
Crypto:
- Hast du dir Gedanken zu Seitenkanälen (Timing, DPA) und Gegenmaßnahmen
gemacht?
- Zum Beispiel: AES 128 mit
- Shuffling (Vorsicht: kein modulo % verwenden (bias), besser:
Fisher-Yates Shuffle)
- Masking (Angreifer muss damit mind. 2nd Order DPA machen)
- Dummy S-Box Zugriffe
- Zufälliges an-/ausschalten von anderen Peripherals, um zusätzlich
Ungleichmäßig Strom zu verbrauchen
- Clock Scaling
- Verwende einen sicheren Cyphermode, kein AES-ECB.
- Lock-bits setzen, um Auslesen des Flash zu verhindern. Wirkt
allerdings nur begrenzt, da Decapping immer noch möglich.
Bedenke bei alledem: AVRs sind nicht für Sicherheit gebaut. Sie haben
keine symmetrischen Busse, keinen Decapping-Schutz etc.
Moin! Gegen direkte Hardware-Angriffe lohnt sich ein Schutz nicht. Wenn der Angreifer das hinbekommt, da irgendwelche komplizierte Technik direkt an den µC der Zentrale anzuschließen oder gar den µC für's Decapping zu klauen ohne daß es jemand merkt, dann ist bereits so viel schiefgelaufen, daß ein Schutz nichts mehr bringt. Der Angreifer darf es gar nicht unbemerkt bis zur scharfgeschalteten Alarmzentrale schaffen. Wenn er es doch schafft: richtig schlecht, dann war der Aufbau in etwa so verhunzt, als hätte man eine Tür offen stehen lassen oder den Code gleich auf's Display geschrieben damit man ihn nicht vergisst. Das einzige was ich zuverlässig verhindern möchte ist, daß ein Angreifer zerstörungsfrei einen Keylogger oder so an die USART-Verbindung klemmt und so alles mitliest, was an Tastenanschlägen übertragen wird. Dadurch kommt er sonst evtl. unbemerkt an einen gültigen PIN-Code und könnte damit die Anlage entschärfen ohne daß es jemand merkt oder weiß wer es war. Der Rest sollte auffallen, entweder durch Alarm oder eine nicht funktionsfähige Anlage (wenn der Controller fehlt). Wenn der Controller oder die ganze Anlage fehlt braucht man sowieso was neues. Damit werden alle alten Codes hinfällig (nur ein Idiot würde nach so einem Vorkommnis die gleichen PINs nochmals verwenden) und man könnte den beiden neuen µCs auch ein anderes Schlüsselpaar mitgeben. Dann bekommt der Angreifer zwar das Programm und sämtliche im alten Controller gespeicherten Daten, aber für einen Angriff gegen das neue Controller-Paar sind diese Daten völlig nutzlos. Hat jemand Infos wieviel solche Angriffe wie Decapping oder sonstwelches Brechen der Lockbits kosten?
Ben B. schrieb: > Hat jemand Infos wieviel solche Angriffe wie Decapping oder sonstwelches > Brechen der Lockbits kosten? Ist günstiger als man gemeinhin glaubt. Decapping kann man entweder selber machen (Rauchende Schwefelsäure, Abschleifen) oder man hat ein Uni-Institut, dass das für einen macht. Als Elektrotechniker an der TU München kann man solche Sachen z.B. von den TU Chemikern machen lassen, also eine interne Dienstleistung. Gibt auch einige Youtube-Videos zum Decapping. Wenn man weiß, wo die Fuses auf dem Die sind, kann man den Rest abdecken und mit einer UV-Lampe ein paar Stunden auf die Fuses leuchten. Je nach Strukturbreite des verwendeten IC ist das mehr oder weniger aufwändig.
Wie gesagt, ich könnte alternativ noch wichtige Pins von den Programmierinterfaces zu schießen probieren. Die sind bis auf TCK vom JTAG alle nicht belegt. Keine Ahnung wie sehr der Die davon in Mitleidenschaft gezogen wird, wenn man kurz mal ein paar Ampere durch die GND-Schutzdiode schickt oder so. Naja egal, ein Schutz gegen sowas ist mir gar nicht so wichtig, da die Daten in dem µC nach dessen Verlust nichts mehr wert sind. Das würde sich evtl. nur lohnen wenn jemand scharf auf das Programm ist um das Ding nachzubauen. Bezweifle ich aber, das kann er einfacher haben wenn ich ein gutes Angebot bekomme oder so. Und so wie's im Moment aussieht bleibts sowieso bei dem einen Prototypen... daß ausgerechnet hier jemand diesen einen µC klaut... nee!
Gut. Angenommen es geht dir nur um Schutz vor Eavesdropping des PIN codes (confidentiality) und Manipulation auf dem Bus selbst (integrity, authenticity). Sniffing verhindert man mit Verschlüsselung. Es gibt Block-Chiffren und Strom-Chiffren. In deinem Fall ist es vermutlich egal. Manipulationen erkennt man mit MACs. Replay verhindert man mit ausreichend großen Zählern (Nonces). Bevor diese Überlaufen muss man ein re-keying machen (vgl. counter/nonce reuse). Schau dir mal Encrypt-then-MAC an, oder AEAD: https://en.wikipedia.org/wiki/Authenticated_encryption DH-Schlüsselaustausch wurde schon genannt. Alternativ Pre-Shared-Keys verwenden und regelmäßig neuen Session-Key aushandeln. Wenn du die PIN über ein Ziffernblock eingibst, bedenke aber auch, dass man mit einer Wärmebildkamera ablesen kann, welche Tasten gedrückt wurden. Vgl. Geldautomaten...
Yep, ich bekomme nur mein eigenes System sicher. Wenn jemand seinen PIN-Code verrät oder so oder wenn man eine Kamera über das Terminal baut, dagegen kann ich technisch nicht viel machen. Sowas zu verhindern liegt nicht in meiner Verantwortung, das muss durch Loyalität oder bauliche Maßnahmen sichergerstellt werden wenn man das möchte. Allerdings können die Codes bis zu 10 Ziffern lang sein, nicht nur 4 wie beim Geldautomaten. Wenn da jemand ein paar Tasten kennt, muß er schon eine Weile probieren. Nach drei Fehlversuchen hat sich's auch erstmal für 5 Minuten erledigt. Nach weiteren drei Fehlversuchen bekommt der Administrator (und wenn man möchte noch weitere Teilnehmer) eine SMS, daß da jemand falsche Codes durchprobiert. Könnte man auch schon nach den ersten drei Fehlversuchen schicken. Dann kann man rechtzeitig Gegenmaßnahmen ergreifen oder ggf. mal auf das Überwachungsvideo schauen wenn man das Ganze so stark sichern möchte.
Schließe an den AVR per SPI oder TWI einen STM32 an. Der STM32 hat einen "TRNG" - Random Number Generator als Peripheriemodul drin. Nun brauchst du nur noch einen ein kleines Progrämmchen das den RNG aus liest und für den AVR bereit stellt.
Wenn du auf re-keying vermeiden möchtest und dein System selten genug verwendet wird (bei Garagen-/Tor-/Türöffner und dergleichen von Menschen bedienten Systemen der Fall), kannst du das auch dadurch lösen, dass der Counter groß genug ist (z.B. 32-bit) also erst "nach Ewigkeiten" (real: nie) überläuft. Counter dann im EEPROM speichern und nach Stromausfall laden. Hat den weiteren Vorteil, dass du die Kommunikation nur in eine Richtung machen musst.
Beitrag #5720417 wurde von einem Moderator gelöscht.
Mit Pre-Shared-Key und Counter als Nonces brauchst du keinen TRNG im uC mehr. Du generierst dir den key halt einmal aus /dev/random oder /dev/urandom und schreibst ihn ins Flash.
Also eine Nachricht vom Tastenfeld könnte IMHO so aussehen:
1 | SYNC | NONCE | ENC(HEADER | PIN) | MAC |
2 | |
3 | SYNC := Sync Sequenz, z.B. 0x01 0x02 0x03 0x04 |
4 | NONCE := 32-bit counter |
5 | ENC := AES-128 mit Pre-shared key, immer vollen Block (16 Byte) übertragen |
6 | HEADER := len(PIN) oder feste Länge von PIN verwenden oder PIN mit \0 terminieren. |
7 | PIN := Gedrückte Tasten z.B. "123456<CR>" |
8 | MAC := Hashfunktion oder ggf. AES-128 ("CMAC") mit separaten pre-shared key; mglw. kann man die Größe auch halbieren z.B. wenn man die oberen und unteren 8 Byte xored.
|
AES-128 auf einem ATmega644 bei 4.8 MHz benötigt so ca. 1.05ms. Eine Nachricht hat dann z.B. 32 Byte Größe (4B Sync, 4B Nonce, 16B ENC, 8B MAC). Da man zum Dekodieren 2x AES laufen lassen würde (MAC und Decrypt), also ca. 2.5ms je Nachricht. (Die Implementierung ist aber definitiv anfällig gegen DPA Seitenkanal. AES mit weiter oben genannten DPA Countermeasures ist in ~4 bis 300 ms zu haben)
Jiri D. schrieb: > Also eine Nachricht vom Tastenfeld könnte IMHO so aussehen: > >
1 | SYNC | NONCE | ENC(HEADER | PIN) | MAC |
Eigentlich könnte man auch die Nonce noch dazu packen, dann hat man nicht das Problem mit Wiederholungen des selben Cyphertext. Für die Sicherheit aber irrelevant (da Nonce+MAC).
1 | SYNC | ENC(NONCE | HEADER | PIN) | MAC |
AES wäre eine Möglichkeit. Gibts da Quellcode-Vorlagen für Assembler? Es wird immer nur eine einzige Taste übertragen, daraus irgendwas zusammenzusetzen macht alles die Zentrale. Also da brauchts keinen komplexen CRC-Code oder so, wenn man mit AES drangeht muß man sowieso den kompletten Block übertragen und könnte die Taste 2..3mal hineinpacken bevor man den Block mit Schrott auffüllt. Bei Übertragungsfehlern geht die Entschlüsselung sowieso schief und dann merkt man das. Dann muss der Benutzer die Taste halt nochmal drücken, sehe ich nicht als Problem. Für Seitenkanalangriffe bräuchte man definitiv direkten Zugang zur Zentrale. Das darf nicht gegeben sein, sonst könnte man sich den ganzen Umweg über das Terminal sparen. Ein Schutz gegen Seitenkanalangriffe bringt daher nicht viel, dann ist das System sowieso schon überwunden.
Ben B. schrieb: > AES wäre eine Möglichkeit. Gibts da Quellcode-Vorlagen für Assembler? Sowas gabs anno dazumal bei so genannten Fun-Cards für die DBox2 (Atmel-basiert). Damit wurde der wiederum genannte Cam-Key entschlüsselt. Frag mich aber nicht, wo man sowas heute noch finden kann.
:
Bearbeitet durch User
Letztendlich ist die ganze Kryptografie und Identitäts Prüfung ein permanentes Kopf-An-Kopf Rennen mit den Bösewichten. Geräte, die nicht langfristig gepflegt werden, können da nur verlieren. Und das trifft leider auf den grössten Teil der Hausautomation zu. Die allermeisten Leute verwenden Wohnungs-Schlösser mit 4-6 einfachen Stiften. Da kackt sich keiner ins Hemd, dabei weiss jedes Kind, dass jeder Schlüsseldienst diese Schlösser in wenigen Minuten öffnet, ohne sie zu beschädigen. Hinter der Türe liegt dann unser ganzes Hab und gut offen greifbar. Dass bei vernetzten Geräten mehr Sicherheit angemessen ist (und auch bei Bens Keylogger) sehe ich ja ein. Aber man kann es auch übertreiben. Im Computer Bereich wird dem Normal-Verbraucher ständig erzählt, das Fort Knox unzureichend sei. Aber das Schloss an der Wohnungstüre, Auto und Fahrrad wird nicht kritisiert. Wer wirklich reinkommen will, der kommt auch rein. Dagegen hat auch die klügste Mathematik keine finale Lösung. Im Bereich der Schliessanlagen versuchen wir gar nicht erst, uns vor diesen Leuten zu schützen. Da gibt es viel pragmatischere Lösungen: zum Beispiel keine Wertgegenstände anhäufen, im Alltag ein gewöhnliches Fahrrad (< 800€) benutzen, das Auto als Verbrauchsgegenstand betrachten, etc. Manchmal kommt was weg - so what? Ich denke, dass wir bei unseren Daten auch mal ein bisschen lockerer werden sollten. Gerade erst hat eine Hotelkette Millionen Ausweisfotos verloren und wurde dafür nicht einmal bestraft. Dabei bestand keine Notwendigkeit, die Bilder (Wertgegenstände) in diesen Mengen so lange zu sammeln. Das Sammeln an sich war doch schon strafbar - zumindest nach heutigem Stand der Gesetze. Aber niemand bestraft die Sammler.
Stefanus F. schrieb: > Die allermeisten Leute verwenden Wohnungs-Schlösser mit 4-6 einfachen > Stiften. Da kackt sich keiner ins Hemd, dabei weiss jedes Kind, dass > jeder Schlüsseldienst diese Schlösser in wenigen Minuten öffnet, ohne > sie zu beschädigen. Das Problem ist das es halt nicht allgm. bekannt ist. Ich denke die meisten gehen davon aus das Schlösser relativ sicher sind. Im Prinzip genau wie bei Software, den meisten ist gar nicht bewusst wie unsicher viele Dinge sind. Wenn da mal wieder was in den Medien kommt wird halt ein Virenscanner installiert und dann ist ja alles gut ;-) BTW: Interessante Theorie das der Schlüsseldienst Schlösser kostengünstig pickt. Ich hätte jetzt vermutet (keine eigenen Erfahrungen mit Schlüsseldiensten) das Zylinder lieber lohnend ausgebohrt werden.
test schrieb: > Interessante Theorie das der Schlüsseldienst Schlösser > kostengünstig pickt. Das tun sie wirklich. Auch Autos werden in der Branche üblicherweise schadensfrei geöffnet. Ich habe beides erlebt. Mit super unknackbaren Schlössern und Türen würde ich eher mich selbst aussperren, als die Bösewichte.
Stefanus F. schrieb: > test schrieb: > Interessante Theorie das der Schlüsseldienst Schlösser > kostengünstig pickt. > > Das tun sie wirklich. Auch Autos werden in der Branche üblicherweise > schadensfrei geöffnet. Ich habe beides erlebt. OK, da fehlen mir die praktischen Erfahrungen. Ich kenne bei Autos nur die Luftkissenvariante bei der die Tür weggebogen wird. Aber moderne Systeme sperren ja die Betätigung innen. Nur gut das die Schließzylinder in Autos weiterhin minderwertig sind ;-) (Habe mal spaßeshalber geübt mein eigenes Auto zu picken, der 8€ Pick aus China geht super) > Mit super unknackbaren Schlössern und Türen würde ich eher mich selbst > aussperren, als die Bösewichte. Die Bösewichte müssen ja nicht zerstörungsfei, das vereinfacht einiges. Ferner müssen sie nicht zwingend in dein super abgesichertes Haus, sie können problemlos auf das Nachbarhaus (in das man problemlos mit dem Schraubenzieher kommt) ausweichen.
test schrieb: > Ferner müssen sie nicht zwingend in dein super abgesichertes Haus, sie > können problemlos auf das Nachbarhaus (in das man problemlos mit dem > Schraubenzieher kommt) ausweichen. So ist es. Die entscheidende Aussage ist „Schraubenzieher“. Kein Einbrecher und auch kein Schlüsseldienst dieser Welt rückt mit einem Keylogger oder ähnlichen elektronischen Spionagegerätschaften an, die physisch an Drähte angeschlossen werden müssten, um eine Alarmanlage an einem normalen EFH oder gar einer Wohnung außer Gefecht zu setzen. Oliver
Ben B. schrieb: > STM32 nur als Zufallszahlengenerator ... > und da unterstellt ihr mir Overkill? Zumal jeder Nachweis fehlt, dass dieser RNG wirklich zufällige Werte liefert. Das gilt für jeden Closed-Source-RNG, egal ob Hardware oder Software. Es ist nämlich relativ leicht, ein System hinter den Zufallszahlen so zu verstecken, dass es allein mit statistischen Methoden im Output des RNG praktisch nicht nachweisbar ist. Für RNGs gilt: zeige mir deine Entropiequellen und den Quelltext, der sie verwurstet und ich sage dir, ob (und wie weit) ich dir trauen kann... Alles andere ist "Prinzip Hoffnung", nicht mehr.
So denn, ich glaube ich habe die AlarmSau soweit erstmal fertig, mit Ausnahme der Key-Crypto. 323kB Assembler-Quellcode, 11.044 Zeilen, nochmal 29kB Quelltext für's Terminal. Das ist mehr als ein C64 auf eine Diskette bekommt. Beidseitig. Und mir reichts dann langsam auch erstmal, nun ist wieder Hardware angesagt. Wegen Einbrechern... Wenn jemand wirklich rein will, dann kommt er auch rein. Egal ob Alarmanlage oder nicht, egal was da für eine tolle Tür dran ist - die liegt hinterher samt Rahmen im Flur wenn man Pech hat. In manchen Gegenden der USA ist es besser, die Tür gleich offen zu lassen. Wenn jemand rein will, ist hinterher wenigstens die Tür noch heile.
Ben B. schrieb: > So denn, ich glaube ich habe die AlarmSau soweit erstmal fertig Glaube ich nicht. Das ist doch dein Lebenswerk :-)
Ja da könntest Du Recht haben. Ich hatte auch drüber nachgedacht, ob ich die CMA-Sternchen direkt selbst an den Satz dran mache.
Beitrag #5721378 wurde von einem Moderator gelöscht.
Beitrag #5721392 wurde von einem Moderator gelöscht.
c-hater schrieb: > Es ist nämlich relativ leicht, ein System hinter den Zufallszahlen so zu > verstecken, dass es allein mit statistischen Methoden im Output des RNG > praktisch nicht nachweisbar ist. Stichwort: AES-Verschlüsselung mit geheimem Schlüssel.
Absolute Sicherheit gibts sowieso nicht. Aber es macht Spaß, zu versuchen, möglichst nahe dranzukommen. Erst recht bei einem Hobby-Projekt. Und ich finde es auch immer recht schade, bzw. weiß gar nicht was ich davon halten soll, wenn jemand sowas entwickelt, bei seiner eigenen Konstruktion eine Schwachstelle findet und dann nicht probiert, die zu schließen. Wegen der Vermeidung von Wiederholungen beim Zufallszahlengenerator: Wenn ich was baue, was den Zufall aus physikalischen Komponenten bezieht, kann ich den Startwert beliebig oft neu setzen. Bei der Alarmanlage reichen vermutlich schon Stunden, damit niemand eine Wiederholung feststellt. Ich kann ja auch bestimmte Parameter auf beiden Controllern nutzen, kann z.B. die Tastenanschläge zählen und mit in das Paket reinpacken... oder sonstewas. Bei AES muss ich sowieso den kompletten Block übertragen, obwohl ich nur ein einzelnes Byte wirklich brauche. Dann liefern verschiedene Startwerte verschiedenen Output, einfach schon aufgrund der Verschlüsselung. Das wäre dann wieder so sicher wie die Flash- oder EEPROM-Daten im anderen Thread. Das würde reichen, da ein Abhandenkommen von auch nur einem der beiden Controller die Daten darin unbrauchbar macht. Wenn man's richtig macht, sind alle Codes hinterher geändert und die neue Anlage mit den alten Codes nicht angreifbar. Und letztlich finde ich auch lustig zu sehen, wie gut sowas funktionieren kann. Wenn mir am Anfang jemand gesagt hätte, das Ding soll scharfgeschaltet maximal 1W Strom an der Steckdose brauchen, hätte ich ihm einen Vogel gezeigt. Naja, das Ding braucht mit 4 testweise beschalteten Alarmschleifen nur 0,7W an der Steckdose... hätte nie gedacht, daß man das mit Hobby-Mitteln erreichen kann.
c-hater schrieb: > Ben B. schrieb: > >> STM32 nur als Zufallszahlengenerator ... >> und da unterstellt ihr mir Overkill? > > Zumal jeder Nachweis fehlt, dass dieser RNG wirklich zufällige Werte > liefert. Immerhin schreibt ST in der AN4230 wie man ihn testen könnte https://www.st.com/content/ccc/resource/technical/document/application_note/4a/6a/82/05/8e/9e/4e/94/DM00073853.pdf/files/DM00073853.pdf/jcr:content/translations/en.DM00073853.pdf > Es ist nämlich relativ leicht, ein System hinter den Zufallszahlen so zu > verstecken, dass es allein mit statistischen Methoden im Output des RNG > praktisch nicht nachweisbar ist. Dann ist der Output doch zufällig genug? Für Alarmanlagen?
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.