Wenn sie nicht fix ist und der Programmierer nicht vollkommen behindert war, reicht ein Sample nicht aus, und selbst 1 Million Samples reichen ziemlich sicher nicht zum Erraten eines Challenge-Response-Verfahrens und seiner Parameter aus.
Was sind das denn für hochgeheime Geräte? Vielleicht gibt es in den unendlichen Weiten der allwissenden Müllhalde schon Infos dazu?!
Ich habe leider z.Zt. nur den Mitschnitt einer einzelnen Sitzung und war eigentlich auf der Suche nach den niedrig hängenden Früchten:
es gibt ja Leute, die durch bloßes Hingucken sehen, dass hier offensichtlich was addiert, verodert, invertiert wurde.
Dass ein einzelnes Sample für komplexere Berechnungen nicht reicht ist mir schon klar. Aber die erwarte ich eigentlich gar nicht ...
Bisher bin ich davon ausgegangen, das da kein Schlüssel wie beim challenge-response verfahren involviert ist.
Eher dachte ich, dass das eine für uCs schnelle und ressourcensparende Berechnung ist.
Bei ähnlich gelagerten Problemen war das nur eine Addition der challengebytes mit ignoriertem Übertrag, manchmal nach vorherigem Invertieren oder nur byteweises Verodern.
besten Dank für die Links.
Speziell im letzten Link wurde ja genau das bestätigt, was auch meine bisherige Erfahrung war:
Shiften, rotieren etc. sind bei derartigen Problemen absolut üblich und mit Phantasie, Intuition und Erfahrung kommt man da auch zu Ergebnissen.
Die Kollegen hier, die sofort auf dem "... geht nicht ..." Trip waren, haben garantiert hier keine hands-on Erfahrung.
Dass es Möglichkeiten zur Authentifizierung gibt, an denen man sich die Zähne ausbeisst weiß ich selber. Aber in den wenigsten Fällen geht es um Fort Knox oder den Großrechner vom CIA. Jede Authentifizierung muss in einem vernünftigen Verhältnis zur vorhandenen Rechenkapazität und Speicherplatz stehen und wartbar sein. Entwickler sind auch nur Menschen und wie gut Abschreckung durch die niedrige Frustrationstoleranz von Angreifern funktioniert, sehen wir in diesem thread ...
Die Kollegen hier, die sofort auf dem "... geht nicht ..." Trip waren,
haben garantiert hier keine hands-on Erfahrung.
Du hast offensichtlich keine Ahnung von der Thematik.
Beispiel wie man so einen Challenge-Response mit minimalem Aufwand bauen könnte wäre TEA oder XTEA. Die brauchen jeweils unter 10 Zeilen Code für die Implementierung und keine zusätzlichen Daten-Tabellen. Die Schlüssellänge ist 128 Bits. Also Challenge damit verschlüsseln, vom Ergebnis 3 Bytes auswählen, fertig. Der 128 Bit Schlüssel bestimmt das Ergebnis. Viel Spaß beim Erraten des Schlüssels anhand eines Beispiels.
Die Kollegen hier, die sofort auf dem "... geht nicht ..." Trip waren,
haben garantiert hier keine hands-on Erfahrung.
Du hast offensichtlich keine Ahnung von der Thematik.
+1
Mal ein simples Beispiel, warum dein Unterfangen anhand der Datenbasis etwas - hm - ambitioniert ist:
request (x) : 2
response (y) : 4
Da fallen mir aus dem Stand diverse Funktionen/Algorithmen ein, z.B:
y=x+2
y=x*2
y=x^2
y=2^x
y=(3^x) mod 5
...
So, und welcher ist jetzt "der Richtige"?
Hallo, 7byte challange ist meistens DES Verschluesselung.
Wird noch sehr selten genutzt.
Hier ein Codebeispiel, sei es für challange und response
Im Prinzip aus einer entropy, im konkreten Fall mehrere Durchläufe von
den unteren Bits des Timers bei WDT Timeout, also Laufzeitaenderungen
beim WDT sowie Temeperaturwerte (8bit überlauf des Timers) welcher Temperaturabhängig ist.
Response verwendet den 56bit encryption key und wendet ihn auf ein 64bit
UID an , hier triple des. Der checksum entscheidet welcher mittlere Key
bei triple DES verwendet wird, es stehen 10 zur Auswahl.
Das Resultat wird auf 7byte reduziert und dies ist der Key für den
112bit des_hash, welcher aud dem 8byte PID generiert wird.
Aus diesem Hash werden 3bytes ausgesucht, zwei Flags invertieren oder
ändern MSB/LSB und dann wird noch ein xor mit einem 16bit Wert gemacht.
Diese generierte Zahl wird zurüchgeschickt und im Empfänger wird sei es
das Timing sowie das Resultat verifiziert und der Result des Ergebnis
mit der xor Funktion gecheckt.
Es gibt aber zig Variationen, wie auch einfache lookuptable mit 32 byte
und es wird einfach die Summe eines irgendein 8bit checksum bei jedem Zeichen susammengezahlt und dies mit der summe der einzelnen Lookups multipliziert und zusammengezahlt. Bit6 heisst, Wert +64 und
bit 7 heisst "resultat ist 0-value" . Bei bit 5 wird der Tabellenindex von hinten gelesen. Resultat wird dann mit je nach checksum 6 unterschiedlichen Fixwerten verodert. Dies z.B. bei einem 6pin PIC mit einem sehr kleinen Speicher und eeprom welches auch Features flags sowie Serialnummer beinhaltet und pin/puk/... .