Liebe Gemeinde, ich habe 2 über CAN verbundene Geräte. Zu Beginn einer Sitzung authentifizieren die sich folgendermaßen: request (7 byte): 15 2F 19 43 22 B4 0B reponse (3 byte): 38 75 EF Hat irgendein Mathegott eine Idee, wie man vom Einen aufs Andere kommt?
Wenn die Sequenz fix ist, ahme sie nach. 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?!
Jöt Z. schrieb: > Hat irgendein Mathegott eine Idee, wie man vom Einen aufs Andere kommt? Wenn man eine Formel angibt, um vom einen auf das andere in diesem einen Beispiel zu kommen, wird dir das exakt gar nichts bringen.
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 ...
ich habe das Thema auch gerade. mein Ansatz ist die Firmware zu analysieren
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. Also eher Authentifizierung durch Obskurität ...
Moin, Und wenn du noch soviel vermutest und erzaehlst, was es sein koennte: Ohne deutlich groessere Anzahl von Samples kann das nix werden. Gruss WK
Beitrag #7510392 wurde von einem Moderator gelöscht.
https://www.mdpi.com/1424-8220/20/8/2364 https://security.stackexchange.com/questions/261542/is-the-seed-and-key-challenge-response-used-in-automotive-security-really-secure http://nefariousmotorsports.com/forum/index.php?topic=4983.0 nach dem durchlesen weitere Fragen stellen.
Rüdiger, 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 ...
Jöt Z. schrieb: > Jede Authentifizierung muss in einem vernünftigen Verhältnis zur > vorhandenen Rechenkapazität und Speicherplatz stehen und wartbar sein. Irgendwelche 128 oder 256 Bit zu verknoten, schafft fast jeder uC. Den Rechenaufwand hat derjenige, der das per Brülute Force knacken will.
Jöt Z. schrieb: > > 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.
:
Bearbeitet durch User
Moin, Dieter S. schrieb: >> >> 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"? Gruss WK
Jöt Z. schrieb: > Die Kollegen hier, die sofort auf dem "... geht nicht ..." Trip waren, > haben garantiert hier keine hands-on Erfahrung. Das ist ja an Arroganz kaum mehr zu überbieten. Dir ist schon klar, dass du EIN Beispiel gegeben hast. DAS wurde kritisiert.
Beitrag #7510691 wurde vom Autor gelöscht.
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/... .
1 | char* |
2 | challenge() { // return 7byte
|
3 | byte i=0,j,k; word t; |
4 | j=4; memcpy(tmp+i,&entropy,j); i+=j; |
5 | eeread(EE_CNT,&t,2); t++; eewrite(EE_CNT,&t,2); |
6 | j=2; memcpy(tmp+i,&t,j); i+=j; |
7 | eeread(EE_LFR,&t,2); t=lfr(t); eewrite(EE_CNT,&t,2); |
8 | j=2; memcpy(tmp+i,&t,j); i+=j; |
9 | des_enc(tmp,tmp,DES_KEY); |
10 | for(k=i=7,j=tmp[i];i--;k^=j) // some randomizing |
11 | j+=tmp[j],tmp[j]^=k; |
12 | tmp[7]=0; |
13 | return tmp; |
14 | } |
15 | |
16 | byte |
17 | xor(void*out, void*in, byte size) { // return 0 if all resulting bits are zero
|
18 | byte i; |
19 | for(i=0;size--;i|=out[size]) out[size]^=in[size]; |
20 | return i; |
21 | } |
22 | |
23 | void |
24 | tdes(void*out, void*in, void*key1, void*key2, void*key3) {
|
25 | des_enc(out,in,key1); |
26 | des_dec(out,out,key2); |
27 | des_enc(out,out,key3); |
28 | } |
29 | |
30 | void |
31 | response(char*dat) { // from 7byte key challange it return 3byte response
|
32 | byte t,k,i,j; dword r=0,ret=0; |
33 | des_key(key,dat); |
34 | for(k=8,i=0,j=7;k--; j^=i) i+=key[k]; k>>=3; if(k>=10) k-=10; k<<=3; // checksum return value from 0-9 multiplied by 8 for indexing |
35 | memcpy_P(tmp+16,P_UID,8); |
36 | memcpy_P(tmp+8,P_KEYS+k,8); |
37 | tdes(tmp,tmp+16,key,tmp+8,key); |
38 | xor(tmp,tmp+16,8); |
39 | for(k=i=7,j=tmp[i];i--;k^=j) // some randomizing |
40 | j+=tmp[i],tmp[i]^=k; |
41 | for(j=i=0;i<7;i++) // shift |
42 | j=!!tmp[i]&0x80, tmp[i]<<=1, tmp[i]+=j; |
43 | des_key(key,tmp); |
44 | memcpy_P(tmp+8,P_PID,8); |
45 | des_enc(tmp+16,tmp+8,key); xor(tmp+16,tmp+8,8); |
46 | *tmp++; |
47 | des_key(key,tmp); |
48 | des_enc(tmp+24,tmp+8,key); xor(tmp+24,tmp+8,8); |
49 | t=tmp[13]; i=t>>2; for(j=24;j--;r+=bit(tmp,128+i++)) r<<=1; |
50 | if(t&0x40) r^=0xfff; if(r&0x80) |
51 | for(j=24;j--;r>>=1) t=!!r&1,res<<=1,res+=t; else res=r; |
52 | memcpy(&r,tmp+11,2); res^=r; r=0; |
53 | #ifdef EE_FLAGS |
54 | eeread(EE_FLAGS,&r+2,1); r&=0x550000; res^=r; |
55 | #endif |
56 | return res; |
57 | } |
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.