|
FoxProFoxPro Developer's Conference '94 |
Session 134
Datensicherheit sowie
Daten-
und Softwareschutz mit FoxPro
Sebastian Flucke
ASCI-Consulting, Berlin
Einleitung
Datensicherheit sowie Daten- und Softwareschutz sind Themen, denen sich auch ein FoxPro-Programmierer auf die Dauer nicht verschließen kann. Aus diesem Grund sollen in dem vorliegenden Beitrag die wichtigsten theoretischen Aspekte betrachtet und bezüglich ihrer Umsetzbarkeit mit FoxPro untersucht werden.
Inhalt:
Kurzbeschreibung:
Zur Einführung werden diejenigen Aspekte der Begriffe Datensicherheit, Datenschutz und Softwareschutz erläutert, die in den weiteren Ausführungen untersetzt werden sollen.
Ein erster Punkt bezogen auf Datensicherheit ist das Absichern von Applikationen gegenüber den Widernissen einer Multitasking-/Multiuser-Umgebung (Platte voll, Hauptspeicher reicht nicht, System-Ressourcen erschöpft, File-Handles reichen nicht aus). Die Festplatten-Problematik trifft dabei sowohl auf Netzlaufwerke für FPD/FPW als auch für lokale Laufwerke in einer Multitasking-Umgebung zu.
Ein weiterer Gesichtspunkt ist die Behandlung von aufgetretenen Fehlern innerhalb der betreffenden Applikation. Es wird ein universeller Error-Handler demonstriert, der neben der Protokollierung von Fehlern eine differenzierte Reaktion je nach Schwere des aufgetretenen Fehlers gewährleistet und zusätzlich die Möglichkeit zur Sonderbehandlung spezieller Fehlerzustände beinhaltet.
Transaktionsverarbeitung und ähnlich gelagerte Algorithmen werden vorgestellt als Möglichkeiten, die nach einem Programm- oder Rechner-Absturz eventuell herrschenden Inkonsistenzen innerhalb von Datenbeständen wieder zu bereinigen.
Die richtige Backup-Strategie ist ein weiterer wichtiger Bestandteil einer Datensicherheits-Konzeption. Hierbei wird auf Backup-Medien, Backup-Typen und das Zusammenspiel von FoxPro-Applikationen mit existierenden Backup-Systemen eingegangen.
Ein wichtiger Punkt des Datenschutzes ist die Verwaltung von Zugriffsrechten für den einzelnen Nutzer (Zugriffrechte sowohl bezogen auf bestimmte Menüpunkte einer Applikation als auch bezogen auf den Zugriff zu bestimmten Daten). Es werden verschiedene Ansatzpunkte für eine Verwaltung von Nutzer-Rechten aufgezeigt. Außerdem werden Voraussetzungen für eine sichere Rechte-Verwaltung diskutiert (Paßwort-Schutz, manipulationssicheres Abspeichern der Zugriffsrechte usw.).
In diesem Zusammenhang spielt das Verschlüsseln von Informationen eine große Rolle. Es werden sowohl professionelle Verschlüsselungsprodukte als auch einfache, selbst zu programmierende Algorithmen vorgestellt. Zu erwähnen ist in diesem Zusammenhang auch das Komprimieren von Daten, welches ebenfalls mit Paßwort-Verschlüsselungen gekoppelt sein kann.
Im Bereich des Softwareschutzes spielt der Schutz des geistigen Eigentums an Software eine wichtige Rolle.
Das betrifft einerseits urheberrechtliche Aspekte, d.h. den Schutz von programmierten Algorithmen vor unauthorisiertem Zugriff. Es wird gezeigt, welche Möglichkeiten FoxPro selbst bietet und welche zusätzlichen Hilfsmittel zur Verfügung stehen.
Andererseits geht es auch um den Schutz vor unberechtigter Nutzung bzw. unberechtigter Vervielfältigung von Softwareprodukten. Hierbei werden Verfahren des Softwareschutzes sowohl mit Hardware-Bestandteilen (Dongle o.ä.) als auch rein softwaretechnisch arbeitende Varianten vorgestellt.
1. Datensicherheit
Ein wichtiger Punkt zur Datensicherheit ist das Absichern von Applikationen gegenüber den Widernissen einer Multiuser-/Multitasking-Umgebung. Das betrifft die drei Bereiche
Welche Ressourcen müssen beim Start eines FoxPro-Programms in ausreichendem Maße zur Verfügung stehen:
Alle diese Ressourcen können natürlich auch zur Laufzeit knapp werden. Ursache dafür ist einerseits der Ressourcenverbrauch der betreffenden Applikation selbst, andererseits können andere, parallel laufende Applikationen die Ursache für Ressourcenknappheit werden.
Der Ressourcenbedarf der eigenen Applikation läßt sich mit ziemlicher Genauigkeit ermitteln. Dadurch hat man die Möglichkeit, vor ressourcenintensiven Prozessen eine Prüfung durchzuführen und die gewünschte Aktivität ggf. zurückzuweisen.
Wesentlich problematischer ist eine Ressourcenverknappung durch fremde Applikationen zu überwachen und zu vermeiden, da ein zu einem Zeitpunkt gemessener Wert (z.B. freier Festplattenplatz) im nächsten Moment durch eine andere Applikation schon wieder belegt sein kann. Diese Problematik betrifft alle oben erwähnten Ressourcen:
Welche Ressourcen werden nun von FoxPro zu welchen Zwecken benötigt?
Im folgenden werden die vier Ressourcen-Arten etwas detaillierter untersucht.
Neben dem Platz für die eigentlichen Daten und Dateien wird Festplatten-Kapazität benötigt für temporäre Dateien. Diese Dateien werden innerhalb einer Foxpro-Applikation entweder explizit erzeugt (z.B. bei programmgesteuerten Strukturmodifizierungen von Datenbanken) oder sie entstehen implizit durch das FoxPro-Laufzeitsystem (z.B. beim INDEX-Befehl kann die temporär benötigte Festplatten-Kapazität ein mehrfaches der letztendlich entstehenden Indexdatei betragen).
Welche Faktoren können einer Applikation nun bzgl. der Festplattenkapazität in die Quere kommen:
Welche Abhilfemöglichkeiten gibt es:
- Überwachung der Festplatten-Kapazität mit der FP-Funktion DISKSPACE() mit möglichst differenzierter Reaktion (nicht sofort Programm-Abbruch, sondern z.B. die Möglichkeit geben, nicht mehr benötigte Dateien zu löschen)
- Reservierung von Platten-Kapazität durch Anlegen einer Dummy-Datei mit den Low-Level-Funktionen FCREATE() und FCHSIZE() und sukzessiver Freigabe des jeweils benötigten Speicherplatzes mit FCHSIZE() (setzt allerdings relativ genaue Kenntnis über den Bedarf an Festplatten-Kapazität des jeweiligen Programmschrittes voraus und kann trotzdem noch schiefgehen, wenn andere Applikationen während des betreffenden Programmschritts ebenfalls Festplatten-Kapazität belegen).
Als zweite Ressourcen-Art wirken sich die zur Verfügung stehenden File-Handles auf die Arbeit mit Datenträgern aus.
Das MS-DOS-Betriebssystem, auf dem auch Windows basiert, benötigt für jede zu öffnende Datei aus organisatorischen Gründen einen sogenannten File-Handle. Die Anzahl der zur Verfügung stehenden Filehandles (gleich Anzahl der Dateien, die gleichzeitig geöffnet sein können), wird eigentlich in der Datei CONFIG.SYS mit der Eintragung FILES=nnn bestimmt.
Diese Eintragung gilt dann über das gesamte MS-DOS-Betriebssystem, d.h. auch einmal über alle aktiven Windows-Applikationen. Ist die Eintragung in der Datei CONFIG.SYS z.B. FILES=100 und es ist eine Applikation aktiv, die 65 Dateien gleichzeitig offenhalten will, dann stehen für weitere Applikationen nur noch insgesamt 35 File-Handles zur Verfügung.
Die FILES-Einstellung in der Datei CONFIG.SYS gilt allerdings nur für Dateien, die sich auf lokalen Laufwerken (Disketten, Festplatten, CD-Laufwerken, MO-Drives usw.) befinden. Für Dateien auf Netzwerk-Laufwerken gilt die entsprechende Netzwerkeinstellung (bei Novell-Netware z.B. der FILE-HANDLES-Parameter in der .CFG-Datei der Netshell). Dabei darf die Summe der FILES aus der CONFIG.SYS und der FILE-HANDLES aus der .CFG-Datei den Wert von 255 nicht überschreiten.
Außerdem wird die Anzahl gleichzeitig offener Dateien zusätzlich noch durch das Programm SHARE beeinflußt. SHARE ist ein Programm zur Verwaltung des gleichzeitigen Zugriffs mehrerer Applikationen auf dieselbe Datei. Für dieses Programm existieren Kommandozeilen-Parameter, die die Anzahl der gleichzeitig für Mehrfachnutzung zu verwaltenden Dateien bestimmen (als zusätzliche Einschränkung der FILES- und FILE-HANDLES-Einstellungen). Kommt es also in einer Applikation zu der Fehlermeldung "Zu viele Dateien geöffnet!", kann die Ursache in einem der genannten Einflußfaktoren oder in einer Kombination dieser Faktoren liegen.
Weiterhin ist zu beachten, daß bestimmte Aktivitäten in FoxPro mehr File-Handles benötigen als man auf den ersten Blick vermutet. So benötigt der Befehl USE xyz entweder 1, 2 oder 3 File-Handles, je nach dem ob zu der Datenbankdatei eine Memodatei und/oder eine automatisch zu öffnende Indexdatei gehören.
Ähnlich wie bei der Poblematik der Festplatten-Kapazität hilft eine Überprüfung der zur Verfügung stehenden File-Handles z.B. beim Start eines FPW-Programms nur bedingt, da jederzeit andere Applikationen auch File-Handles belegen können.
Die Funktionen FILE_CHK(), FILE_RES() und FILE_FRE() in der Programmdatei MISCFUNC.PRG auf der Begleitdiskette zeigen eine Prüfung der zur Verfügung stehenden File-Handles sowie einen Mechanismus zur Reservierung und sukzessiven Freigabe von File-Handles.
Der zur Verfügung stehende Hauptspeicher ist die dritte Ressourcen-Art, die berücksichtigt werden muß.
Die Hauptspeicher-Menge, die einer FoxPro-Applikation zur Verfügung stehen soll, wird (mit einer speziellen Ausnahme bei FPW) vom FoxPro-Laufzeitsystem beim Programmstart okkupiert und steht der Applikation dann uneingeschränkt zur Verfügung.
Innerhalb der Applikation muß man dann lediglich überwachen, daß die noch nicht von Programmelementen (Fensterdefinitionen, Menüs, Popups, Datenbankpuffern usw.) belegten Bereiche für die jeweilige Programm-Aktivität ausreichen.
Der belegte und der zur Verfügung stehende Speicherplatz kann mit den FoxPro-Funktionen SYS(1016) und SYS(1001) ermittelt werden.
Der schwierigere Part der Überwachung ist das Abschätzen des für eine konkrete Programm-Aktivität benötigten Speicherplatzes. Dort hilft normalerweise nur die try-and-error-Methode unter zuhilfenahme der Faustregel "lieber noch 25% dazugeben".
Eine wichtige Ausnahme ist Speicherplatz für nutzerdefinierte Fenster unter FPW. Neben einigen Bytes für organisatorische Zwecke, die jedes Fenster innerhalb des FoxPro-Speichers belegt, benötigen nutzerdefinierte Fenster unter Windows auch Speicher außerhalb des mit SYS(1001) abfragbaren FoxPro-Speichers! Dieser Speicher wird benötigt zum Speichern der Fensterinhalte von nutzerdefinierten Fenstern und errechnet sich wie folgt:
Speicher = PixelAnzahlHöhe * PixelAnzahBreite
* Farbtiefe.
PixelAnzahlHöhe - Höhe des Fensters in Pixeln
PixelAnzahlBreite - Breite der Fensters in Pixeln
Farbtiefe - Anzahl der Bits zum Speichern der Farbinformationen
je Pixel
Beispiel:
PixelAnzahlHöhe = 400
PixelAnzahlBreite = 600
Farbtiefe = 16.7 Mill. Farben -> 24 Bit
-> Speicher = 5 760 000 Bit = 720 000 Byte = 703.125 KByte!!!!
Das Beispiel zeigt, daß man eine FoxProW-Applikation nicht unbedingt im TrueColor-Modus mit 16,7 Mill. Farben abarbeiten sollte. Unabhängig von der Fenstergröße und der Farbtiefe ist es aber in jedem Fall Speicher außerhalb von FPW und damit Speicher, der auch durch andere Applikationen beansprucht werden kann. Die Funktion WIN_RAM() in der Programmdatei MISCFUNC.PRG auf der Begleitdiskette zeigt die Berechnung des Bedarfs an RAM außerhalb des FPW-internen Speichers unter Nutzung von Windows-API-Funktionen via FOXTOOLS.FLL.
Die vierte zu beachtende Ressourcenart sind die Windows-System-Ressourcen. Hinter diesem Begriff verbirgt sich ein 2 x 64 KByte großer RAM-Bereich, der zur Verwaltung windowsspezifischer Objekte benötigt wird.
Der eine 64K-Block beinhaltet die sogenannten GDI-Ressourcen (Definition lt. Windows-SDK: "GDI resources include device-context handles, brushes, pens, regions, fonts, and bitmaps."). In dem zweiten 64K-Block werden die USER-Ressourcen verwaltet (Definition lt. Windows-SDK: "These resources include window and menu handles.").
Der noch freie Teil dieser Ressourcen (die übrigens in Windows 3.1/3.11 in keiner Form erweitert werden können) kann mit der Windows-API-Funktion "GetFreeSystemResources" via FOXTOOLS.FLL abgefragt werden (siehe Funktion GETSYSRES() in der Programmdatei MISCFUNC.PRG auf der Begleitdiskette). Diese Funktion gibt den noch freien Anteil der jeweiligen Ressourcenart in Prozent zurück.
Die z.B. im Info-Fenster des Programm-Managers angezeigte Prozentzahl an freien Systemressourcen läßt sich mit der API-Funktion "GetFreeSystemResources" ebenfalls abfragen. Sie gibt das Minimum aus freien USER- und freien GDI-Ressourcen zurück (etwas entgegen der Windows-SDK-Dokumentation, die da sehr allgemeinkonkret schreibt "the percentage of free space for system resources").
Die Überprüfung des Umgangs einer FoxProW-Applikation mit den genannten vier Ressourcenarten kann man übrigens sehr leicht mit den Funktionen der zum Windows-SDK gehörenden STRESS.DLL überprüfen. Diese DLL beinhaltet Funktionen zum Dummy-Reservieren von Hauptspeicher, Festplatten-Kapazität, File-Handles und Systemressourcen, um das Verhalten von Applikationen in Extremsituationen prüfen zu können (siehe die Funktionen STRS*() in der Programmdatei MISCFUNC.PRG auf der Begleitdiskette).
Bezogen auf alle vier Ressourcenarten läßt sich nun aber feststellen: Egal, wieviel Vorsorge man trifft, es bleibt das Risiko, daß doch einmal an einer entscheidenden Stelle eine Ressource nicht ausreicht und die Applikation dadurch zum Absturz kommt.
Man kann diesem Fehlerfall zwar vorbeugen, wenn er aber eintritt, dann muß die Applikation differenziert reagieren können.
Die Reaktionsmöglichkeiten sind dabei sehr unterschiedlich. Werden z.B. die Windows-System-Ressourcen knapp, weil der Nutzer die Warnungen einer entsprechenden Überwachungs-Routine ignoriert hat, kann es zu sehr vielfältigen Auswirkungen kommen, denen man ihre Ursache nicht immer auf den ersten Blick ansieht ("Zu wenig Speicherplatz" ist z.B. eine typische FoxProW-Reaktion auf ungenügende Windows-System-Ressourcen).
Eine differenzierte Reaktion auf Fehlerzustände während der Abarbeitung einer FoxPro-Applikation ist das Anliegen eines Error-Handlers (siehe Programmdatei ERR_HAND.PRG auf der Begleitdiskette). Dieser Handler beinhaltet:
und läßt sich programmtechnisch mit wenigen einfachen Handgriffen integrieren.
Eine sehr effektive, aber sorgfältig einzusetzende Online-Maßnahme zur Vorbeugung von Datenverlusten bei Abstürzen von Programm oder Computer ist die sogenannte Transaktionsverarbeitung.
Dabei geht es darum, Dateischreib-Prozesse zu logischen Blöcken zusammenzufassen, die entweder komplett absolviert werden sollen oder gar nicht. Kommt es innerhalb eines solchen Blockes zum Fehler (z.B Computer-Absturz), kann der schon geschriebene Teil eines Blockes quasi ungeschehen gemacht werden und man hat wieder den konsistenten Ausgangszustand vorliegen.
Transaktionsverarbeitung repariert also keine Fehler, sondern sichert automatisch oder auf explizite Anforderung des steuernden Programms die Wiederherstellung eines konsistenten Ausgangszustandes.
FoxPro enthält in der vorliegenden Version keine expliziten Befehle zur Transaktionsverarbeitung. Trotzdem braucht man auf dieses Prizip nicht vollständig zu verzichten.
Zum einen bieten die meisten Netzwerk-Betriebssysteme (z.B. Novell-Netware) Möglichkeiten zur Transaktionsverarbeitung, die über entsprechende FoxPro-Bibliotheken (GP-LIB, FP-NET u.a.) gesteuert werden können, falls man FoxPro im Netzwerk betreibt (bei NOVELL-Transaktionen ist allerdings zu beachten, daß während der Zeit einer expliziten Transaktion die betreffende Datei von Novell mit einem File-Locking für alle anderen Stationen im Netz gesperrt ist).
Zum anderen kann man das Transaktions-Prinzip natürlich auch mit den normalen FoxPro-Befehlen realisieren:
Ist das Programm nun während der "Transaktion" abgestürzt, dann erkennt ein entsprechender Algorithmus beim nächsten Hochfahren die nicht abgeschlossene Transaktion und löscht die temporäre Datei (der Ausgangszustand liegt ja noch im Original vor).
Dieses "hausgemachte" Verfahren ist allerdings nur für Einplatzlösungen zu empfehlen, weil zum Löschen und Umbennen natürlich exklusive Zugriffsrechte benötigt werden. In einer Netzwerkumgebung sollte man besser auf die Transaktionsmechanismen der Netzwerksoftware zurückgreifen.
Zu beachten ist, daß sowohl echte als auch "hausgemachte" Transaktionen immer entsprechende Festplatten-Kapazitäten voraussetzen und sich negativ auf die Laufzeit auswirken (als Preis für die höhere Sicherheit).
Die Offline-Variante der Absturz-Vorbeugung ist das regelmäßige Erstellen von Backups. Ziel ist es, die Wiederherstellung der Arbeitsfähigkeit nach Hardware-, Software- und Bedienfehlern mit vertretbarem Aufwand realisieren zu können.
Dabei gibt es mehrere Backup-Methoden:
Als Backup-Medien sind prizipiell alle beschreibbaren removable Datenträger geeignet:
Alle genannten Medien haben bestimmte Vor- und Nachteile, die an dieser Stelle aber nicht näher diskutiert werden sollen.
Unabhängig von der Backup-Methode und den verwendeten Medien sollte man immer auf eine ausreichende Generationsfolge achten. Wieviele Generationen man archiviert, muß je nach Bedarf entschieden werden. In keinem Fall sollte man aber am Dienstag schon das Tape vom Montag überschreiben, denn wenn der Computer bei dieser Operation abstürzt, kann im Extremfall sowohl die Festplatte mit dem aktuellen Stand der Daten als auch das Tape mit dem Stand von Montag zerstört werden.
Aus Sicht einer FoxPro-Applikation gibt es zwei Ebenen von Backups:
Die häufigste Backup-Methode auf Betriebssystem-Ebene ist die turnusmäßige Sicherung der Festplatteninhalte von Netzwerkservern und auch Arbeitsstationen auf Streamer-Tapes. Dieser Art von Datensicherung ist in jedem Fall der Vorzug zu geben.
Die Integration von Backup-Funktionen in eine Applikation ist ein schwieriges Unterfangen. Man sollte sich diesen Schritt wohl überlegen, weil an eine solche Funktion von den Kunden dann schnell Anforderungen gestellt werden, die die Programmierer professioneller Backup-Systeme einige Mannjahre gekostet haben. Trotzdem im folgenden einige Bemerkungen zu dieser Problematik.
Backup innerhalb einer Applikation heißt:
Ein relativ gut gangbarer Weg ist die Kombination eines professionellen Backup-Tools mit einer Einbindung in die SHUTDOWN-Routine einer Applikation:
Mit dieser Variante hat man dem Wunsch vieler Kunden nach der Integration eines Backup-Mechanismus in den meisten Fällen hinreichend Rechnung getragen, ohne sich den Widernissen der Eigenprogrammierung eines Backuptools aussetzen zu müssen.
Zu beachten ist unter FPW allerdings, ob es sich bei der per Befehlszeile gestarteten Backup-Routine um ein DOS- oder ein Windows-Programm handelt.
Bei einem DOS-Backup-Tool gibt es keine Probleme. Bei einem Windows-Programm allerdings wird dieses Programm mit dem RUN-Befehl zwar gestartet, die eigentliche FoxProW-Applikation würde dann aber parallel dazu weiter abgearbeitet werden. Das kann dazu führen, daß noch während des laufenden Backup-Prozesses die FoxProW-Applikation beendet wird und es keine Instanz mehr gibt, die darüber wacht, daß vor der Beendigung des Backups die Applikation nicht erneut gestartet werden darf! Dagegen hilft nach bisherigem Erkenntnis-Stand nur das "Anhalten" der FoxProW-Applikation mit einer entsprechenden Maske sowie das Vertrauen darauf, daß der Nutzer in dieser Maske erst OK drückt, wenn das Backup-Tool wirklich seine Arbeit beendet hat.
Innerhalb der oben erwähnten Spannbreite möglicher Backup-Routinen (vom einfachen XCOPY-Befehl bis zum inkrementellen Server-Backup) liegt natürlich auch der Einsatz von Pack-Programmen als Backup-Tool.
In diesem Zusammenhang besonders zu erwähnen ist der FoxPro-Packer FOXSQZ. FOXSQZ ist ein "normales" Packer-Programm, welches als FoxPro-API-Library (PLB/FLL) vorliegt und die meisten seiner Funktionen nicht nur auf physische Dateien auf der Festplatte sondern auch auf Memofelder anwenden kann. Es wird als Shareware vertrieben und kann aus dem FOXUSER-Forum in CompuServe heruntergeladen werden.
2. Datenschutz
Datenschutz heißt einerseits Schutz vor unbefugtem Zugriff, anderseits auch Schutz vor unbefugter Manipulation von Daten.
Als erstes soll auf entsprechende rechtliche Regeln (Bundesdatenschutzgesetz u.ä.) hingewiesen werden. Welchen Datenschutz-Kriterien eine Software entsprechen muß, sollte immer Vertragsgegenstand zwischen Auftraggeber und Auftragnehmer bzw. auch zwischen Verkäufer und Käufer sein.
Aus softwaretechnischer Sicht hat die Datenschutz-"Medaille" drei Seiten:
Die Nutzer haben differenzierte Rechte bzgl. der Daten. Die Zugriffsmechanismen sind über bestimmte Dialogelemente zu aktivieren. Daten dürfen sich von einem bestimmten Nutzer abrufen lassen oder auch nicht.
Aus den oben erwähnten "drei Seiten der Medaille" ergeben sich drei Zweierbeziehungen:
Für diese Zweierbeziehungen ist immer die grundsätzliche Frage zu klären, wem in der Beziehung werden die Rechte zugeordnet (wird z.B. dem Nutzer zugeordnet, welche Daten er abrufen darf oder wird den Daten zugeordnet, welcher Nutzer sie abrufen darf?). Die Entscheidung für die eine oder andere Variante ist sehr von der vorliegenden Dynamik des Datenbestandes und der Nutzerfluktuation abhängig.
Das Gewähren oder Verwehren von Zugriffsmechanismen (Menüpunkten bzw. Dialogelementen) ist aus programmtechnischer Sicht mit Hilfe von logischen Funktionen oder Variablen unproblematisch realisierbar, wobei die Erweiterungen von Screen- und Menü-Generator GENSCRNX und GENMENUX dabei wertvolle Unterstützung bieten.
Wenn man sich auf die Vergabe von nutzerspezifisch differenzierten Rechten einläßt, lädt man sich allerdings einige Konsequenzen auf:
Die Administrierung der Nutzerrechte erfolgt über spezielle Nutzer, die durch ihre Rechte dazu authorisiert sind.
Ein Login zur Authorisierung eines konkreten Nutzers sollte immer mit der Abfrage eines persönlichen Paßwortes gekoppelt sein. Um im Rahmen eines normalen READ ein unsichtbares Paßwort eintippen zu können, ist folgender Trick möglich:
Der Trick führt dazu, daß der Screen-Generator einen GET-Befehl der Form
@ 1,3 GET xyz MESSAGE "Statuszeilentext" COLOR ,W/W,,,,B/B
generiert.
Die eingesetzten Farbewerte bedeuten:
Anstelle der festen Farben ("W/W" und "B/B") kann man natürlich auch den momentan gesetzten Windows-Standard ermitteln und dann diese Farben verwenden (siehe Programmdatei PASSWORT.PRG und Maske PASSWORT.SCX auf der Begleitdiskette).
Zur Ablage und Speicherung von Paßworten sind folgende Kriterien zu beachten:
Die Verschlüsselung des Paßwortes (oder auch anderer Daten) hat zwei Ziele:
Zum "Unsichtbarmachen" reichen einfache Bit-Verschiebe-Mechanismen aus (siehe die Funktionen SHL() und SHR() in der Programmdatei PASSWORT.PRG auf der Begleitdiskette).
Zum Verschlüsseln von Daten sollte man immer eine Variante mit einem schlüsselabhängigen Algothmus wählen (Verschlüsselungen, die zum ASCII/ANSI-Code jedes Buchstabens nur einen festen Wert hinzuaddieren, sind als unbrauchbar abzulehnen).
Besse geeignet sind z.B. Algorithmen mit statischer oder dynamischer XOR-Verknüpfung unter Nutzung eines variabel vorzugebenden Verschlüsselungs-Keys (siehe die Funktionen STAT_XOR() und DYN_XOR() in der Programmdatei PASSWORT.PRG auf der Begleitdiskette). Gegebenenfalls kann man diese Funktionen dann noch mit SHL() oder SHR() verknüpfen und erreicht damit schon einen hohen Verschlüsselungsgrad.
Zum Schutz vor Manipulationen sollte man verschlüsselte Paßworte, aber auch andere verschlüsselte Daten mit einer Prüfsumme versehen, die nach dem Entschlüsseln Auskunft darüber gibt, ob eine Manipulation vorgenommen wurde. Zu beachten ist allerdings, daß Prüfsummenverfahren immer nur mit Sicherheit ermitteln können, ob eine Manipulation vorgenommen wurde, sie können Manipulationen jedoch nicht mit hundertprozentiger Sicherheit ausschließen (diese Tatsache liegt in den mathematisch-statistischen Grundlagen der Prüfsummenbildung begründet). Die Funktionen PRUEFADD() und PRUEFCHK() in der Programmdatei PASSWORT.PRG auf der Begleitdiskette beinhalten Routinen zum Erzeugen und zum Prüfen einer einfachen Prüfsumme.
Nicht unerwähnt bleiben sollen die Verschlüsselungs- und Paßwortschutz-Möglichkeiten von BACKUP-Tools und Packer-Programmen, die allerdings nicht gegen unauthorisierten Zugriff auf die laufenden und damit ungeschützten Daten verhindern.
Mit Hilfe der erwähnten Verschlüsselungs-Algorithmen hat man natürlich theoretisch die Möglichkeit, komplette Datenbankdateien zu verschlüsseln. Zu diesem Zweck schafft man sich Routinen zum Schreiben von Daten in die Datenbank, die vor den Schreiben die Daten verschlüsseln und verwendet diese Befehle anstelle des üblichen REPLACE-Kommandos. Außerdem benötigt man dann natürlich ein äquivalentes Gegenstück zum Auslesen der Daten aus der Datenbank.
Allerdings birgt dieses Verfahren einige Nachteile in sich:
Umgehen kann man diese Nachteile, wenn man zu einem kommerziellen Verschlüsselungstool greift. Für FoxPro gibt die spezifische Datenverschlüsselungs-Software CRYPTOR des US-amerikanischen Produzenten XITECH. Dieses Produkt ist eine Library, die drei Funtkionen zum Online-Verschlüsseln von jeglichen unter Foxpro nutzbaren Dateien beinhaltet:
Die Einbindung in ein FPD-Programm ist dabei denkbar einfach:
CLOSE ALL
* es folgt das Einbinden der Library
SET LIBRARY TO CRYPT25
* es folgt das einmalige Anmelden einer Datei zum Verschlüsseln
(Paßwort "otto")
=CRYPTFIL("xyz.dbf","otto")
* es folgt das Aktivieren der Verschlüsselung/Entschlüsselung
=CRYPTOR("xyz.dbf","otto")
* es folgt das Öffnen der Datei
USE xyz
* jetzt kann die ganz normale Nutzung der Datei beginnen, z.B.
BROWSE
BROWSE
* es folgt das Schließen der Datei
USE
* es folgt das Deaktivieren der Verschlüsselung/Entschlüsselung
=CRYPTOFF("xyz.dbf")
* es folgt das Öffnen der Datei
USE xyz
* jetzt erzeugt FoxPro den Fehler "Keine
Datenbankdatei", weil die Entschlüsselung deaktiviert ist
* Ende des Beispielprogramms
Die Einbindung in ein Windows-Programm verläuft analog, sie unterscheidet sich nur in unwesentlichen Details.
3. Softwareschutz
Vom Datenschutz nun zum Softwareschutz, bei dem zwei Apekte zu unterscheiden sind:
Die urheberrechtliche Seite ist bei Programmiersystemen mit echten Kompilern eigentlich kein Problem, da ein Re-engineering solcher Software so aufwendig ist, daß es in den meisten Fällen aus Kostengründen gar nicht erst in Angriff genommen wird.
Etwas anders sieht es bei FoxPro als einer Interpretersprache aus. Die foxpro-spezifischen Kompilate (.FXP-, .SPX-, .MPX-, .APP- und .EXE-Dateien) enthalten einen präkompilierten Code, der sich vom eigentlichen Quelltext nur durch Äußerlichkeiten unterscheidet.
Es gibt zwar die Option "Verschlüsseln beim Kompilieren", diese Option ist aber primär zur Vermeidung der Lesbarkeit und des Patchens von String-Konstanten gedacht und stellt keinen wirksamen Schutz dar.
An dieser Stelle sind ein paar Bemerkungen zu dem nicht ganz unumstrittenen Produkt REFOX der Firma XITECH notwendig. Dieses Produkt bietet prinzipiell zwei Funktionen:
Das Schützen vor unerlaubter Dekompilation erfolgt über drei Schritte:
REFOX ist also Lanze und Schild gleichzeitig und produziert damit natürlich einen künstlichen Bedarf nach sich selbst. Andererseits muß man aber durchaus auch ein berechtigtes und juristisch zulässiges Interesse an einer Dekompilation anerkennen (z.B. zur Fehlerbeseitigung in einer Applikation, deren Produzent nicht mehr existiert).
Die lizenzrechtliche Seite des Softwareschutzes ist etwas vielfältiger:
Ideelle Mittel sind einerseits Gesetze und sonstige allgemeingültige Regelungen und andererseits konkrete vertragliche Vereinbarungen in Verträgen oder allgemeinen Geschäftsbedingungen. Dort sollte man stets auf eine saubere Ausgestaltung dieser Problematik achten.
Als vorwiegend hardwaretechnische Mittel des Softwareschutzes stehen drei Gruppen zur Verfügung:
Spezialhardware ist normalerweise überdimensioniert, wenn man eine einzelne Applikation schützen will (außerdem teuer und nicht allzu handlich).
Der Softwareschutz durch Dongle hat zwei Bestandteile:
Die meisten Dongle stellen (auf verschiedenem Niveau) die folgenden Features zur Verfügung:
Bezogen auf die Methoden zur Einbindung der Dongle in die zu schützenden Software existieren drei Varianten:
Die SHELL-Methode ist ein automatisches Ummanteln von EXE-Dateien mit einem speziellen Vorspann, der die Prüfung beinhaltet und bei Fehlern die eigentliche EXE gar nicht erst startet:
Die OBJECT-Methode bedeutet eine individuelle Prüfung des Dongles über Bilbliotheks-Routinen, die in die Applikation integriert werden:
Die DUMMY-Methode besteht in dem Aufruf einer Dummy-EXE aus der eigentlichen Applikation heraus, die Dummy-EXE prüft den Dongle und kehrt dann im Fehlerfall einfach nicht zur aufrufenden Applikation zurück:
Aus Sicht der Zuverlässigkeit des Schutzes ist also für FoxPro nur die SHELL-Methode empfehlenswert, wobei man dort genau prüfen muß, ob sich der konkrete Softwareschutz mit einer von FoxPro erstellten EXE-Datei versteht. Bei einer anderen Interpreter-Sprache (dBASE IV 2.0) trat der Fall auf, daß der Schutz mit der SHELL-Methode hervoragend funktioniert hat, die EXE ihre eigentliche Funktion aber nicht mehr erfüllen konnte.
Die Arbeit mit Dongeln ist nicht ganz unproblematisch:
Die oben erwähnten Dongle-Disketten sind speziell kopiergeschützte Disketten, die im Prinzip wie Dongle arbeiten, wobei die meisten Angebote auf dem Markt sich auf Dongledisketten mit Anwesenheitsprüfung beschränken. Probleme bei Dongledisketten können auftreten bzgl. des Vorhandenseins von Disketten-Laufwerken und im Zusammenhang mit mechanischen Laufwerks-Toleranzen.
Der Softwareschutz mit vorwiegend softwaretechnischen Mitteln ist natürlich auch mit der PC-Hardware verbunden. Erwähnt werden sollen zwei Produkte:
Protection Plus Professional unterstützt die folgenden Features:
Diese Lösung besticht durch ihr gutes Preis-Leistungsverhältnis. Ein Manko ist der nicht vorhandene Kopierschutzschutz für Installationsdisketten.
CopyControl bietet ähnliche Features wie Protection Plus Professional, ist zusätzlich aber mit einem Kopierschutz für Disketten ausgestattet. Allerdings ist das Produkt wesentlich teurer und unter Windows nicht nicht ganz problemfrei.
Für beide Produkte gilt außerdem der schon weiter oben beschriebene Nachteil der offen zugänglichen API-Schnittstelle.
Einsatz des Library Contruction Kit
(c)1994 Sebastian Flucke