Schlüssel erzeugen

Hallo!

Ich habe eine Chipkarte, welche eine eindeutige, 32bit breite Chipkartennummer hat.
Nun sollen die verschlüsselten Daten auf der Karte mit einem 128bit Schlüssel verschlüsselt werden, welcher sich aus der Chipkartennummer generien lässt.

UINT32 chipNr=karte->GetNr();

UINT32 key[4];
key[0]=chipNr;
key[1]=chipNr;
key[2]=chipNr;
key[3]=chipNr;

Bringt es etwas, wenn ich die ChipkartenNummer für den Schlüssel etwas verändere, also so in der Art:

UINT32 chipNr=karte->GetNr();

UINT32 key[4];
key[0]=(chipNr+13)*2;
key[1]=(chipNr-12456)*3;
key[2]=(chipNr+5)*10;
key[3]=(chipNr-555555)*11;

Oder bringt das bezüglich Sicherheit nichts?

Christoph

Das bringt alles nichts, weil du so in jedem Fall effektiv einen 32-Bit-Schlüssel hast, den man sehr leicht per brute force ermitteln kann.

Christoph schrieb:

Das bringt alles nichts, weil du so in jedem Fall effektiv einen 32-Bit-Schlüssel hast, den man sehr leicht per brute force ermitteln kann.

ok, also besser einmal die 32 bit Nummer verwenden, und den Rest mit einem anderen Schlüssel auffüllen, also so in der Art:

UINT32 key[4];
key[0]=chipNr;
key[1]=12345676;
key[2]=987654;
key[3]=23456;

SeppJ

Das sind immer noch 32 Bit Information. Es gibt keine wundersame Informationsvermehrung.

SeppJ schrieb:

Das sind immer noch 32 Bit Information. Es gibt keine wundersame Informationsvermehrung.

naja, die Alternative ist, dass ich alle 4 UINT32 Werte auf einen konstanten Wert setze. Schlüssel wäre dann eben eine konstante Bytefolge.
Es ist grundsätzlich kein Problem, wenn alle Karten mit dem gleichen Schlüssel verschlüsselt sind. Es ist halt noch eine Zusatzsicherheit, wenn man in den Schlüssel auch noch die Nummer mit reinzieht.

Die Kartennummer ist die einzige "dynamische" Information, die ich in die Schlüsselgenerierung einbeziehen kann. Und die Nummer ist eben ein UINT32, das ist hardware mäßig vorgegeben.

SeppJ

xcxcyxcyc schrieb:

Es ist halt noch eine Zusatzsicherheit

Nein, ist es nicht.

Die Kartennummer ist die einzige "dynamische" Information, die ich in die Schlüsselgenerierung einbeziehen kann. Und die Nummer ist eben ein UINT32, das ist hardware mäßig vorgegeben.

Dann ist das eben so. Aber du kannst nichts tun, um es sicherer zu machen. Eigentlich sollte das ganze Verfahren an sich unsicher sein, da, wenn ich das richtig verstehe, die Kartennummer doch auf der Karte mit gespeichert ist, oder? Dann wäre das ja völlig sinnlos. Wie ein verschlüsselter Brief mit Dekodiertabelle im gleichen Umschlag. Das schützt ja wirklich nur vor versehentlichem Lesen.

Bitte ein Bit

@xcxcyxcyc:
Dein Verfahren basiert darauf das es geheim bleibt. Und das ist einfach nicht gegeben.

Sobald dein System interresant wird, wird jeder deinen Chip auslesen und die Daten analysieren. Und dann weis ein jeder dein Verschlüsselungssystem inklusive Schlüsselgenerierung.

Eine konstante Byte Folge ist da sogar noch schlimmer als deine erste Variante, da ein geknacktes System alle Chipkarten betrifft. Aber die zweite Variante ist auch nicht besser: die Seriennummer eines Chips zu bestimmen ist kein Problem. Im schlimmsten Fall reduziert sich das Knacken darauf alle Seriennumern zwischen 100000001 und 200000000 auszuprobieren. Und das sind schlichtweg Peanuts.

Das ist wahr, Security through obscurity hat schon immer versagt.

die verschlüsselte Kommunikation ist grundsätzlich hardwareseitig implementiert.
Somit kann ich theoretisch meine Daten in Klartext raufschreiben.

Praktisch aber ist bei einem gewünschten Hardwaresystem die Verschlüsselung bereits geknackt (Mifare Classic). Der Kunde besteht aber auf diesem Kartentyp.

Um Skript Kiddies davon abzuhalten, eine Karte mit Geld zu bespielen und dann ein Image zu ziehen und dieses auf eine andere Karte zu spielen, ist es wichtig, dass die Daten in verschlüsselter Form zumindest nicht auf jeder Karte gleich aussehen.
Dadurch, dass ein Teil von der Chipkarten Nummer abhängt, ist zumindest ausgeschlossen, dass jemand mal schnell mit einer App irgendsolche Dinge macht.
Dazu müsste man schon mal die Daten entschlüsseln, mit dem neuen Schlüssel verschlüsseln und dann wieder auf die Karte spielen.

**Welche andere Möglichkeit gibt es denn? Ich bin offen für neue Ideen.**Wie bereits gesagt - der Kartentyp ist vorgegeben und bekannterweise unsicher.
Es gibt die Funktionen Lesen von Blöcken und Schreiben von Blöcken, welche jeweils 16byte groß sind.
Aus Performancegründen muss mit diesen Funktionen aber sparsam umgegangen werden.
Die Anzahl zu sammelnder "Samples" ist aufgrund der Anwendung eher gering. Es wird kaum möglich sein, mit einer Karte mehr als 100 Transaktionen durchzuführen.

vor allem auch die Frage: Ist es überhaupt möglich, mit diesen max. ca. 100 Transaktionen auf den Schlüssel + Verschlüsselungsalgorithmus zu kommen?
Wenn ja, wie?
Es werden geschätzt ca. 1000-2000 Karten in Umlauf kommen.

Vor allem liegen die entschlüsselten Daten ja auch nur als Bitstrom mit eingefügten Zufallszahlen vor, sodass man erstmal merken muss, dass es sich bei den Daten jetzt um die entschlüsselten Daten handelt.
Die mit dem richtigen Schlüssel entschlüssten Daten sehen nicht viel anders aus als die mit dem falschen Schlüssel entschlüsstelten Daten.

SeppJ

Mehr als ein Scriptkiddieschutz ist mit den gegebenen Bedingungen einfach nicht drin. Wenn der Feind der Besitzer der Karte selbst ist, nützt ja nicht einmal ein Passwort. Ein etwas begabteres Scriptkiddie lacht über diese Pseudosicherheit und lädt einmal viel Geld auf die Karte, speichert das zugehörige Datenmuster und nutzt die Karte nur für sich selbst. Braucht man Geld, spielt man das alte Muster wieder auf. Falls die Karten mit einem Namen verbunden sind, dann stiehlt man einmalig eine Karte. Außerdem verkauft man das Gelddruckgeheimnis noch für ein paar Tacken an den interessierten Laien, denn mit einer Anleitung braucht man nicht einmal Scriptkiddie sein, um die Methode nach zu machen.

Eine ganz andere Möglichkeit wäre, dass nicht die Karte die Daten speichert, sondern einen Schlüssel und das System die Daten online speichert. Dafür bräuchten alle Terminals ein Verbindung zum Server. Die Karte dient dann als Ausweis für die Daten im Nutzerkonto, das geschützt auf dem Server liegt. Sofern der Schlüssel auf der Karte noch durch ein Passwort gesichert ist, nützt nicht einmal eine gestohlene Karte ohne Passwort. Das wäre dann so ungefähr das System der EC-Karte. Entsprechend aufwändig, aber halbwegs sicher. Natürlich ebenso anfällig gegen die bekannten Attacken auf EC-Karten (manipulierte Terminals), aber das ist schon ein sehr großer Schritt über Scriptkiddie und benötigt organisierte Bandenkriminalität zur Durchführung. Je nach Einsatzzweck lohnt sich das dann nicht.

cooky451

Was wird denn überhaupt genau verschlüsselt? Wie viel Geld auf der Karte ist?

B4ndit

Speicher doch einfach die Einheiten des Geldes als eindeutige Nummer einmal auf die Karte und einmal auf den Server. Diese Nummer wird auf dem Server raus gelöscht wenn abgebucht wurde und somit ist diese Nummer nur exakt einmal gültig. Wenn die Nummer geklaut wird, ist sie halt weg, aber kann trotzdem nur einmal gebucht werden. Es ist dann auch egal, ob sie zusätzlich noch einmal verschlüsselt auf der Karte ist, Sie halt nur einmal benutzbar, von dem der sie als erster einsetzt.

Oder geht so was mit deinem System gar nicht?

Christoph

SeppJ schrieb:

Eine ganz andere Möglichkeit wäre, dass nicht die Karte die Daten speichert, sondern einen Schlüssel und das System die Daten online speichert. Dafür bräuchten alle Terminals ein Verbindung zum Server. Die Karte dient dann als Ausweis für die Daten im Nutzerkonto, das geschützt auf dem Server liegt.

Mit Chip-Karten, also Intelligenz in der Karte selbst, sollten diese ganzen Angriffe unmöglich werden, vorausgesetzt es ist ordentlich implementiert. Dann bleibt höchstens noch Seitenkanäle ausnutzen, z.B. den Chip aufätzen und mit dem Mikroskop untersuchen oder ähnliches. Und selbst dann ist das schlimmste, was passieren kann, dass jemand eine Karte kopieren kann. Es findet dabei aber keine Geld-Verdopplung statt, weil auf dem Server zu jeder Zeit der Geldbetrag jeder Karte gespeichert ist.

Dafür gibt es aber schon fertige Systeme. Oft haben die einen RFID-Chip, weil das für den Nutzer einfach deutlich praktischer ist und beim Bezahlen viel schneller geht, weil man die Karte nicht aus dem Portmonee holen muss. Ohne ordentliches Kryptografie-Wissen seh ich aber keine Chance, das korrekt zu implementieren. Auch größere Firmen haben schon Probleme gehabt, sowas hinzubekommen, siehe https://en.wikipedia.org/wiki/MIFARE#Security_of_MIFARE_Classic.2C_MIFARE_DESFire_and_MIFARE_Ultralight .

Die U-Bahn- und Eisenbahn-Fahrkarten in manchen Großstädten oder teilweise ganzen Ländern (Japan) funktionieren auf die Weise; in Deutschland seh ich das oft bei Mensa-Karten. Die Mensa-Karten an meiner Uni waren ältere Mifare-Karten und mussten (zu hohen Kosten) ausgetauscht werden, nachdem die im Wikipedia-Artikel genannten Lücken aufgetaucht ist.

es ist nicht garantiert, dass ständig eine Online Verbindung vorhanden ist.
Und es darf hier auch zu keinen Wartezeiten kommen, die Buchung muss in 1s erledigt sein.
Es ist aber garantiert, dass "ab und zu" (auf jeden Fall mehrmals am Tag) eine Verbindung vorhanden ist.

Jedenfalls ist die Möglichkeit vorhanden, im Backoffice System die Buchungen zu prüfen. Falls es tatsächlich nicht nachvollziehbare Buchungen gibt, könnte man überlegen, Blacklists zu versenden. Denn zumindest die Chipkartennummer ist fix in der Karte integriert und lässt sich nicht verändern. Auch lässt sich prüfen, ob die Karte tatsächlich vom Unternehmen ausgegeben wurde. Alle anderen Karten kann man von vornherein mal sperren.

Danke für den Input, werde das mit den zuständigen Leuten nochmal besprechen.

Christoph schrieb:

SeppJ schrieb:

Eine ganz andere Möglichkeit wäre, dass nicht die Karte die Daten speichert, sondern einen Schlüssel und das System die Daten online speichert. Dafür bräuchten alle Terminals ein Verbindung zum Server. Die Karte dient dann als Ausweis für die Daten im Nutzerkonto, das geschützt auf dem Server liegt.

Mit Chip-Karten, also Intelligenz in der Karte selbst, sollten diese ganzen Angriffe unmöglich werden, vorausgesetzt es ist ordentlich implementiert. Dann bleibt höchstens noch Seitenkanäle ausnutzen, z.B. den Chip aufätzen und mit dem Mikroskop untersuchen oder ähnliches. Und selbst dann ist das schlimmste, was passieren kann, dass jemand eine Karte kopieren kann. Es findet dabei aber keine Geld-Verdopplung statt, weil auf dem Server zu jeder Zeit der Geldbetrag jeder Karte gespeichert ist.

Dafür gibt es aber schon fertige Systeme. Oft haben die einen RFID-Chip, weil das für den Nutzer einfach deutlich praktischer ist und beim Bezahlen viel schneller geht, weil man die Karte nicht aus dem Portmonee holen muss. Ohne ordentliches Kryptografie-Wissen seh ich aber keine Chance, das korrekt zu implementieren. Auch größere Firmen haben schon Probleme gehabt, sowas hinzubekommen, siehe https://en.wikipedia.org/wiki/MIFARE#Security_of_MIFARE_Classic.2C_MIFARE_DESFire_and_MIFARE_Ultralight .

Die U-Bahn- und Eisenbahn-Fahrkarten in manchen Großstädten oder teilweise ganzen Ländern (Japan) funktionieren auf die Weise; in Deutschland seh ich das oft bei Mensa-Karten. Die Mensa-Karten an meiner Uni waren ältere Mifare-Karten und mussten (zu hohen Kosten) ausgetauscht werden, nachdem die im Wikipedia-Artikel genannten Lücken aufgetaucht ist.

wir stellen nicht die Karten selbst her - sondern müssen eben genau die von dir genannte, unsichere Mifare Karte verwenden.