S. Goers
Grünschnabel
Dabei seit: 11.06.2008
Beiträge: 5
|
|
Hallo im Forum,
um es gleich vorweg zu sagen: Ich komme von SG-Intec (SG-Lock).
Ich habe aufmerksam und mit Interesse die Diskussion im Forum verfolgt und würde nun gerne auch etwas dazu beitragen.
Zunächst kann ich aus eigener Erfahrung sagen, dass die Ansprüche der Rechteinhaber an einen Kopierschutz SEHR breit gefächert bzw. unterschiedlich sind.
Somit ist es eigentlich fast unmöglich das "perfekte" Produkt anzubieten.
Neben möglichst hoher Sicherheit ist die einfache Einbindung durch den Programmierer und die problemlose Handhabung durch den Endbenutzer ein wichtiges Kriterium (weshalb SG-Lock treiberlos konzipiert wurde). Speziell die ersten 2 Punkte können schnell in Widerspruch geraten.
An dieser Stelle möchte ich auf die Einbindung des APIs per DLL kommen. Dass dies nicht der Stand der Technik sein soll, sehe ich anders.
Zitat: |
Original von Michael Bauer
Danke für Deinen kurzen Bericht zu Matrixlock :-)
SG-Lock bietet zwar die Möglichkeit mehrere Keys für die interne Dongleverschlüsselung zu speichern, folgende Funktionen werden aber im Vergleich zu Matrixlock nicht geboten:
1) Keinen automatischen Schutz mittels eines Wrapper Tools wie z.B. MxCrypt
2) Keine Unterstützung für statische DLL Einbindung
3) Keine Donglesperre bei Hackversuchen
4) Kein Obfuscator für .Net Anwendungen
5) Keine Netzwerkunterstützung
6) Keine Remote Update-Fähigkeit
SG-Lock bietet zum Einbinden des Schutzes nur die dynamische DLL Einbindung, was meiner Ansicht nach heute nicht mehr Stand der Technik ist, siehe andere Hersteller.
Augrund der Schwächen 1-4 würde ich im Vergleich Matrixlock <-> SG-Lock, Matrixlock als stärkeren Schutz ansehen. |
|
Die Einbindung der DLL bei SG-Lock ist nämlich kein normales Laden infolge dessen sofort alle API-Funktionen zur Verfügung stehen. Bis auf eine Freischaltfunktion sind nämlich nach dem Laden der DLL alle anderen Funktion noch nicht freigeschaltet. Dies wird erst nach einer erfolgreichen Authentifizierung der EXE durch die DLL vorgenommen.
Der Code zur Authentifizierung muss als Source-Code zusätzlich in den Quellcode der geschützten Anwendung "included" werden - dieser befindet sich nach dem compilieren in der EXE-Datei (wie bei einer statisch hinzugelinkten Lib). Ganz nebenbei wird hierbei auch noch die DLL von der EXE authentifiziert (die andere Variante).
Eine Dummy-DLL, die lediglich das API emuliert ist damit nicht so einfach möglich erzustellen, wie vielleicht an dieser Stelle vermutet wurde. Zusätzlich ist es auch nicht einfach möglich mit einer eigenen Anwendung über das API auf die Dongle Hardware zuzugreifen (um viellecht Werte im Dongle zu ändern) , was mit einer rein statischen Lib (wie hier favorisiert) ersteinmal nicht ausgeschlossen ist, deren API ist ja i.d.R. offen (das eine hat nämlich nichts mit dem anderen - die Art der Bindung - zu tun) - ein Vorteil der bei SG-Lock angewandten Methode gegenüber einer statischen Lib. Das alles wird mit einem API-Aufruf erledigt.
Insofern halte ich dieser Art der Einbindung gerade nicht für veraltet - im Gegenteil - es verbindet die Vorteile der beiden Methoden ohne, dass die Nachteile von beiden zu tragen kommen.
Zu der oben genannten Liste möchte ich gerne auch Stellung beziehen.
Zu 1: Envelope -Tools werden meiner Meinung nach in der Sicherheitswirkung überschätzt. Häufig bieten Sie die Möglichkeit mit sogn. "Generischen Hacks" ausgehebelt werden zu können, die sogar fast jeder nicht-Programmierer durch einfaches Herunterladen aus den Internet nutzen kann.
Zu 2: siehe oben
Zu 3: Die Authentifizierung beruht bei SG-Lock auf Schlüsseln mit 128-Bit Länge. Der verwendet Algorithmus hat aus kryptographischer Sicht eine effektive Länge von ca. 126 Bits. Hierbei ist ein Brute Force Angriff weitgehend sinnlos (2^126 Möglichkeiten) und damit ist ein "Hacker-Lock", dass die Versuche begrenzt, überflüssig. Ein solcher Schutz wäre dann notwendig, wenn die Anzahl der Möglichkeiten aufgrund der gewählten Methode sehr klein sind, um diesen prinzipiellen Nachteil der Methode abzuschwächen.
Zu4: Es gibt sehr gute .net Obfuscator-Tools am Markt von Herstellern, die sich darauf spezialsiert haben. Softwarehersteller, die Ihr Know-How und Urheberrechte effektiv schützen möchten, werden sicherlich nicht unbedingt ein kostenlos mitgeliefertes anwenden sondern versuchen das beste Tool, das am Markt verfügbar ist, auszuwählen. Das kann dann selbstverständlich auch mit SG-Lock kombiniert werden.
Zu 5: Das stimmt. SG-Lock ist nicht als Netzwerk-Version erhältlich.
Zu6: Selbstverständlich ist SG-Lock remote-update-fähig. Es wird z.Zt. von unserer Seite nur kein fertiges Tool dafür angeboten, da dies i.d.R. schöner in die geschützte Anwendung integriert werden (Menüpunkt).
Mit freundlichen Grüßen
S. Görs
|
|
11.06.2008 13:02 |
|
uhabber
Mitglied
Dabei seit: 02.02.2008
Beiträge: 37
|
|
|
11.06.2008 22:31 |
|
S. Goers
Grünschnabel
Dabei seit: 11.06.2008
Beiträge: 5
|
|
Hallo uhabber,
ich möchte gerne auch hierzu etwas beitragen.
Zitat: |
Original von uhabber
ich besitze auch einen SG-Lock Dongle ich kann nur sagen dieser Dongle ist besser als Matrixlock.
Ich selber setze Wibu Key ein.SG-Lock Auth.methode ist gut
der Bytecode ist der Schlüssel zum Dongle und liegt dann dem User offen und man kann den Dongle schön editieren |
|
Ja, die Prüfung der DLL erfolgt mit der Methode SglAuthent(). Ein kundenspezifischer Bytecode schaltet der Dongle frei. Wobei dazuzusagen ist, dass hierbei nur stark verschlüsselte Informationen über die Schnittstelle laufen. Um Missverständnissen vorzubeugen: Der oben genannte User, der Dongle editieren kann, ist der Softwarehersteller/Rechteinhaber und natürlich nicht der Softwareanwender (auch User genannt).
Zitat: |
Original von uhabber
Meiner Meinung nach muss der Dongle effektiv gegen verändern gesichert sein durch Wissen und Besitz (Password und Masterkey).
Die stärke der Verschlüsselung ob Feal , AES , DES , XTEA spielt keine grosse Rolle.Wenn der Schlüssel uberreichbar ist im Dongle.
|
|
Dem kann ich zustimmen - die sichere Schlüsselverwahrung ist ein wichtiger Sicherheitsfaktor, deshalb werden alle Daten im SG-Lock mit einer internen 128-Bit Verschlüsselung im Donglespeicher abgelegt, so auch die 128-Bit Schlüssel selbst. Dabei benutzt jeder SG-Lock einen anderen internen Schlüssel - dies ist allerdings transparent für den Programmier gelöst, d.h. nicht jeder SG-lock muss anders angesprochen werden.
Zitat: |
Original von uhabber
Sg-LOCK ist ein Single PC Dongle welcher bis zu 15 Verschlüsselungen kann.
Verfügt aber über keinen festprogramierte Schlüssel der einzigartig für jeden Kunden ist ausser U2 Modell
Wenn jemand den Schlüssel auslesen kann so kann er dann den Dongle kopieren gegen seinen eigenen muss nur den Auth code patchen.
|
|
Es sind bis zu 16 Schlüssel mit 128-Bit Länge, die im SG-Lock gespeichert werden können. Eine Auslesefunktion gibt es nicht - man muss dann an die Hardware, was wenig Sinn macht, da der Speicher - wie oben beschrieben - mit individuellen, d.h. von SG-Lock zu SG-Lock unterschiedlichen 128-Bit Schlüsseln voll-verschlüsselt ist.
Es gibt deshalb mehr als einen Schlüssel, weil neben der Nutzung für
1. Daten-Verschlüsselung
2. Daten-Signierung
3. Challenge-Response-Authentifizierung
man auch sehr gut
4. Informationen im Schlüssel selbst verstecken kann, z.b. eine Lizenznummer.
Es handelt sich schließlich dabei um 16 Bytes (128 Bit) Informationen. Falls man nur ein paar Bits braucht (aber eigentlich immer) sollte man diese nocheimal überverschlüsseln, damit die Information im Datenblock diffundiert.
Bei einer Überprüfung wird dann nicht die Lizenznummer über die Schnittstellen DLL/USB übertragen sondern lediglich Verschlüsselungergebnisse davon und diese jedesmal anders da man hierfür sehr gut Zufallszahlen nehmen kann und sollte.
Dabei ist dann die Frage, ob eine statische LIB oder eine DLL benutzt wird, gar nicht mehr so wichtig, weil die gesamte Information zwischen EXE und USB Hardware quasi getunnelt wird. Dabei ist die Information sogar nur "Sekundär-Information", da es ja nur um Verschlüsselungsergebnisse handelt und nicht um den Schlüssel (in diesem Fall die Lizenznummer) selbst.
Ich hoffe ich habe in die Ideen, die hinter der Konzeption von SG-Lock stehen, etwas Licht bringen können ...
Mit freundlichen Grüßen
S. Goers
|
|
12.06.2008 09:44 |
|
S. Goers
Grünschnabel
Dabei seit: 11.06.2008
Beiträge: 5
|
|
Hallo uhabber,
ich denke es ist notwendig hier in die Deatils zu gehen ...
Zitat: |
Original von uhabber
Schauen wir in das Handbuch da steht auf Seite 16 kap.4.2
Sg-Auth....
Dise Funktion muss man als erstes aufrufen und die 48 byte Auth.Code übergeben
(habe ich diese 48 Byte kann ich mit dem SG-Lock Manager Arbeiten
Ram Editieren.... usw
|
|
Wenn SglAuthent() eine Funktion der DLL wäre, wäre die Aussage richtig - ist sie aber nicht. Vielmehr ist SglAuthent() eine Funktion, die included wird und damit in der EXE ist (bitte in den Header-Dateien nachsehen). SglAuthent() ihrerseits ruft andere Funktionen in der DLL auf, denen entscheidene Informationen nicht übergeben werden. Somit ist die Annahme man könne einfach den Aufruf von SglAuthent() mit eine Dummy-DLL auffangen nicht richtig (das wäre bei weitem zu einfach).
Zitat: |
Original von uhabber
Challenge-Response-Authentifizierung Klasse dann weiss jeder den TeA KEY 128 Bit und DAS U2 Lock Währe wertlos U3 / U4 Haben mehere Schlüssel auf Reserve
|
|
Ich glaube hier besteht ein Verständnisproblem. Der interne 128-Bit Schlüssel (egal ob bei U2 oder U3,U4) hat nichts mit der Funktion SglAuthent() zu tun.
Selbst wenn ich Zugang zum SG-Lock-API hätte, weil mir auf irgend eine Weise der 48-Byte Authentcode bekannt geworden ist, bin ich eigentlich kein Stück weitergekommen den internen 128-Bit Schlüssel zu ermitteln, denn es gibt keine Lese-Funktion für den 128-Bit Schlüssel.
Insofern ist die Challenge-Response-Authentifizierung eine gute Methode, die den Angreifer entweder per reverse engineering in die EXE-Datei zwingt oder an die SG-Lock Hardware, was beides einen erheblichen Aufwand darstellt. Die DLL mit ihrem API ist nicht mehr beteiligt, da sie nur die Daten vermittelt, aber nicht mehr verändert und ist somit für Angriffe uninteressant bzw. nutzlos.
Zitat: |
Original von uhabber
Sgl-Writekey ok
aber EEPROM IST EEPROM
ich kann den Speicher lesen den normalen RAM
der Schlüsselspeicher wird im selben RAM stehen
|
|
Sicherlich kann man EEPROMs auslesen, aber was hat man gewonnen, wenn man nur verschlüsselte Daten findet? Selbst wenn mir bekannt ist wo im EEPROM ein 128-Bit Schlüssel steht oder ich das gesamte EEPROM kopiere und mir sage "Ich muss garnicht wissen wie die Daten genau ausehen - ich kopiere sie einfach von einem SG-Lock in mein Demo SG-Lock und ich habe diesen dubliziert" - das geht leider nicht, weil jedes SG-Lock die EEPROM Daten aufgrund des unterschiedlichen internen 128-Bit Schlüssel anders entschlüsselt. Dies würde der SG-Lock im übrigen selbst erkennen und sich passiv schalten.
Mit freundlichen Grüßen,
S. Goers
|
|
12.06.2008 15:36 |
|
S. Goers
Grünschnabel
Dabei seit: 11.06.2008
Beiträge: 5
|
|
RE: statische/dynamische Einbindung |
|
Hallo Herr Bauer,
gerne möchte ich hierzu noch etwas ergänzen.
Zitat: |
Original von Michael Bauer
Hallo Herr Goers,
vielen Dank für Ihren Beiträge und dass Sie mich korrigiert haben was Ihren Schutz anbetrifft.
Ich möchte mich nochmals kurz zum Thema statische oder dynamische DLL äussern.
Ob die statische oder die dynamische DLL mehr Schutz bietet lässt sich so pauschal nicht beantworten. In beiden Fällen kann man die Sache geschickt oder ungeschickt angehen. Meine bisherigen Erfahrungen haben mir aber gezeigt, dass die dynamische DLL Einbindung für einen Hacker einen schnelleren Einstieg in das Programm ermöglicht. Wenn dann noch so selbstprechende Namen wie "LeseDongleSeriennummer" oder "VerschlüsselungViaDongle" im Spiel sind, weiss ein Hacker sofort auf welche DLL-Funktionen er seine Breakpoints setzen muss.
|
|
Sie haben natürlich recht, dass wenn die Progammausführung in eine DLL verzweigt, dies im Maschinencode einfacher zu finden ist, als wenn eine interne Funktion aufgerufen wird. Aber auch eine statische Lib wird irgendwann (meist recht schnell) auf die Treiberebene wechseln und ist damit auch nicht immun gegen diese Analysemethode des Maschinencodes.
Zitat: |
Original von Michael Bauer
Wurde dann noch eine User-Integration nach folgendem Schema gemacht – diese Art ist leider sehr oft vorzufinden:
Ergebnis = Aufruf Dongle-Funktion()
If (Ergebnis)
{
/* Funktion erfolgreich ausgeführt */
}
Else
{
/* Fehler bei der Ausführung */
}
|
|
Mit einer Einbindung in der oben beschriebenen Form hat man sicherlich nicht alle Möglichkeiten genutzt.
Hier kann man mit einer zweiten weit verzögerten Prüfung z.B. einer Challenge-Response-Authentfizierung (gerne auch mit verdecktem vorherigen Umkopieren von relevanten Daten in größerem Rahmen und in andere Programmteile), die nicht regelmäßig sondern sporadische, unklare Fehler erzeugt, viel erreichen.
Andererseits muss man im Auge behalten, was der Softwarehersteller tatsächlich erreichen will. Nicht jede Software ist wirklich interessant für "high-skilled hackers". Und nicht jeder Hacker empfindet das dringende Bedürfnis, seinen Hack weiterzugeben oder gleich ins Internet zu stellen. Ich habe die Erfahrung gemacht, dass Softwarehersteller recht realistisch einschätzen können, wie groß die Bedrohung durch illegale Nutzung Ihrer Software tatsächlich ist.
Nicht wenigen Softwareherstellern ist zunächst das einfache Kopieren unter Kollegen, die nie zu einem Disassambler greifen würden, ein Dorn im Auge. Genauso die Mehrfachnutzung - ein Kunde kauft und betreibt eine legale Version, hat aber zusätzlich 3 andere Installationen in Betrieb (Support kann er damit u.U. auch noch erhalten, da er ja als legaler Nutzer auftreten kann).
Viele Softwarehersteller sind sich der Tatsache bewußt, dass es keinen 100%-igen Schutz gibt und sie Missbrauch nicht überall und zu jedem Zeitpunkt zu 100% unterbinden können - wenn sie aber 90% potenzieller illegaler Kopien unterbinden können ist das ein deutlicher Gewinn für sie.
Mit freundlichen Grüßen
S. Goers
|
|
13.06.2008 10:24 |
|
|