Mit DEC ein record verschlüsseln

[Roaster]

Hi,

ich möchte mit Hilfe des DEC von Hagen ein record mit folgendem Aufbau verschlüsseln:

Delphi-Quellcode:

  TLicenseString = array [0..255] of byte;

  TLicenseBlock = packed record
    Code : TCode;
    ApplicationKey : TKey;
    Modifier : LongInt;
    LicVersionLow   : word;
    LicVersionMid   : word;
    LicVersionHigh   : word;
    LicVersionStr   : TLicenseString;
    RegUserName : TLicenseString;
    RegCompany : TLicenseString;
    VendorName : TLicenseString;
    VendorCompany    : TLicenseString;
  end;

Wie stelle ich dies am besten an?

[Klaus01]

Du könntest den Datensatz in eine Datei schreiben und die Datei verschlüsseln.

Oder Du bringst Dein Record irgendwie in einen Stream.
Mit TStream.WriteBuffer oder ähnlichem.

DEC sollte Methoden zur Verschlüsselung von Dateien und Stream
beinhalten.

Grüße
Klaus

[mkinzler]

Ansonsten müßtest du eine Funktion schreiben, welche den record in einen Stream oder String wandelt und den dann verschlüsseln.

[negaH]

Delphi-Quellcode:

procedure Encode(var Value: TLicenseBlock);
begin
  with TCipher_Rindael.Create do
  try
    Mode := cmCFS8;
    Init(Key);
    Encode(Value, Value, SizeOf(Value)); 
  finally
    Free;
  end;
end;

Das ist der einfachste Weg. Wichtig in deinem Falle ist der Cipher.Mode cmCFS8. Du kannst cmCFB8, cmOFB8, cmCFS8 benutzen. Diese Modis arbeiten auf 8Bit = 1 Byte und verschlüsseln somit einen Datenblock häufiger als die anderen Cipher Modis. Gerade bei kurzen und sehr sicherheits relevanten Daten wie Lizenzschlüsseln, Passwörtern sollte man diese Modis benutzen.

Ich empfehle dir jetzt noch ein par Änderungen an deinem TLicenseBlock:

Delphi-Quellcode:

  TLicenseBlock = packed record
    RandomSalt: array[0..15] of Byte; // <- Zufallsdaten 
    Code : TCode;
    ApplicationKey : TKey;
    Modifier : LongInt;
    LicVersionLow   : word;
    LicVersionMid   : word;
    LicVersionHigh   : word;
    LicVersionStr   : TLicenseString;
    RegUserName : TLicenseString;
    RegCompany : TLicenseString;
    VendorName : TLicenseString;
    VendorCompany    : TLicenseString;
  end;

  TLicenseData = packed record
    PasswordSalt: array[0..15] of Byte; // Zufallssalt fürs Password
    Data: TLicenseBlock;
  end;

uses DECRandom;

procedure Encode(var Value: TLicenseData);
begin
  RandomBuffer(Value.PasswordSalt, SizeOf(Value.PasswordSalt));
  RandomBuffer(Value.Data.RandomSalt, SizeOf(Value.Data.RandomSalt));

  with TCipher_Rindael.Create do
  try
    Mode := cmCFS8;
    Init(THash_SHA1.KDFx(Key, SizeOf(Key), Value.PasswordSalt, SizeOf(Value.PasswordSalt), Cipher.Context.KeySize, TFormat_COPY));
    Encode(Value.Data, Value.Data, SizeOf(Value.Data));
  finally
    Free;
  end;
end;

Mit diesen beiden Änderungen werden effektiv mindestens 2 Angriffe verhindert oder erschwert

1.) Brute Force Attacke auf das Password -> Key. Ein Angreifer kann nun nicht mehr zb. durch Rainbow Tabellen eine effiziente Wörterbuchattacke auf das Password durchführen. Er ist gezwungen eine echte langwierige Brute Force Attacke durchzuführen. Wir schützen also das verwendete Password.

2.) mit den 16 Bytes RandomSalt in deinem Lizenz Block, die ja mit verschlüsselt werden, wird eine Known Plain Text Attacke erschwert bzw. verhindert. Ein Angreifer kann also nicht mehr auf Grund das er den Aufbau deiner Lizenzdaten kennt einen verschl. Lizenzblock knacken. Ohne diese Erweiterung kann er davon ausgehen das zb. im 1 Byte -> Code: TCode nur ganz bestimmte Werte drinnen stehen können. Diese Information würde es ihm ermöglichen seine "Brute Force" Testentschl. zu verifizieren. Mit dem vorgesetzten RandomSalt ist dies nun ausgeschlossen, bzw. die Komplexität dieses Test erhöht sich von 1 zu 1 auf 1 zu 2^(16 * 8 ).

3.) durch einbinden der Unit DECRandom wird ein sogennater YARROW Random Generator eingebunden. Wenn du diesen per RandomSeed(DeineDaten) sicher initialisierst (also nicht reroduzierbar für einen Angreifer) dann ist der Zufallsstrom dieses Generator nicht knackbar (zumindestens nicht so lange SHA1 als Hashfunktion nicht geknackt wurde).
Alle Random?????() Funktion in DECUtils benutzten nach dem Einbinden von DECRanndom() diesen YARROW RNG. Ohne diese Unit wird ein Borland-ähnlicher simpler LCG RNG benutzt, der natürlich unsicher ist.

Mit diesen drei simplen Änderungen kann ich dir garantieren das nur noch eine Brute Force Attacke, also das Durchprobieren aller Schlüssel, der Datenblock zu knacken geht. Alle effizienteren Verfahren sind ausgeschlossen, unter den Annahmen

1.) der Cipher ist sicher -> AES Rijndael
2.) die Hashfunktion ist sicher -> SHA1
3.) die Zufallsfunktion ist sicher -> SHA1 YARROW von Bruce Schneier
4.) das Passwort Key ist sicher -> also im Hirn gespeichert und nicht in der EXE

Da es sich bei diesem Verfahren um eine symmetrische Verschlüsselung handelt hast du das Problem an Punkt 4.) mit dem Schlüsselaustausch. Wenn du das nicht sicher gelösst bekommst ist das ganze Verfahren immer knackbar. Dh. der Angrefer kann immer das Passwort zb. durch Spyware in Erfahrung bringen. Die einzigste Lösung für dieses Problem sind die asymmetrischen Verfahren, genauergesagt die "digitalen Signaturen". Bei diesen Verfahren gibt es 2 getrennte "Operatonen". Einmal die Erzeugung einer digitalen Signatur die einen privaten Schlüssel benötigt. Dieser liegt natürlich nur auf deinem Server und niemals bei deinen Kunden. Die zweite Operation ist die Verifikation einer solchen Signatur. Diese Operation kommt OHNE den privaten Schlüssel aus und wird somit in deine Software zur Verifikation der Lizenz benutzt. Ein Key Generator ist somit ausgeschlossen, wenn wir davon ausgehen können das ein Angreifer NICHT deinen Public Key in deiner EXE austauschen kann.

Fazit: ohne die Grundbedingung das deine EXE in einem sicheren Kontext ausgeführt wird wirst du niemals eine sichere Lizenz hinbekommen !

Gruß Hagen

[Roaster]

Hagen,

perfekt, würde ich sagen. Deine Antwort hat mir sehr weitergeholfen. Kann ich DEC auch für Shareware Programm benutzen, Part I lediglich?

Ein kleines Problem, das ich aber noch nicht gelöst habe, ist, dass ich in meiner Anwendung einen, ich nenn' ihn mal, ApplicationKey (in Form eines bspw. 16 stelligen Byte Codes) speichern muss, der gleichzeitig der Key für die Verschlüsselung und Entschlüsselung ist.

Der User muss ja kein Passwort oder gleiches eingegeben, damit die Lizenz Daten entschlüsselt werden können. Den ApplicationKEy könnte ich natürlich noch mehrmals verschlüsseln, mit irgendwelchen Strings oder Sonstigem, die ich in der Anwendung hinterlege, aber jeder halbwegs bewanderte Cracker wird dies natürlich sofort finden. Ok, ich weiß ja jetzt aus deiner Ausführung von oben, dass ein 100%ig Schutz sowieso nicht besteht, aber man könnte es dem Cracker schon ein wenig erschweren und nicht gerade vereinfachen...

Ich dachte jetzt mehr an eine Variante, der Lizenznehmer muss seinen Namen und Firma, eingeben und ich decrypte dann zusammen mit dem ApplicationKey die Lizenz Daten. Würde sicherlich funktionieren, wenn da nicht noch eine Kleinigkeit wäre, die ich unbedingt so haben möchte:

Ich finde im Internet auf einer der Cracker Seiten eine meiner Lizenzdateien. Diese möchte ich in meinem Lizenz-Schlüssel Generator öffen, entschlüsseln und daraus dann den ursprünglichen Lizenznehmer auslesen.

Dies bedeutet aber, dass ich ja erstmal den Namen und die Firma des Lizenznehmers nicht kenne aber trotzdem in der Lage sein möchte die Lizenzdaten zu entschlüsseln.
Ich benötige so eine Art Master und Public Key Verfahren. Mit Hilfe des Masterkeys müsste ich immer in der Lage sein die Lizenzdatei zu enschlüsseln, nicht aber der User/Cracker, wenn er nicht den genauen Namen und die Firma aus der Lizenzdatei kennt.

Kann ich dies mit DEC programmieren oder benötige ich da noch mehr? Ich möchte jedenfalls nicht während der Entschlüsselung der Lizezdatei auf einen Server im Web zugreifen. Schon allein deswegen nicht, da ich die Datei sporadisch auf Gültigkeit abprüfe und eine Internetverbindung nicht immer gegeben ist.

Danke!

[negaH]

Zitat:

Kann ich DEC auch für Shareware Programm benutzen, Part I lediglich?

Ja, kannst du frei benutzen, ein Hinweis in deiner Aboutbox wäre schön.

Zu deinem anderen Problem:

Was hindert dich daran in deinem Lizenzmanager die Daten des Kunden mit einem weiteren Schlüssel zu verschlüsseln. Dieser Schlüssel ist nur dir bekannt, also in deinem Lizenzmanger gespeichert und verlässt euren Server ja niemals. Diese verschl. Kundendaten werden nun zusammen mit deinem RegKey gespeichert und zum Kunden gesendet. Sollte dieser bösartig sein/ein Cracker und du diesen RegKey im WEB finden so lädst du diesen in deinen Lizenzmanager und entschlüsselt den Kundendatenblock.

Das Problem mit deinem ApplicationKey kanst du niemals sicher lösen wenn du auf reine Software als Schutz aufbaust. Selbst wenn du Public Key Kryptographie benutzen würdest so könnte ein Cracker einfach deinen Public-ApplicationKey durch einen eigenen austauschen OHNE das er irgendwas an deinem Code hacken müsste (sprich er versucht garnicht deinen Schutz zu deaktivieren).

Die Idee von Zeit zu Zeit die Lizenzen deiner Kunden per INet zu verifizieren ist sehr sinnvoll und defakto die einzigste Möglichkeit für dich ein sicheres System zu bauen das aus reiner Sofwtare besteht. Der Grundgedanke ist es nun das dein INet Server aus Sicht deiner Kunden ja einbruchsicher ist. Ergo kannst du wichtige Schlüssel auch auf diesem Server benutzen die keinem anderen zur Verfügung stehen.

Das funktioniert dann aber nur wenn deine Sofwtare zb. wichtige Anwendungsdaten aus dem INet nachlädt. Dh. der Kunde ist gezwungen von deinem Server Daten nachzuladen die dann natürlich auf den Kunden und seinem RegKey zugeschnitten verschlüsselt wurden. Also nur legal registrierte Kunden können diese wichtigen Daten nachladen.

Bei einem solchen System macht die Anwendung von PublicKey Kryptographie aber wiederum Sinn. Denn nur ein Kunde mit gültigem digital signiertem RegKey kann auch deine Daten aus dem INet saugen. Ein Cracker der diesen Key in deiner Sofwtare ausgetauscht hat wird dagagen keine gültigen RegKeys mehr erzeugen können.

Eine Software die gepatcht wurde so das die RegKey Abfrage deaktiviert wurde kanne ebenfalls keine Daten aus dem INet nachladen, da ja kein gültiger RegKey vorhanden ist. Der RegKey besteht also aus den Kundendaten, bestimmte Computermerkmalen wie MAC Addresse etc,pp und wurde mit deinem Privaten Key des Lizenzmanagers digital unterschrieben. Damit kannst also nur DU eine solche Signature erzeugen. Bei jedem Download von eurem Server muß der Kunde seinen RegKey vorweisen/senden und deine Software überprüft ob dieser RegKey eine gültige Signatur deines Lizenzmanagers enthält. Zur Überprüfung dieser Signature benötigst du nur den PublicKey deines Schlüssel. Dh. die Sofwtare die den Zugriff auf die Dateien eures Servers über den RegKey des Kunden gestattet kennt selber nicht den Privaten Schlüssel deines Lizenzmanager. Somit sind verteilte Anwendungen möglich, und der Downloadserver selber uß garnichtmal euer eigener Server sein.

Gruß Hagen

[negaH]

Zitat:

Dies bedeutet aber, dass ich ja erstmal den Namen und die Firma des Lizenznehmers nicht kenne aber trotzdem in der Lage sein möchte die Lizenzdaten zu entschlüsseln.
Ich benötige so eine Art Master und Public Key Verfahren. Mit Hilfe des Masterkeys müsste ich immer in der Lage sein die Lizenzdatei zu enschlüsseln, nicht aber der User/Cracker, wenn er nicht den genauen Namen und die Firma aus der Lizenzdatei kennt.

Ja auch sowas geht mit sym. Kryptographie. Du erzeugst einen Zufallsschlüssel A. Mit diesem werden die Daten verschlüsselt. In deinem RegKey speicherst du nun diesen Key A zwemal verschlüsselt, einmal mit den ApplicationKey verschlüsselt und ein anders mal mit deinem Lizenzmanagerschlüssel.

Du kannst also nun deine Daten etweder mit dem ApplicationKey entschlüsseln indem zu erstmal den verschl. Key A mit dem ApplicationKey entschlüsselst und danach die Daten des Kunden. Oder du nimst deinen Lizenzmanagerschlüssel lädst den Key A aus dere RegKey der damit verschl. wurde, entschl. Key A und kommst auch an die Daten ran.

Kurz gesagt: ein Zufallsschlüssel erzeugen mit dem die Daten geschützt werden. Diese Zufallskey für jeden vorkommenden MasterKey separat verschlüsselt in RegKey speichern.

Oder du verschl. in deinem RegKey die Daten gleich zweimal. EInmal mit AppKey und einmal mit MasterKey. Das hat den Vortteil das du als einzigster überprüfen kannst ob beide Datenböcke nach der entschlüsselung noch zueinander identisch sind. AppKey und MasterKey kennst du ja als einzigster beide. Es würde aber schon ausreichen wenn der Teil für den MasterKey nur ein Hashdigest über die Kundendaten ist. Denn im Grunde möchtest du ja verifizieren ob die mit dem AppKey entschl. Kundendaten nicht manipuliert wurden. Die digitale Signatur besteht also aus einem Hashdigest über diese Kundendaten der dann noch verschl. wurde mit dem MasterKey. Aber bitte vergiß nicht bei dieser Hash-Prüfsumme einen Zufallssalt mit einzubauen !

Könnte dann so aussehen:

Code:

RegKey := Kundendaten || Salt || Signature

Kundendaten = verschl. mit AppKey.
Salt = Zufall, 128 Bit 
Signature = Hash(Kundendaten) verschlüsselt mit SessionKey.KDF_MD5(Salt || Masterkey)

Überprüfung ist dann so:

1.) entschl. Kundendaten mit AppKey
2.) ziehe Hash über Kundendaten
3.) verschlüssele Hash mit SessionKey.KDF_MD5(Salt || MasterKey)
4.) vergleiche Output mit dem in RegKey gespeicherten Wert

KDF_MD5 steht für eine Key Derivation Function sowas wie THash_MD5.KDFx() und erzeugt aus Salt + MasterKey + Hashfunktion einen sicheren zufälligen Sessionkey der nicht rückwärts geknackt werden kann. Du schützt damit den MasterKey vor Angriffen.

Ach übrigens könntest du auch die Signature über die verschl. Kundendaten ziehen. Das würde es ermöglichen die Signature zu überprüfen ohne das du den AppKey kennen müsstest.

Wichtig ist nur eines: diese Siganture kamnn nur reproduziert oder entschlüsselt werden wenn man den MasterKey hat, und dieser liegt nicht im Zugriff eines Crackers.

Gruß Hagen