Hi zusammen, ich vertreibe ein Embedded System inkl. Software. In einer neuen Version möchte ich gerne Softwareoptionen einbauen, die nur per Aktivierungscode freigeschaltet werden können. Jede meiner Hardware hat eine eindeutige Seriennummer. Der Aktivierungscode soll jeweils nur für ein Gerät einsetzbar sein. Ich stell mir das so vor: Kunde schickt mir die Seriennummer. Ich schicke Ihm einen passenden Aktivierungscode. Er kann den Code eingeben und die Option freischalten. Mein Problem ist der Algorithmus, wie der Aktivierungscode berechnet werden kann. Weil im Prinzip muss bei mir und in der Firmware das gleiche passieren. Hat jemand eine Idee wie ein solcher Algorithmus aussehen könnte? Gruß Miu
Da gibts diverse Möglichkeiten: - einen individuellen Aktivierungscode zusätzlich zur Seriennummer in jedem Gerät - Hashverfahren mit salt - symmetrische oder asymmetrische Kryptographie Welchen Aufwand willst du betreiben?
Ich schätze mal es sollte einfaher sein mit einem Hash zu arbeiten Probleme an dem Hash, bzw symmetrischen Verfahren: wird auf irgendeine Art und Weise der Key geknackt, dann ist es hinüber mit dem System Asymmetrisches Verschlüsseln könnte für dich da sehr gut sein, so könntest du den Key einfach verifizieren, dass er von dir kommt. Ansonsten, einfach aber aufwendig: Jeder Chip kriegt in der Firmware den Code eingespeichert, und es gibt eine direkte Kopplung Seriennummer+Code+Funktion, aber immer nur eine, und der Code wird zufällig generiert, bei Bestellung muss der nur aus der DB- geholt werden und fertig, das Verfahren sollte auf dem embedded System am wenigsten Platz/Ressourcen verbrauchen, benötigt jedoch unter Umständen für jedes Board ein eigenes Hex-File! mfg
Angenommen, es gibt für Seriennummer s, die freigeschalteten Optionen o und eine nur dir bekannten Kennung k jeweils eine Bytefolge. Außerdem eventuell noch ein Schlüssel i, der individuell nur für das eine System gilt und das im System hinterlegt ist und natürlich irgendwo bei dir auf dem Rechner. Dann könntest du dir daraus einen Freischaltcode f erzeugen. Zu s: natürlich eine individuelle Bytefolge pro System, die dem Kunden bekannt sein darf und dir und deinem System bekannt sein muss. Zu o: eine Zeichenfolge, aus der für dich bzw. das System hervorgeht, welche Optionen gerade an sind. Also ein von dir festzulegendes Format der eigentlichen Informationen. Nur dir bekannt und dem programmierten System natürlich. Es muss zur Sicherung auch eine Prüfsumme enthalten (z.B. CRC oder zumindest halt eine Summe der restlichen Byte). Zu k: Nur dir und deinem System intern bekannt, kann für alle Systeme gleich gewählt werden. Zu i: Kann auch entfallen, verhindert aber, daß k ermittelt werden kann, indem verschiedene Freischaltcodes verschiedener Controller verglichen werden. Ist dem System intern bekannt, sowie dir (zusammen mit der Seriennummer gespeichert). Für alle folgenden Rechnungen werden die Bytefolgen jeweils auf die gleiche Länge gebracht, z.B. durch Auffüllen mit Leerzeichen auf die grösste Länge. k und i sollten natürlich bereits so lange sein. Wenn du dich mit dem Kunden über eine neue Option einig bist, erstellst du o aus den aktuellen Optionen incl. Checksumme und berechnest f: f = s XOR k XOR o XOR i (die Reihenfolge ist egal). [Gemeint ist damit, dass das erste Byte von f berechnet wird als erstes Byte von s XOR erstes Byte von k XOR erstes Byte von o XOR erstes Byte von i, dann zweites Byte von f = zweites Byte von s XOR zweites Byte von k ...] Der Kunde bringt dieses f in das System, wie auch immer. Dort wird berechnet: o = s XOR k XOR i XOR f Das funktioniert, weil XOR umkehrbar ist (siehe RAID-3 und RAID-5 zum Wiederherstellen verlorener Partionen). Im System wird dann die Prüfsumme kontrolliert, und die neuen Optionen gespeichert, wenn die Summe ok ist. Das bietet: - Kunde kann sich keine Optionen selbst ausdenken - Mit einem f für ein System kann kein anderes geschaltet werden (dank i). - Aus mehreren f verschiedener Systeme mit bekannten Optionen kann nicht auf andere Systeme geschlossen werden, solange i verwendet wird. - Wenn der Kunde mit einem freigeschalteten Satz Optionen scheitert (Programmfehler o.ä.), kann er sicher mit einem alten f (falls du ihm das mal hast zukommen lassen) zumindest den alten Zustand herstellen, ohne dich erreichen zu müssen. Wenn i verwendet wird, kann k entfallen.
Danke für die vielen Anregungen. @Tom Ekman Der Aufwand soll sich in Grenzen halten. Wenn ich mehr Zeit (damit mehr Geld) brauche um ein sicheres System hinzubekommen, als ich später damit verdiene, dann macht das Ganze keinen Sinn. Ein asymmetrisches Kryptosystem gefällt mir im Moment von der Idee her am besten. Mir fehlt ein bißchen die Erfahrung damit, was es bedeutet so etwas zu implementieren. @Marcus B. Von der Möglichkeit ein individualles Hex-File einzurichten halte ich nicht viel. Ich glaube der Verwaltungsaufwand steigt hierbei deutlich und die Nachverfolgbarkeit leidet wahrscheinlich ebenso. Trotzdem vielen Dank für die Idee... @Klaus Wachtler Vielen Dank für die ausführliche Beschreibung deiner Idee. Leider glaube ich, dass diese Möglichkeit doch zu einfach ist. Ein einfaches XOR ist mir zu leicht berechenbar... Außerdem kann ich mit dieser Methode doch nicht sicherstellen, dass nicht eine falsche Option freigeschaltet werden kann, wenn ein falscher Schlüssel eingeben wird. @alle Ich werde versuchen mich ein wenig näher mit einem asymmetrischen Verfahren zu beschäftigen. Das ganze hätte für mich den Charme, dass ich an der Hardware außer der Seriennummer keine weitere individuelle Nummer brauchen würde... Vielen Dank nochmal
Miu schrieb: > @Klaus Wachtler > Vielen Dank für die ausführliche Beschreibung deiner Idee. Leider glaube > ich, dass diese Möglichkeit doch zu einfach ist. Ein einfaches XOR ist > mir zu leicht berechenbar... Daher i > > Außerdem kann ich mit dieser Methode doch nicht sicherstellen, dass > nicht eine falsche Option freigeschaltet werden kann, wenn ein falscher > Schlüssel eingeben wird. Dafür die Prüfsumme
Vielleicht zur Klarstellung: Eine Verschlüsselung wird nicht davon sicherer, daß sie kompliziert zu berechnen ist. Mein Vorschlag ist sogar absolut sicher, solange i bzw. k nicht bekannt werden (also z.B. nicht aus dem Flash ausgelesen werden können, aber dann ist jedes Verfahren tot). Prinzipiell ist jede derartige Verschlüsselung sicher, solange die Schlüssellänge so groß ist wie die Information. Den ganzen Zirkus mit den üblichen Verschlüsselungen AES, DES, ... muß man sich erst antun, wenn man mit Schlüsseln auskommen will oder muß, die kürzer sind als die Information. Da es hier aber keinen Grund gibt, mit wenigen Bits Schlüssel irgendwelche Megabytes Daten zu kodieren, ist das unnötiger Aufwand, der nur neue Löcher aufreisst.
> Ich werde versuchen mich ein wenig näher mit einem asymmetrischen > Verfahren zu beschäftigen. Das ganze hätte für mich den Charme, dass ich > an der Hardware außer der Seriennummer keine weitere individuelle Nummer > brauchen würde... Du weisst hoffentlich, dass, wenn du eine gängiges Verfahren wie RSA verwendest, du meist mit sehr großen Zahlen (und zwar wirklich großen Zahlen für Mikrocontrollerverhältnisse) arbeiten musst um tatsächlich mehr Sicherheit zu generieren. Wie wäre es den ganz einfach mit: Aktivierungscode = md5(Seriennummer + geheimer Schlüssel) Vorteil: - Durch den md5 Hash kann der Schlüssel nicht eindeutig zurückberechnet werden - md5 ist einfach umzusetzen - mit jeder neuen Versionsnummer kannst du auch einen neuen geheimen Schlüssel verwenden falls doch einmal einer öffentlich wird (im Extremfall sogar für jede Seriennummer)
Ich halte den Vorschlag von Marcus B. für den besten: Wenn Du sowieso schon eine eindeutige Seriennumer in jeder Hardware hast (im EEPROM???), dann kannst Du doch auch noch die individuellen Freischaltcodes dazubrennen und die passende Liste in Deiner Kundendatenbank vorhalten.
Klaus Wachtler schrieb: > Vielleicht zur Klarstellung: > Eine Verschlüsselung wird nicht davon sicherer, daß sie kompliziert > zu berechnen ist. > > Mein Vorschlag ist sogar absolut sicher, solange i bzw. k nicht > bekannt werden (also z.B. nicht aus dem Flash ausgelesen werden > können, aber dann ist jedes Verfahren tot). Nein, Stichwort Known-Plaintext: f = s XOR k XOR o XOR i Angenommen man ahnt das der Algorithmus s und o braucht und hat einmal die Basis-Optionen (o=0). Bekannt sind somit f, s und o, k XOR i ist konstant und somit berechenbar. Marcus B. schrieb: > Probleme an dem Hash, bzw symmetrischen Verfahren: > wird auf irgendeine Art und Weise der Key geknackt, dann ist es hinüber > mit dem System Man kann auch mit jedem Ändern der Optionen einen neuen, geheimen Schlüssel übermitteln. Müsste dann aber bereits eingegebene Aktivierungscode speichern.
Und woher soll jemand f bekommen für o=0? Aber eigentlich auch egal.
Klaus Wachtler schrieb: > Mein Vorschlag ist sogar absolut sicher, solange i bzw. k nicht > bekannt werden (also z.B. nicht aus dem Flash ausgelesen werden > können, aber dann ist jedes Verfahren tot). Nö, es hat sogar eine recht offensichtliche Schwachstelle. Mal angenommen ich habe zwei gleiche Geräte, mit den Seriennummern s1 und s2 und den "Geheimzahlen" i1 und i2. Jetzt kaufe ich für das erste Gerät zwei verschiedene Features o1 und o2, und erhalte die Freischaltcodes
und
Jetzt kann ich rechnen:
Anschliessend kaufe ich das Feature o1 auch für mein zweites Gerät, erhalte den Freischaltcode
und kann rechnen
Ich erhalte also den Freischaltcode für o2 für mein zweites Gerät. Ergo: wenn ich mehrere Geräte habe, muss ich nur für eines der Geräte alle Features kaufen, die ich haben möchte. Für alle weiteren Geräte brauche ich immer nur noch jeweils ein Feature kaufen (zweckmässigerweise das billigste), und kann mir dann Freischaltcodes für die anderen Features selbst berechnen. Natürlich kann man sich auch mit mehreren zusammentun, wenn man noch andere Benutzer des Gerätes kennt ;-) Andreas
Bitte 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.