-
In den verschiedensten IT-Anwendungen und vor allem Internet-Webseiten können oder müssen sich Benutzer registrieren. Hierzu wird zumeist ein Benutzername (oft die eMail-Adresse) in Kombination mit einem Passwort zur Authentifizierung angegeben. Mit dieser Kombination kann der Benutzer sich später jederzeit wieder einloggen um Zugriff auf seine persönlichen Einstellungen, sein Konto oder die ihm (meist durch vorangegangene oder nachfolgende Bezahlung) zugewiesenen Dienste zu erlangen. Milliarden Menschen haben zum Teil mehrere sogenannte Accounts auf verschiedensten Websites. Allen voran Online-Shop's, eBay etc, Banken, Reiseportalen, App-Anbietern usw. Die jeweiligen (Website-)Server/Anwendungen speichern diese Anmeldedaten/Zugangsdaten (Benutzername und Kennwort) zumeist in Datenbanken entweder in Klartext oder verschlüsselt. Obwohl der Zugriff auf diese Datenbanken durch verschiedene Verfahren geschützt wird, häufen sich in den letzten Monaten erfolgreiche Hacker-Attacken in denen massenweise solche Anmeldedaten erbeutet werden. Aufgrund der einfachen Verschlüsselung und der Masse an erbeuteten Daten lassen sich diese Daten mit etwas Rechenleistung wieder entschlüsseln. In vielen Fällen wird der dazu notwendige Schlüssel ebenfalls erbeutet. Manchmal werden die Daten jedoch auch unverschlüsselt erbeutet, weil die Server-Eigner nicht mit dem Gelingen eines solchen Hacker-Angriffs gerechnet haben. Der resultierende Schaden ist nicht nur für das Vertrauen und Image der jeweiligen Website enorm; Es birgt für die Anwender ein hohes Risiko des Missbrauchs dieser Daten. Da 95% der Anwender diese Anmeldedaten in selber Form mehrfach, d. h. bei mehreren Anwendungen oder Webseiten, benutzen, geht von der Erbeutung solcher Anmeldedaten eine unbezifferbare Bedrohung aus. So kann beispielsweise ein auf einer einfach geschützten Website erbeutetes Passwort genutzt werden um im Namen des Anwenders Einkäufe auf div. Online-Shops zu machen oder Zugriff auf eine vom Anwender genutzte Cloud (Online-Speicher) zu erlangen und damit zu intimen Daten und Bildern oder gar der Zugang zu weitaus sensibleren Anwendungsbereichen wie dem Online-Banking erlangt werden. Dies ist ein massives und teilweise noch stark unterschätztes Risiko unserer Zeit in der sich ein zunehmender Bereich unseres Lebens online manifestiert.
-
Bei der vorliegenden Erfindung handelt es sich um ein mehrschichtiges Verfahren, welches dieses Problem gänzlich beseitigt.
- 1. Es werden die bei der Registrierung (erstmaligen Anmeldung) eingegebenen Passwörter generell NICHT mehr gespeichert.
Vielmehr wird daraus ein deutlich (mind. um 37,5%) verkürzter HASH-WERT gespeichert der sich aus dem eingegebenen Passwort per kryptografischen Einweg-Hashings (OWHF) errechnet – jedoch selbst mit dem zughörigen Algorithmus nicht rekonstruiert werden kann. (OWHF bedeutet One-Way Hash Function und steht für die Erstellung eines Hash-Wertes aus dem selbst bei Bekanntheit des benutzten Verfahrens/Algorithmus/Schlüssels eine Wiederherstellung des Ausgangswertes (Eingabewert) unmöglich ist. Also eine Einweg-Hashfunktion.)
Somit ist schon mal sichergestellt, dass erbeutete Passwörter nicht in anderen Anwednungen/Websites verwendet werden können oder dass daraus kein Klartext rekonstruiert werden kann der es dem Angreifer erlaubt das Konzept das ein Anwender gebraucht um Passwörter zu generieren zu erkennen. Und zwar selbst dann nicht falls es dem Angreifer gelingen könnte, alle nachfolgenden Verschlüsselungen zu brechen und das Hashing zu reversieren.
Hat der Ausgangswert eine Länge von weniger als 16 Zeichen wird er (ggf. mehrfach) mit sich selbst erweitert, bis eine Länge von mindestens 16 Zeichen vorliegt.
Ein Hashing wie CRC-64 sollte ausreichen um die Häufigkeit von Kollisionen vernachlässigbar zu machen. An sich sind solche aber auch nicht problematisch da eine Konto-Verwechslung aufgrund des nicht gehashten (oder zumindest nicht verkürzt gehashten) anwendungseinmaligen Anmeldenamens ausgeschlossen ist und es gibt ohnehin eine große Anzahl an Passwörtern die von Millionen Anwendern gleichermaßen benutzt werden.
- 2. Da Hash-Verschlüsselung aber durchaus zu knacken* ist, muss ein zusätzlicher (z. B. 192-Bit-) Schlüssel (MASTER-KEV) die Hash-Werte oder auch weitere sensible Daten (die jedoch im Gegensatz zum Passwort komplett wiederherstellbar sein müssen – wie z. B. der Anmeldename – und daher nicht derart gehasht werden können) verschlüsseln. Hierfür würde sich aus heutiger Sicht eine AES-Verschlüsselung anbieten; also z. B. AES-192 mit höchstmöglicher Rundenzahl, mindestens 12, besser 16. Das vorliegende Schutzverfahren ist aber grundsätzlich vom darin verwendeten kryptografischen Verschlüsselungsverfahren selbst unabhängig. Dieses kann mit fortschreitender Zeit und Technik angepasst werden so dass hier jeweils ein solches Verwendung findet dass zu der jeweiligen Zeit als sicher (und zukunftssicher) gilt. Selbiges gilt für die Schlüsselbreite. Je nach Sensibilität der Daten kann die Mindestgröße von 128 Bit z. B. auf 192, 256, 512, 1024 Bit oder weiter erhöht werden. Letztlich ist es nur eine Frage der Rechenpower. Dieser Master-Key muss im Gegensatz zu dem Hash-Algorithmus individuell zu der jeweiligen Anwendung sein. Er kann z. B. beim Installationsvorgang aus einer Programm-Seriennummer oder aus den Hardware-Daten des PC's (inkl. div. Seriennummern und Prozessor-ID's) oder aus einer z. B. 58-stelligen Zufallszahl evtl. in Kombination mit einem Unique-Key der in den Programmcode implementiert wurde generiert werden. Es wäre denkbar, dass sich die Anwendung oder der Anwender diesen bei der Registrierung bzw. nach der Installation vom Hersteller bzw. dessen Registrierungsserver zuweisen lässt. Auch eine Generierung aus einem Hardwarebaustein (Hardwareerweiterung It. Anspruch 8) zur Erzeugung von Schlüsseln/Zufallszahlen oder mit Hilfe von zufälligen Mausbewegungen des Anwenders wäre praktikabel. In der Praxis wird es wohl eine Kombination aus diesen Methoden sein.
Zuätzlich muss dieser Master-Key an einer Stelle untergebracht sein, die nur der zuständigen Chiffrierungssoftware zugänglich ist. Dies könnte ein versteckter Bereich/Unterordner sein zu dem nicht einmal der Administrator und das System selbst Zugriffsrechte hat, aber das wäre nicht sonderlich sicher. Da der Master-Key dem Anwender bekannt sein oder auf einem Notfallmedium (verschlüsselt) gesichert sein muss um z. B. für den Fall eines Hardware-Ausfalls das komplette System oder ein Backup wieder herstellen zu können, wäre es auch praktikabel, wenn dieser Master-Key nach jedem Systemneustart vom Anwender eingegeben wird und er somit garnicht auf Festplatte etc. gespeichert ist. Kann bei Systemen z. B. aufgrund Redundanz ein Hardware-Ausfall/Absturz ausgeschlossen werden, kann auf die Mitteilung des Master-Key sogar gänzlich verzichtet werden. (Siehe auch Ausführungen zum Thema Backup) Der Master-Key ist dann nur im Arbeitsspeicher abgelegt und dort entsprechend versteckt wie die weiteren Ausführungen beschreiben. Der Vorteil liegt darin, dass ein Missbrauch durch Menschen die Zugriff zum System haben, ausgeschlossen ist.
*) „knacken” bedeute hier – da wir ein verkürztes Einweg-Hashing anwenden – nicht die Wiederherstellung des Quellwertes sondern die Erzeugung eines Pseudo-Quellwertes der unter dem selben Hashing (selbes Verfahren, selber Algorithmus, selber Schlüssel) zu dem selben Ergebnis (Hash-Wert) führt und somit eine Prüfung positiv durchläuft.
Aber auch eine zusätzliche Verschlüsselung bietet vor allem auf Dauer keine 100%-ige Sicherheit. Wie sich in der Vergangenheit immer wieder gezeigt hat, werden als sicher geltende Systeme nach oft nur kurzer Zeit doch geknackt. Zwar kann auch damit das ursprüngliche Passwort aufgrund des in 1. genannten verkürzten Hashings nicht sicher wiederhergestellt werden (womit die Gefahr für den Anwender faktisch auf das attakierte Portal begrenzt ist), doch ein Angreifer könnte somit unberechtigten Zugriff auf die angegriffene Website/Anwendung haben. Um dieses Rest-Risiko weiter zu minimieren, folgen die nächsten Schritte.
- 3. Der unter 2. verwendete Master-Key wird, bevor er zur Verschlüsselung von Passwörtern (Hash-Wert aus 1.) eingesetzt wird, ARITHMETISCH BEARBEITET. Als Basis dafür dient u. a. der sog. Unique-Key (die einmalige Ordnungszahl) des jeweiligen Datenbanksatzes, eine Datenfeldnummer sowie eventuell anderweitige Daten dieses Datensatzes (z. B. Anmeldename, Klarname oder Geburtsdatum) bzw. ein stark reduzierter Hashwert davon. Gut geeignet ist z. B. der Ausgangswert des Anmeldenamens, der als wichtigstes Such-Datenfeld mit dem unbearbeiteten Master-Key (und Zeitschlüssel, siehe 4.) verschlüsselt wird da ansonsten eine Suchanfrage an die Datenbank unmöglich oder zumindest sehr zeitaufwendig wäre. Abgesehen vom Einbringen der Datenfeldnummer wird für jedes zu verschlüsselnde Datenfeld eine etwas andere Funktion zur Bearbeitungs des Master-Key angewendet und die Daten jeweils anderer Datenfelder einbezogen sodass Manipulationen durch Tausch der Datenfelder zu keiner gültigen Dechiffrierung führen. Aufgrund der arithmetischen Bearbeitung ist eine Mustererkennung-Kryptoanlyse für diese Daten auszuschließen. Man könnte die Sicherheit nochmals steigern in dem man für nur zweifach verschlüsselte (suchbaren) Datenfelder einen anderen Master-Key verwendet als für die Verschlüsselung der Passwörter oder ähnlich sensibler Datenfelder, doch wir reden hier von ein paar hundert Jahren Analysezeit mehr oder weniger, nach heutigen Stand der Technik.
Als arithmetische Berechnung kann beispielsweise bei einem 128-Bit-Schlüssel eine einfache Multiplikation des Unique-Key's mit dem zweiten Wort des Master-Keys multipliziert mit 12, eine Multiplikation der Datenfeldnummer mit dem siebten Wort und eine Addition des fünften Wortes mit dem stark (auf 16 Bit) reduzierten Hashwert des Anmeldenamens als ausreichend betrachtet werden. Aber hier können auch viele weitere Kombinationen und Methoden Anwendung finden, wie z. B. eine Bit-Verschiebung oder eine weitere Verschlüsselung; wobei letzteres die Handhabung unnötig verzögert. Die dafür verwendete Funktion/Formel sollte möglichst anwendungsindividuell sein. D. h. sie wird entweder bei der Installation (zufällig) vom Installationsprogramm erzeugt oder vom Anwender vorgegeben.
Diese Funktion muss dem Anwender bekannt sein oder auf einem Notfallmedium (verschlüsselt) gesichert sein, falls die Möglichkeit von Hardware-Ausfällen/Abstürzen nicht abgesichert ist. Auch sollte ein Backup inklusive dieser arithmetischen Bearbeitung erfolgen.
Somit ist gewährleistet daß jeder Datensatz mit einem etwas anderen Schlüssel (Master-Key) verschlüsselt wird, was eine Muster-Erkennung, wie sie zum Errechnen bzw. Hacken des Schlüssels erbeuteter Daten eingesetzt werden kann, nahezu ausschließt und einen möglichen Angriff auf das extrem zeitintensive Brute-Force (das systematische durchprobieren aller möglichen Schlüssel) beschränkt.
- 4. Um jegliche Angriffe (insbesondere die eben erwähnte Brute-Force und Kryptoanalyse) nach heutigen Stand unmöglich zu machen wird der zuvor generierte Code (Master-Keyverschlüsselte(Hash-)Werte) zusätzlich nochmals mit einem ZEITSCHLÜSSEL verschlüsselt. Dabei sollte ein anderes Verschlüsselungsverfahren (z. B. Twofish oder Blowfish) angewendet werden wie es mit dem Master-Key verwendet wurde. Dieser mindestens 128 Bit breite Zeitschlüssel wird in regelmäßigen Abständen (z. B. maximal täglich besser stündlich (wenn genug PC-Leistung bereit steht um die somit notwendige Dechiffrierung-Chiffrierung in angemessener Zeit durchzuführen) neu erstellt. Er wird entweder als Zufallszahl generiert oder aus einer speziellen Hardwareeinrichtung gewonnen. Dabei kann eine Mehrfacherzeugung oder eine mathematische Funktion benutzt werden um die benötigte Größe (Bitbreite) zu erzielen. Wichtig ist, dass er nicht vorhersehbar ist. Zusätzlich sollte der Zeitpunkt zu dem er erzeugt wird eine gewisse Variabilität haben, die wiederum per Zufall festgelegt wird. Es kann beispielsweise im groben ein 60 Minuten Zeitfenster vogesehen werden welches defacto immer wieder neu bestimmt wird indem jedesmal eine Zufallszahl von 1 bis 600 zu 3300 (55·60) addiert wird und so die Sekunden des nächsten Zeitpunktes zum Erzeugen eines neuen Zeitschlüssels und der dazugehörigen Umchiffrierung der (Anmelde-)Daten festlegt, wobei die Zeit zwischen den Umchiffrierungen dann zwischen 55 und 65 Minuten schwankt. Damit wird ein evtl. erbeuteter Zeitschlüssel in Kürze wertlos und jeglicher Angriff direkt auf dem Datenbankserver erhält eine zeitliche Brissanz die es einmal mehr unmöglich machen dürfte zum Erfolg zu kommen.
Die Erzeugung mit Hilfe einer speziellen Hardware-Einrichtung zur Erzeugung von Zufallszahlen und/oder zufälligen Schlüsseln wie es z. B. mit Hilfe von Trusted Platform Module (TPM) möglich ist, wäre am Besten sofern ausgeschlossen werden kann dass der dort generierte Schlüssel irgendwo abgefangen/”mitgehört” werden kann. Am effektivsten ist insofern eine Kombination verschiedener Methoden.
So werden alle Passwörter (und evtl. weitere Daten) regelmäßig per gültigen Zeitschlüssel dechiffriert und mit dem neuen sofort wieder chiffriert. In der Praxis wird so eine Umchiffrierung je nach Datenbankgröße und Rechenleistung evtl. im Hintergrund bzw. etappenweise laufen können und nach Beendigung werden dann nur die entsprechenden Datenbankfelder getauscht.
Ein Online-Angriff ist somit aufgrund der jeweils kurzen Zeitfenster unmöglich und wenn die komplette (verschlüsselte) Datenbank erbeutet wird, dürfte deren Dechiffrierung aufgrund der drei- bis vier-fachen Verschlüsselungstiefe als (zeitlich) unrealistisch angesehen werden, denn das Ergebnis aus dem Hackversuch mit Verfahren 2 – Zeitschlüssel – bringt keinen Klartext der dem Angreifer zeigen könnte, dass er sein Teilziel erreicht hat und es gibt – auch aufgrund der arithmetischen Bearbeitung und der unterschiedlichen Verschlüsselungsverfahren – keinen einzelnen Schlüssel mit dem die gesamte Datenbank dechiffriert werden kann. Die Möglichkeiten steigen von 2 hoch 128 (eine 38 stellige Zahl) auf (2 hoch 128) hoch 128, einer Zahl mit 4933 Stellen. Würde jede Berechnung nur 1 PikoSekunde (1 millionstel Mikrosekunde) dauern, wäre ein Computer damit 4 e 4912 Jahre beschäftigt wobei das Weltall erst seit 1,4 e 10 Jahren besteht.
Nun bestünde theoretisch nur noch die Gefahr dass die Schlüssel (Masterkey und Zeitschlüssel) trotz aller üblichen Vorsichtsmaßnahmen (womöglich zusammen mit den zugehörigen (mehrfach verschlüsselten) Daten) erbeutet werden. Aus diesem Grund folgt die nächste/letzte Sicherheitsstufe.
- 5. Es gibt bislang 2 Schlüssel im System. Den Master-Key und den Zeitschlüssel. Um sicherzustellen, dass diese Schlüssel nicht erbeutet werden können, werden sie generell defacto nicht gespeichert, – weder auf Festplatte noch im Arbeitsspeicher. Statt dessen werden sie mit einem Wert verschlüsselt der sich aus einem zukünftigen Zeitwert des Systems errechnet, z. B. die Systemzeit in Mikrosekunden (durch einen anwendungsspezifischen Algorithmus mit sich stets wechselnden (Zufalls-)Parametern zu einem 128 Bit-Schlüssel hochgerechnet). Nur der sich jeweils daraus ergebende FUTURE-KEY wird gespeichert. Doch dieser ist zunächst unbrauchbar und kann nur zu einer ganz bestimmten Zeit die 0,5–2 Sekunden in der Zukunft liegt mit dem dann gegebenen System-Zeitwert (oder Timer-Wert – siehe weiter unten) in den ursprünglichen Zeitschlüssel und Masterkey umgewandelt werden.
Erst dann kann mit diesen Schlüsseln wieder Chiffrierungs- und Dechiffrierungsaufgaben vorgenommen werden. In der Zeit bis dahin werden anstehende Chiffrierungsaufgaben in eine Warteschlange gestellt. Sie werden dann von einem Unterprogramm abgearbeitet das per Timer (dieser muss die im System höchste Priorität haben) aufgerufen wird. Der Timer wurde bei Erzeugung der Future-Key's gleich mit gesetzt und darf nach dem Setzen weder verändert noch ausgelesen werden können, bis er abgelaufen ist. Auch muss darauf geachtet werden, dass vom Ablaufdes Timers bis zum Anlauf des Unterprogramms eine gewisse (wenn auch minimale) Zeitspanne vergeht. Dies muss durch eine entsprechende Fehlerkorrektur aufgefangen werden. Aus diesem Grund läuft der Timer nach seinem Auslösen weiter so dass das Timer-Unterprogramm die erfolgte Zeitverzögerung messen und ausgleichen kann. Zur weiteren Fehlerkorrektur (z. B. durch unkalkulierbare Überläufe der kleinsten Stelle der Zeitangabe) wird von Masterkey und Zeitschlüssel ein maximal 16 Bit breiter Prüfziffern-Hash gespeichert.
Zur Messung der Zeitverzögerung muss der Timer nach seinem Ablauf bzw. Auslösens, eine bstimmte Zeit (die das System benötigt um die ausgelöste Interruptanforderung auszuführen und das Timer-Unterpgrogramm startet, also z. B. 150 Prozessortakte, die für die Timer-Hardware z. B. per DIP/DIL-Schalter IC festgelegt werden) auslesbar sein. Um zu vermeiden, dass ein Schadprogramm diese kurze Auslesbarkeit ausnutzt sollte dieser Timer einen Alarm auslösen bzw. das System anhalten falls vor dem Ablaufdes Timers oder nach dem ersten Auslesen ein Programm versucht diesen auszulesen. Ferner ist der Timer nur ein einziges mal pro Phase (Start-Ablauf-Neustart) auslesbar und hält nach dem Auslesen an. Die gelesene Nachlaufzeit ist somit nur dem Timer und dem Timer-Unterprogramm bekannt und kann genutzt werden um damit die neu zu setzende Timerzeit arithmetisch zu verschlüsseln. Dadurch kann diese neue Zeit X nicht anderweitig abgefangen werden bzw. wäre dann nutzlos. Als zusätzliche Sicherheitmaßnahme löst die Timer-Hardware Alarm aus wenn sie nicht binnen einer bestimmten Zeit nach dem Auslösen erneut gestartet wird. Um Adressmanipulationen vorzubeugen prüft die Timer-Hardware ob die Schreibbefehle tatsächlich aus dem Adressbereich des Timer-Unterprogramms erfolgen. Auch erfolgen diese Schreibbefehle so direkt wie möglich und ohne dazwischengeschaltete Treiber oder ähnlichem. Ist dies systembedingt nicht möglich muss die Integrität der jeweiligen Treiber zusätzlich sichergestellt werden.
Sollte ohne Timer mit diesem Leistungsumfang gearbeitet werden, so ist die zu verwertende Zeitangabe in einem genug großen Bereich zu wählen so dass die Fehlerkorrektur auch ohne Verzögerungsinformation die korrekten Schlüssel wieder herstellen kann. Geht man beispielsweise von einer Taktrate von 5 GHz aus, dann entstehen bei 150 Taktraten Verzögerungen von ca. 30 ns, woraus sich eine Verwendung aller Zeitangaben kleiner als 100 ns ausschließt. Da die meisten Systemzeitangaben ohnehin den Mikrosekundenbereich nicht unterschreiten, wird sich dieses Problem in der heutigen Prasxis erübrigen.
Am Ende des Timer-Unterprogramms wird/werden der/die Future-Key(s) wieder neu erzeugt, der Timer gesetzt und der Zeitschlüssel/Master-Key gelöscht. Die Zeitspanne bis zum nächsten Timer-Event muss stets eine gewisse Variabilität haben um nicht vorhersehbar zu sein. Hierzu wird ähnlich wie bei dem Zeitintervall zum Erzeugen des Zeitschlüssel z. B. bei einer 2-Sekunden-Intervall-Vorgabe der neuen Zeit X eine 30%-ige zufällige Varianz hinzu addiert oder abgezogen sodass die neue Zeit X dann tatsächlich beispielsweise in 1,4 bis 2,6 Sekunden gegeben ist.
Zur Erzeugung eines sicheren Future-Key wird der jeweilige Schlüssel (Masterkey/Zeitschlüssel) mit einem mind. 128-Bit-Schlüssel verschlüsselt der sich aus einem anwendungsspezifischen Algorithmus mit stets wechselnden zum Teil per Zufallszahl bestimmten Parameter erzeugt. Die Einbindung eines TPM oder eines auf der Hardwareerweiterung installierten Verschlüsselungsdienstes wäre zusätzlich hilfreich. Um einen Brute-Force-Angriff in diesem Bereich zu vereiteln muss die Verschlüsselungstechnik hier so aufwendig gewählt werden dass die Dechiffrierung aus Computersicht extrem lange braucht. Der eingesetzte Computer sollte je nach Leistungsstärke etwa 100–500 Millisekunden dafür benötigen. Geht man von einem hochwertigen System aus so dürfte ein High-End-System zumindest auch 1–10 Millisekunden benötigen. Hierzu wird zunächst eine übliche Verschlüsselung eingesetzt und anschließend weitere mathematisch komplexe Berechnungen durchgeführt. Da das Radizieren als eine der aufwendigsten Berechnungen gilt, kann hier mit vielstelligen komplexen Potenzen gearbeitet werden. Ggf. mehrfach verschachtelt.
Ferner wird der Future-Key des Masterkey's (MK) hochgradig versteckt. Es darf nicht möglich sein, den dafür verwendeten Datenträger komplett zu erbeuten innerhalb 1/100 der Zeit in der ein Zeitschlüssel Gültigkeit hat. Geht man beispielsweise von einem Zeitrythmus für die Erneuerung des Zeitschlüssels von 1 h und von einer bestenfalls (in dem Fall schlimmstenfalls) durchschnittlichen Downloadrate von 100 Mbit/Sek. aus so muss der Datenträger in dem der MK-Future-Key in einer Matrix ähnlicher Schlüsselwerte mit größtenteils übereinstimmenden 16-Bit Hashwerten (Prüfsumme, siehe oben) versteckt ist mindestens 5 TB groß sein. Natürlich erhöht sich die Sicherheit weiter wenn das Versteck für den MK-Future-Key zudem auf verschiedene Geräte verteilt wird, wobei damit verschiedene Speicher des Systems (nicht der Arbeitsspeicher in dem auch der Zeitschlüssel-Future-Key gespeichert ist) gemeint sind aber auch Speicher anderer Systeme die u. a. per Netzwerk angebunden sind oder sichere (Cloud-)Server im Internet. Beim Speichern auf Festplatte wird hier idealerweise der sog. Direktzugriff angewandt um den FK irgendwo abzulegen ohne dass das Filesystem einen Hinweis darauf vermerkt. Denkbar wäre auch die Aufsplittung auf mehrere Geräte. Damit das Datenschutz-System den MK-Future-Key wieder finden kann wird der genaue Ort des Verstecks in einem Zeiger gesichert welcher wiederrum mit dem Zeitschlüssel verschlüsselt wird.
Sofern mit der Hardware-Erweiterung gearbeitet wird, können zusätzlich die o. g. stetig wechselnden Parameter die als Basis für den anwendungsspezifischen Algorithmus dienen mit dem aus der zukünftigen Systemzeit der 128-Bit-Schlüssel zur Erzeugung der Future-Key's erzeugt wird aus dem Arbeitsspeicher gelöscht werden nachdem diese Parameter (die zusammen mindestens 128 Bit haben müssen) als Pseudo-Zeit-Vorgabe in den 128-Bit-Timer programmiert wurden. Der Timer läuft dann nicht gegen 0 sondern gegen eine Pseudeo-Zeit + X die dem Timer-Unterprogramm die Parameter liefert die es zusammen mit der Systemzeit benötigt um die Future-Key's wieder zu dechiffrieren. Alternativ kann der Schlüssel zur Chiffrierung von MK und Zeitschlüssel zu Future-Key auch eine 128-Bit-Zufallszahl sein die dann in dem Timer als Ziel (Alarmzeit) gegeben wird. Nun wird als Startzeit diese Zufallszahl + X vorgegeben und die Zufallszahl gelöscht. So ist sicher gestellt dass der Timer in X Zeit auslöst und an das damit gestartete Timer-Unterprogramm genau den Schlüssel übergibt der nötig ist um aus den Future-Key's wieder die ursprünglichen Schlüssel zu gewinnen.
Da der Timer nicht auslesbar ist und nur nach dem Auslösen einmalig seinen Inhalt an das Timer-Unterprogramm (und nur an dieses) preisgibt, ist der Schlüssel zur Dechiffrierung der Future-Key's schlichtweg nicht verfügbar. Wird ohne Hardwareerweiterung und somit mit einem Standard-System-Timer gearbeitet die zumeist nur 64 Bit haben dann ist der Future-Key unter Umständen angreifbar. Allerdings ist dann aufgrund der besonders aufwendig gewählten Dechiffrierung von einer Zeitverzögerung auszugehen in der der so erbeutete Zeitschlüssel längst seine Gültigkeit verloren hat. Zudem ist der MK-Future-Key erst nach erfolgreich geknackten Zeitschlüssel(-Future-Key) zu finden doch bis dahin ist er schon längst woanders, da sich dessen Aufenthaltsort ca. alle 2 Sek. ändert. Das komplette Entwenden aller möglichen Aufenthalstorte des MK-Future-Key scheidet aufgrund der enormen Größe und Vielfalt dieser mbglichen Verstecke (vor allem in der Zeit X, beispielsweise 2 Sek.) aus. Nach der Zeit X werden beide Haupt-Schlüssel bereits wieder mit einem neuen Schlüssel zu neuen Future-Key's chiffriert. Es ist also aufgrund der Größe der möglichen Aufenthaltsorte nicht möglich beide Future-Key's zu erbeuten so dass beide mit dem selben Schlüssel erzeugt wurden. Dies Wiederrum verursacht notwendige Tests von 1 e 1233. Unmöglich. Um den MK-Future-Key zu finden wäre es unumgänglich den dafür hinterlegten Zeiger zu dechiffrieren. Dafür müsste aber aus dem Zeitschlüssel-Future-Key erst mal der Zeitschlüssel gewonnen werden. Doch dies ist auch bei nur 64-Bit-Timer-Werten in dem dafür notwendigen Zeitfenster von ca. 2 Sekunden (Zeit X bis zum nächsten Timer-Event) selbst mit Supercomputern aufgrund der besonders aufwendigen Dechiffrierung undenkbar. Diese Komplexität kann übrigens an die wachsende Rechenleistung stetig angepasst werden so dass es auch in 100 Jahren unmöglich sein wird diesen Schlüssel in 2 Sekunden zu knacken. Wobei dann aus den 2 Sekunden wohl auch schon längst 0,0002 Sekunden geworden sind.
Die einhergehende Verzögerung der Anmeldung dadurch dass im Durchschnitt erst in 1,2 Sekunden die Anmeldedaten geprüft oder gespeichert werden, fällt (vor allem im Internetverkehr) nicht ins Gewicht da sie für jeden Anwender nur einmalig bei Anmeldung auftritt. Werden mit dem Verfahren auch weitere Daten verschlüsselt so ist die Intervall-Vorgabe kürzer zu wählen (z. B. 0,2 Sek).
Es wird somit nur der bzw. zwei Future-Key(s) im System gespeichert mit denen man (falls erbeutet) nichts anfangen kann da er/sie erst zur Zeit X gültig wird/werden. Der aus dieser Zeit-X-Dechiffrierung zu gewinnende Zeitschlüssel mit dem eine Dechiffrierung der Daten möglich wäre, ist nicht bekannt und niergends im System gespeichert, ebenso ist der ebenfalls notwendige Master-Key im System nicht vorhanden. Mit den Future-Keys selbst lassen sich die Daten jedoch nicht dechiffrieren sondern nur der Zeitschlüssel und Master-Key erzeugen aber eben auch nur zur Zeit X. Die Zeit zu der diese Future-Keys Gültigkeit erreichen, wird ebenfalls nicht gespeichert sondern direkt in einen Timer (zumindest High Precision Event Timer (HPET)) programmiert. Dieser sollte idealerweise ein NMI(Not maskable Interrupt)-Timer sein bzw. einen NMI auslösen und die erste Aktion des Timer-Unterprogramms besteht darin, andere Interrupts und Threads zu unterbinden so dass während der Abarbeitung dieses Unterprogramms kein anderes Programm (parallel) abgearbeitet wird.
Um die oben beschriebene Funktionalitäten (z. B. Unlesbarkeit bis zum Auslösen) des Timers zu gewährleisten kann dieser als Spezial-Timer auf einer HARDWAREERWEITERUNG dem System zur Verfügung gestellt werden. Der Timer sollte 2 128-Bit-Register haben. Eines für die Startzeit und eines für die Alarmzeit. Die Zeitauflösung sollte wenigstens 1 Nanosekunde (ns) sein, möglichst 1 Pikosekunde (ps), wenngleich dem Erfinder aktuell keine so schnell zählenden Timer-Chips bekannt sind, sollten stets die technisch hochauflösendsten Timer der jeweiligen Zeit Verwendung finden.
Diese Hardwareerweiterung könnte zusätzlich eine Funktion zur hardwaremäßigen Zufallszahlerzeugung beinhalten.
Ferner könnte hier z. B. auf einem Eeprom (oder einem anderen nichtflüchtigen Speicher der nur per hardwareseitigen Eingriff zu beschreiben/zu ändern ist) die Software zur Chiffrierung und Dechiffrierung inkl. dem o. g. Timer-Unterprogramm untergebracht sein. Idealerweise blendet sich dieser Speicher in einem bestimmten Speicherbereich des Arbeitsspeicher des Systems ein (ähnlich dem ROM/Flash für Bios) oder die Software wird daraus geladen und regelmäßig damit verglichen, sodass Manipulationen des Programmcodes ausgeschlossen sind. Ein Update der Software ist nur möglich wenn auf der Hardwareerweiterung(-skarte) z. B. ein Knopf gedrückt wird oder bei Verwendung eines Eproms dieses per UV-Emitter gelöscht wird. Natürlich ist auch ein sonstiger nichtflüchtiger Speicher denkbar wenn sein Beschreiben hardwareseitig blockiert wird bis z. B. der Systemadministrator der ein Update einspielt hierzu eine Taste betätigt oder einen Jumper setzt, wobei sichergestellt sein sollte dass die Beschreibbarkeit nach Ausführen des Updates oder zumindest nach einer gewissen Zeit (z. B. 15 Minuten) automatisch wieder deaktiviert wird, falls es von Seiten des Anwenders vergessen wird. Damit während dieses Schreibvorgangs Manipulationen (z. B. mit einem Rootkit/Bootkit) ausgeschlossen sind, könnte das Update eines solchen Speicherbausteins auch auf einem anderen System ausgeführt werden, welches standardmäßig nicht am Netzwerk angebunden ist. Selbstverständlich kann als Updateprogramm nur eines vom Hersteller der Chiffrierungssoftware verwendet werden welches die Integrität des erfolgten Updates mehrfach vergleicht.
Diese Hardwareerweiterung sollte ferner prüfen ob der zum Aufruf des Timer-Unterprogramms zuständige Interrupt-Zeiger (dieser ist typischerweise in einer Interrupt-Tabelle des Systems gespeichert) manipuliert wurde. Dies geschieht z. B. indem die Hardware prüft, ob kurz (Bereich von ca. 10–150 Prozessor-Taktzyklen) nach dem Auslösen des Timers der Prozessor auch tatsächlich in dem Speicherbereich arbeitet in dem das Timer-Unterprogramm gespeichert ist. Damit bei nicht redundanden Systemen die Zeitschlüssel vor Verlust durch einen System-/Hardware-Fehler/-Neustart geschützt sind, können diese (ohne Future-Key-Chiffrierung) auf der o. g. Hardwareerweiterung (z. B. auf einem Flash-Speicher) gesichert werden, wobei diese Sicherung bzw. der Transfer zum Flash-Speicher ebenfalls nur verschlüsselt erfolgt mit Hilfe der angehaltenen Timer-Zeit die nur dem Timer (und somit der Timer-Hardwareerweiterung) und dem Timer-Unterprogramm bekannt ist und wobei das Auslesen dieses speziellen Flash-Speichers grundsätzlich gesperrt ist und nur mit zusätzlichen vorort am System auch hardwaremäßig zu erfolgenden Sicherheitsmaßnahmen möglich ist. Idealerweise wird ferner die Hardwareerweiterung vor Diebstahl geschützt, was u. a. mit Bindung an das jeweilige System (inkl. CPU-ID) erfolgen kann.
Als zusätzliche Sicherheitsmaßsnahme und vor allem wenn systembedingt die direkte Ausführung des auf Eeprom befindlichen Programmcodes dort nicht möglich ist oder ohne Hardwareerweiterung gearbeitet wird, prüft ein oder mehrere weiteres/weitere Programm/e und/oder die Hauptanwendung regelmäßig (in sehr kurzen Abständen < 0,05 Sek.) ob es ggf. Manipulationen am Interrupt-Zeiger oder der im Arbeitsspeicher aktiven Software gab und löst notfalls Alarm aus und hält ggf. das System an. Dies könnte entweder durch kompletten oder stichpunktartigen Vergleich der im Arbeitsspeicher befindlichen (Chiffrierungs-)Programme mit den Programmdaten auf dem Eeprom oder durch Prüfziffer-Hashing erfolgen.
Um bei fortschreitenden Multi-Threadding zu verhindern dass ein Schadprogramm den vom Timer-Unterprogramm dechiffrierten Masterkey/Zeitschlüssel aus dem Arbeitsspeicher erbeutet sollte dieser nur auf der bereits mehrfach erwähnten Hardwareerweiterung zwischengespeichert werden die dann wiederrum nur Lesezugriffe vom Timer-Unterprogramm aus zulässt. Alternativ oder in Kombination damit werden die dechiffrierten Masterkey/Zeitschlüssel an stets unterschiedlichen Stellen innerhalb einer SPEICHER-ZUFALLSMATRIX abgelegt. Hierzu wird am Anfang des Timer-Unterprogramms ein größerer (z. B. 16 MB in einem 64-Bit-System) geschützter Speicherbereich mit Zufallszahlen gefüllt und per Zufall bestimmt wo in diesem Bereich genau der Schlüssel abgelegt wird, wobei er nie als ganzes sondern in vorzugsweise 16 Teile aufgesplittet gespeichert wird und die Position jedes dieser Teile vom Zufall bestimmt wird. Dabei müssen die Zufallszahlen so gewählt werden, dass sich (angewandt auf die selbe Bitlänge des Schlüssels also z. B. 128 Bit ebenfalls aufgeteilt in 16 Teile) die zur o. g. Fehlerkorrektur vermerkte 16-Bit-Hash-Prüfziffer vielfach (> 200000, 25–50%) ergibt. Ferner werden die Zeiger welche auf den so versteckten Masterkey/Zeitschlüssel bzw. deren 16 Teile zeigt in zwei (je einem) QWords (64-Bit) codiert. Bei einer Aufsplittung in je 8 Teile reicht auch ein einziges QWord. Dieser enthält mehrere Zufallswerte wodurch eine Errechnung der jeweiligen Postition unmöglich sein dürfte oder zumindest so lange dauert dass zumindest der dann erbeutete Zeitschlüssel längst ungültig ist. (Was jedoch nichts nützt wenn Datenbank und Matrix erbeutet wurden und in aller Ruhe mit z. B. einem Hochleistungsrechner-Verbund (> 100 TFlops) gehackt werden, weshalb bei sensiblen Daten die Aufteilung auf 8 Teile in 1 QWord nicht empfohlen wird.) Diese QWords werden, während des Timer-Unterprogramm und somit während der Nutzung von Masterkey/Zeitschlüssel (bevor sie wieder gelöscht werden) nur in Prozessorregistern abgelegt so dass sie von Programmen eines anderen Prozessors nicht gelesen werden können. Abgesehen von den Prozessorregistern ist nur noch der Prozessorstack als kurzzeitiger Zwischspeicherort für eines der QWord-Offset-Codes zulässig, wobei es dann vorher mit dem jeweils anderen Schlüssel (den Schlüssel auf den das andere QWord zeigt) oder der Hardwareeinrichtung verschlüsselt wird. Als zusätzliche Sicherung kann ein derartiger Zwischenspeicherort (der Stack ist ja zumeist Teil des normalen Arbeitsspeicher) aus Gründen der Verwirrung in hoher Frequenz per Zufallszahlen in 64-Bit-Größe belegt werden.
Hilfreich könnte auch sein, wenn das System, welches die Chiffrierung bzw. Dechiffrierung bzw. Prüfung der (Anmelde-)Daten bzw. deren Speicherung vornimmt, während seiner Chiffrierungs-Aktivität, insbesondere während der Umchiffrierung und dem Abarbeiten des Timer-Unterprogramms vom Netzwerk getrennt wird, bzw. sich vom Netzwerk trennt. Dies könnte softwareseitig oder für eine größere Sicherheit und Schnelligkeit hardwarseitig geschehen. Vorstellbar ist hier eine spezielle Funktion/Erweiterung der Netzwerkkarte bzw. deren Anbindung ans System um die Umschaltung innerhalb von Millisekunden zu ermöglichen.
In jedem Fall sollte bei dem ausführenden System die sog. Speicher- und Prozessor-Dump-Funktion deaktiviert sein und auch nicht aktivierbar sein. Auch für den Fall eines Prozessorfehlers/Absturz.
Falls bei Betrieb ohne Hardwareerweiterung die Integrität der verwendeten Programme und der Interrupt-Tabelle somit nicht sichergestellt werden kann, sollte stattdessen zumindest ein Trusted Platform Module (TPM) verwendet werden um die Integrität des Systems zu erhöhen.
-
Zwar wäre die generelle Verschlüsselung per TPM ebenfalls möglich und somit wäre auch sichergestellt dass der Schlüssel nicht ohne weiteres erbeutet werden kann sofern hierfür der Endorsement Key verwendet würde da dieser (der private Teil) ausschließlich dem TPM bekannt ist, doch wäre aufgrund dessen dass dieser immer gleich ist, ein Angriff z. B. per Mustererkennung durchaus denkbar und je nach Rechenleistung womöglich sogar in vertretbarer Zeit. Zusätzlich besteht noch das Problem bei einem Hardware-Defekt und die direkte Nutzung der TPM-Verschlüsselung zur Krypto-Analyse des Schlüssels. Insgesamt würde der Funktionsumfang eines TPM für den Großteil der hier vorliegenden Sicherheitsmechanismen. nicht ausreichen.
-
Gibt ein Anwender nun nach erfolgter Registrierung seine Anmeldedaten ein um Zugang zu der jeweiligen Website bzw. seinen erworbenen Diensten zu erlangen, so werden diese Anmeldedaten-Anfrage zunächst in eine Warteschlange gestellt. Bei Auslösen des Timers wird das eingegebene Passwort nach dem o. g. Verfahren codiert und dann dieser Code mit dem in der Datenbank hinterlegten/gespeicherten (und ebenfalls bereits nach diesem Verfahren chiffrierten) Code verglichen. Stimmt es überein kann Zugang gewährt werden, ansonsten nicht.
-
Zur VERANSCHAULICHUNG gehen wir von einer einfachen Konfiguration aus.
-
Es gibt einen Web-Server mit Zugriff auf eine Datenbank (Datenbankserver) und das vorliegende mehrschichtige Schutzverfahren wird entweder in der Datenbankanwendung implementiert so dass die Anwender-Eingaben vor deren Verbindung/Weiterleitung zur Datenbank ausgefiltert werden und dann – sofern es sich um Anmeldedaten (oder anderweitige sensible Daten die zu sichern sind) handelt – durch dieses Schutzverfahren laufen bevor Sie der Datenbank übergeben werden oder dieses Verfahren wird auf dem Webserver zwischengeschaltet, was definitv sicherer wäre, jedoch nur möglich ist wenn der Webserver exklusiven Zugriff auf die Datenbank hat oder alle weiteren Verbindungen ebenfalls durch das Schutzverfahren laufen. Das Schutzverfahren wird im Übrigen auch sicherstellen, dass Anmeldedaten nie dechiffriert werden, da dafür auch keine Notwendigkeit besteht. Ferner wird es bei anderweitigen Dechiffrierungsanfragen (stichpunktartig) prüfen ob für die Anforderung ein gültiges Login besteht. Ggf. wird es hierfür eine interne (verschlüsselte) Liste führen um die Gefahr von SQL-Angriffen und Login-Täuschungen abzuwenden. Ein Admin-Zugriff ist in der höchsten Sicherheitsstufe nicht möglich, kann aber darunter unter bestimmten weiteren Voraussetzungen etabliert werden.
-
Treffen nun Daten ein werden diese, bevor sie an die Datenbankverwaltung weiter gesendet werden, abgefangen und durchlaufen das nachfolgende Verfahren.
- 1. Passwörter werden per verkürzten Einweg-Hashing sofort zu unwiederherstellbaren Hash-Werten verschlüsselt. Dieser Teilschritt könnte ggf. bereits am Front-End (Web-Browser) erfolgen, falls nicht per https übertragen wird oder dies irgendwann als unsicher angesehen wird.
- 2. Anmeldename und Passwort werden von der Web-(Server-)Anwendung an das Schutzverfahren übergeben. Dies erfolgt am einfachsten indem die Anmeldedaten als neuer Eintrag einer speziellen (Stack-)Datei hinzugefügt werden. Er beinhaltet den Chiffrierungsgrund, die Anmeldedaten und eine Zuordnungsnummer der Anfrage. Ggf. dazugehörige weitere Daten werden zunächst gepuffert. Selbstverständlich wären auch andere Wege des programmübergreifenden Datenaustauschs möglich.
- 3. Zur Zeit X ruft der wiederholt gesetzte Timer das entsprechende Unterprogramm auf.
- 4. Dieses blockiert sofort weitere Interrupts und speichert die Systemzeit sowie den Timerwert (Nachlaufzeit zum Ausgleich der Zeitverzögerung seit Timer-Ablauf) und stoppt dann ggf. die Netzwerkverbindung zum Web(-Server) und weitere Threads.
- 5. Nun wird die Zufallsmatrix zur gesicherten Ablage der Schlüssel vorbereitet und aus der gesicherten Systemzeit (abzgl. des Timerwertes) der gültige Zeitschlüssel und der Master-Key berechnet und ggf. die Fehlerkorrektur angewendet. Zum Auffinden des Masterkey-Future-Key's wird der Zeiger darauf zuvor mit dem dechiffrierten Zeitschlüssel entschlüsselt. Der Masterkey-Future-Key wird (im Versteck) sicher gelöscht.
- 6. Dann werden die Daten aus der (Stack-)Datei entnommen und sogleich dort sicher gelöscht*. Der Anmeldename wird mit dem Master-Key und Zeitschlüssel verschlüsselt und das Ergebnis als Suchanfrage an die Datenbank gesendet. Bei positiven Ergebnis wird der Master-Key entsprechend der Klardaten, der Datenfeldnumer und des Unique-Key's des Datensatzes gemäß der anwendungsindividuellen Formel arithmetisch bearbeitet und der Passwort-Hash damit verschlüsselt. Anschließend erfolgt die Verschlüsselung mit dem Zeitschlüssel und das Passwort wird mit dem der Datenbank verglichen bzw. dort gespeichert. Ggf. können weitere sensible Daten (aus dem Puffer oder nachfolgend) mit dem arithmetisch bearbeiteten Master-Key und Zeitschlüssel chiffriert gespeichert werden. Alternativ könnte für sensible Daten (neben dem Passwort) ein gesonderter Zeitschlüssel verwendet werden, welcher dann analog zum Haupt-Zeitschlüssel gehandhabt wird (Future-Key-Verschlüsselung).
- 7. Der Chiffrierungsgrund der (Stack-)Datei entscheidet die exakte Vorgehensweise. Er startet u. U. auch weitere Aktivitäten wie z. B. die Erstellung eines neuen Zeitschlüssels oder eine Datensicherung.
- 8. Die o. g. (Stack-)Datei erhält unter der jeweiligen Zuordnungsnummer eine Quittierung/Rückmeldung.
- 9. Eventuelle Zwischenspeicher (Variablen) für die aus der Datei entnommenen Anmeldedaten werden sicher gelöscht*.
* „sicher gelöscht” bedeutet die Anwendung von Löschverfahren die eine Wiederherstellung unmöglich machen.
- 10. Das neue Versteck für den Masterkey-Future-Key's wird vorbereitet. (Zufalls Matrix) Der Zeiger darauf wird mit Zeitschlüssel chiffriert, wobei das Original noch nicht gelöscht wird.
- 11. Es werden neue Parameter erzeugt und aus der neuen Zeit X ein 128-Bit-Schlüssel errechnet. Daraus wird in einem extrem komplexen Verfahrensmix aus Verschlüsselung und Potenzierung mit komplexen vielstelligen Zahlen je ein neuer Future-Key berechnet und der Timer entsprechend gesetzt.
- 12. Master-Key und Zeitschlüssel werden sicher gelöscht.
- 13. Ggf. wird die Netzwerkanbindung/Internetanbindung wieder hergestellt.
- 14. Der Masterkey-Future-Key wird versteckt und das Original sowie der unchiffrierte Zeiger darauf sicher gelöscht.
- 15. 15. Blockierte Threads und Interrupts werden wiederaktiviert und der Web-(Server-)Anwendung eine Botschaft gesendet, dass die Anmeldedaten bearbeitet bzw. ausgewertet wurden so dass evtl. weitere gepufferte Anfragen weiter geleitet werden.
-
Es ist davon auszugehen dass von der Datenbank z. B. täglich eine Sicherung (BACKUP) erstellt wird/werden soll. Dies erfolgt zumeist auf einem gesonderten Sicherungslaufwerk. In diesem Fall wird entweder die Datenbank mit Hilfe des Zeitschlüssels, da dieser nach kurzer Zeit verworfen sein wird, dechiffriert und dann gesichert (also „nur” mit dem arithmetisch veränderten Masterkey verschlüsselt) oder es wird der für diese Sicherung gültige Zeitschlüssel ausgedruckt bzw. dem Anwender mitgeteilt sodass das Backup notfalls wiederhergestellt werden kann. Da der gültige Zeitschlüssel unbekannt ist und erst zum nächsten Timer-Ablauf aus dem Future-Key und der Systemzeit berechnet werden kann, muss diese Sicherungsfunktion vom Timer-Unterprogramm ausgeführt werden.
-
Damit der ausgedruckte oder mitgeteilte Backup-Zeitschlüssel nicht ausserhalb des Systems, also in der materiellen Welt (womöglich zusammen mit dem dazugehörigen Backup z. B. aus einem Safe) entwendet werden kann, wäre es sinnvoll, dass das Timer-Unterprogramm die zu den (beispielsweise 100 letzten) Backups gehörigen Backup-Zeitschlüssel in einer Liste speichert die so wie die Anmeldedaten auch mit dem kompletten Schutzverfahren chiffriert sind und somit nicht erbeutet werden können. Falls ein Backup wiederhergestellt werden muss wird dies dem Timer-Unterprogramm (so wie auch der Backkup-Vorgang) über eine spezielle Anfrage mitgeteilt und nach dessen Anweisung das Backup eingespielt. Dem Timer-Unterprogramm wird das Datum des Backups mitgeteilt sodass es den dazugehörigen Backup-Zeitschlüssel aus der o. g. Liste extrahieren kann.
-
Erfüllt ein Server all diese Sicherheitsbausteine so erhält er ein SIEGEL, das er u. a. auf seinem Portal veröffentlichen kann und welches (ähnlich dem „Trusted-Shop-Garantie-Siegel”) dem Anwender/Nutzer die Gewissheit gibt, dass seine (Anmelde-)Daten hier sicher sind. Hierbei ist eine mindestens zweistufige Qualitäts-Klassifizierung sinnvoll um zu unterscheiden ob das Maximum der Sicherheitsmechanismen (inklusive Hardwareerweiterung, TPM und Handhabung der jeweils sichersten Optionen) oder nur das Minimum (in etwa Patentanspruch 1) eingesetzt wird.
-
Man könnte vielleicht meinen, dass mit Hilfe einer RSA-Verschlüsselung (asynchrone Schlüssel) und Aufbewahrung des privaten/geheimen Schlüssels an einem anderen sicheren Ort eine ähnliche Sicherheit erreicht werden könnte, da der evtl. mit erbeutete (öffentliche) Schlüssel nicht ausreicht um die Daten zu entschlüsseln (was normalerweise auch garnicht nötig ist sofern es sich nur um Anmeldedaten handelt). Doch aufgrund der rassanten Entwicklung im Bereich der Rechenleistung ist heute schon klar, dass selbst Schlüssel mit 1024-Bit Länge in naher Zukunft berechnet werden können (Faktorisierung) sofern der öffentliche Schlüssel bekannt ist. Insofern wäre hiermit eine langfristige Sicherheit definitv nicht gegeben. (Siehe Schätzungen und Prognosen von BSI, NIST, bzw. Dirk Fox (Secorvo GmbH)) Vor allem wäre jedoch diese Handhabung nicht zweckmäßig wenn auch (sensible) Daten wieder dechiffriert werden müssen. Die Erbeutung des privaten Schlüssels wäre ferner nie ganz auszuschließen.
-
Es bestünde ferner die Möglichkeit allein mit einer starken Einweg-Verschlüsselung (so wie das Hashing aus Anspruch 1) die reale Entschlüsselung erbeuteter Daten selbst mit dem richtigen Schlüssel auszuschließen. Allerdings ist es in diesem Fall möglich Äquivalentwerte zu finden, die zu dem gleichen Ergebnis (Hashwert) kommen und somit Zugriff gewähren obwohl der ursprüngliche reale Ausgangswert nicht wiederhergestellt werden konnte. Ferner wäre auch hier das Problem dass es natürlich auch Daten gibt die nicht mit einem Einweg-Hashing verschlüsselt werden können da es notwendig ist sie wieder völlig herstellen zu können.
-
Zwar wird hier in erster Linie über Anmeldedaten gesprochen, aber selbstverständlich lassen sich mit diesem Verfahren auch alle anderweitigen Daten schützen. Zu empfehlen ist jedoch dass größere Mengen sensibler Daten stets mit einem gesonderten Master-Key/Zeitschlüssel verschlüsselt werden sollten und wenn sie (das jeweilige Datenfeld bzw. die jeweilige Datenspalte) nicht für eine datenbankweite Suche zur Verfügung stehen müssen, sollte unbedingt die arithmetische Bearbeitung des Master-Key's (vor der weiteren Verschlüsselung per Zeitschlüssel) erfolgen. Denn ist eine Datenbank mit einem einzigen Schlüssel verschlüsselt, gilt: Je größer die Datenmenge desto leichter ist der Schlüssel zu knacken.
-
Selbstverständlich haben hochwertige Datenbanksysteme eine eigene Verschlüsselung. Diese ist bei Anwendung des vorliegenden Verfahrens eigentlich überflüssig, schadet aber auch nicht.
-
Insbesondere muss sich somit die Anwendung des vorliegenden Verfahrens nicht um die Verschlüsselung der einfacheren und nicht ganz so sensiblen Daten kümmern. So würde es beispielsweise bei einem Bankserver ausreichen, die Anmeldedaten und z. B. Kontonummer sowie Strasse mit dem vorliegenden Verfahren zu schützen, wobei für Kontonummer und Strasse je ein gesonderter Zeitschlüssel zum Einsatz kommen könnte. Alle restlichen Daten wären mit der Datenbankverschlüsselung ausreichend gesichert da mit ihnen im Fall der Erbeutung kein dramatischer Schaden entstünde.
-
Mit diesem Verfahren geschützte Daten/Passwörter können bei heutigem Wissensstand und absehbaren Technikstand nicht erbeutet werden. Selbst mit einem Brute-Force-Angriff eines Super-Computers könnte jeweils immer nur ein einziger Account geknackt werden sofern die Web-Anwendung Brute-Force-Angriffe nicht sowieso verhindert. Ein Angriff auf die Datenbank als Ganzes kann aufgrund der mehrfachen inhomogenen Verschlüsselung ausgeschlossen werden. Rechnerisch kann klar gesagt werden dass selbst ein Computer in tausenden von Jahren mit einer Rechenleistung die Trilliarden größer wäre als heute ein erfolgreicher Angriff als unmöglich anzusehen ist.
-
Es bleibt am Ende das Hauptrisiko dass der/die Schlüssel (hier Master-Key etc.) mit erbeutet wird/werden, was jedoch durch das vorliegende Verfahren ausgeschlossen werden kann da sämtliche relevanten Schlüssel niemals wirklich vorliegen. 99% der Zeit sind nur die Future-Key's vorhanden (und diese gut versteckt) welche – selbst wenn sie erbeutet würden – völlig nutzlos sind da mit Ihnen nur die Master-Key's und Zeitschlüssel erzeugt werden könnten (aber eben auch nur zu einer ganz bestimmten Zeit die nur der programmierte Timer kennt). Da das Hack-Ergebnis kein Klartext sondern wiederrum nur ein Schlüssel ist der zudem nur einer von 2 ist, fallen sämtliche möglichen Angriffsszenarien aus. Es müsste quasi für jedem möglichen Schlüssel erst alle Angriffe auf die erbeuteten Daten angewendet werden um zu sehen ob dabei sinnvolle Ergebnisse entstehen. Die Rechenzeit dafür übersteigt Alter und Lebensdauer des Universums.
-
Wann die Future-Key's Gültigkeit erlangen ist nicht herausfindbar und während der kurzen Ablaufdauer des Timer-Unterprogramms liegen Master-Key und Zeitschlüssel nur so versteckt vor dass es selbst mit Super-Computern in 1000 Jahren unmöglich sein dürfte die tatsächlichen Schlüssel heraus zu finden. Der codierte Zeiger darauf liegt während dessen nur in Prozessorregistern auf die selbst mit einem Hardwareeingriff nicht zugegriffen werden kann.
-
Master-Key und Zeitschlüssel sind quasi wie Geister der Zukunft, – nicht da und wenn doch dann nicht zu sehen.
-
Nur dann wenn der Angreifer während des Abauf des Timer-Unterprogramms einen kompletten Speicher- und Prozessor-Dump (inklusive aller Prozessor-Register) erbeuten könnte, würde eine echte Gefahr bestehen. Dies muss daher ausgeschlossen werden. Andernfalls müssen die Zufalls-Matrix in der die Schlüssel versteckt sind und/oder die Dechiffrierungsaufgaben selbst auf verschiedene Systeme/Speicher aufgeteilt werden. Auch eine Kombination (weitere Verschlüsselungsstufe(n)) mit TPM-Ver- und Ent-Schlüsselung wäre hilfreich, vor allem wenn zum unveränderlichen EK noch eine weitere Verschlüsselungsstufe mit wechselndem Schlüssel eingefügt wird. Ein derartiger Dienst kann gemäß Anspruch 8 noch optimaler in der o. g. Timer-Hardware-Erweiterung integriert werden, sodass letztlich auch ein Speicher- und Prozessor-Dump nicht zu einem erfolgreichen Angriff führen kann, da ein Teil der Verschlüsselung in der Hardwareeinrichtung stattfindet und diese Schlüssel dort unlesbar untergebracht sind. Sie werden auf der Hardwareeinrichtung erzeugt und können diese nicht verlassen. Da die Hardwareeinrichtung zu einem unveränderlichen Schlüssel noch einen variablen innehält der analog zum Zeitschlüssel in gewissen Zeitabständen neu erzeugt wird, kann eine Kryptoanalyse ausgeschlossen werden. Der Unterschied zu einem TPM (Trusted Platform Module) liegt einmal in der speziellen Sicherung gegen Hardwaredefekte besteht und darin dass keine asynchrone Chiffrierung stattfindet und somit auch kein öffentlicher Schlüssel bekannt ist.
-
Auf eine Sicherung der Hardware-Schlüssel ausserhalb der Hardwareeeinrichtung (wegen etwaiger Hardware-Defekte) kann verzichtet werden wenn diese Verschlüsselungsstufen bei einem Backup ausgelassen bzw. entfernt werden, was wiederrum nur zu empfehlen ist wenn die Backups besonders sicher aufbewahrt werden.
