Authentizität von informationen gewährleisten

[Memger]

Hi Hagen!
das ist genau das, was ich meinte
ich wollte eigentlich nur ne bestätigung, dass es nicht geht :-(
um auf den viel clevereren hacker zu kommen...
auf die praxis bezogen heitß das, dass mein programm eine dll in den prozessraum des "bösen hackerprogramms" injiziert und dann in diesem prozess quasi lokal die api-fkt. writeprocessmemory abfängt, sodass (M) nicht mehr funktioniert. d.h. er müßte seinerseits auch api-hooking betreiben und mich damit aushebeln oder wie?

gruß
memge

[Hagen Reddmann]

Vergiß es einfach. In meinem "Anti-Hacking" bzw. "Hacking" Codes nutze ich NIEMALS die normalen Importe/Exporte. Ich nutze ein Funktion die OHNE jedweiges Windows API die Import/Export Adressen ermittelt. D.h. diese Funktionen reimplementieren GetModuleHandle() und GetProcAddress(). Damit nutzte ich IMMER die tatsächlichen Funktionsadressen OHNE das man mit dem Import/Export Hooking was dagegen ausrichten könnte. Einzigste Köglichkeit wäre ein sogenanntes Codepatching im System-Kernel um dort den Systemweiten Hook einzurichten. Deine Denkweise IST FALSCH. Du versuchst AKTIVE Gegenmaßnahmen gegen einen potentiellen Hacker einzusetzten. Bitte bemerke: Alle Möglichkeiten Dein Program zu attackiern kannst DU garnicht kennen, keiner kann das. Damit gibt es IMMER JEMANDEN der Deine Maßnahmen umgehen kann. Deine Maßnahmen sind der Kanonenschuß auf einen rießigen Schwarm von Spatzen. Du musst andersherum denken. Produziere soviel Müll wie es geht, der Angreifer muß nun aus allen Diesen Aktionen Deines Programmes genau die wichtigen herrausfinden. Das ist VIEL VIEL schwieriger als man denkt.
Nochwas: Hacker arbeiten mit Debugging Machinen/Software. SoftICE z.B. debuggt nicht nur gezielt Deine Anwendung, sondern debuggt das KOMPLETTE Betriebssystem OHNE das dieses das mitbekommt. D.h. Du hast KEINERLEI Chance, wenn der Hacker Deinen Versuch merkt lacht er sich vielleicht tod :=) (darauf kannst noch hoffen, mehr nicht).

Gruß Hage

[Gesine Kuhlmann]

Hi,

1)
Also wollen wir doch mal die Kirche im Dorf lassen. Wenn man davon ausgeht, dass ein Hacker vollständigen Zugriff auf deinen Client hat, dann kann man strampeln soviel man will und der Hacker kommt immer an die nötigen Algorithmen um einen Sicherheitsmechanismus auszuhebeln. Das meinte ich übrigens mit Fundament und Wolkenkratzer. Hat der Hacker sogar physikalischen Zugriff auf deinen Client, dann sind theoretisch sogar Hardwarelösungen auszuhebeln ( Man braucht eben nur das nötige Equipment/Knowhow ).

3)
Der ganz schlaue Hacker macht sich diese Mühe aber überhaupt nicht. Er greift da an, wo es am einfachsten ist. Das ist in den meisten Fällen der Nutzer, der mit sicherheitsrelevanten Daten fahrlässig umgeht ( 5 von 10 Nutzern haben Ihr Kennwort unter der Schreibtischunterlage notiert oder lassen Ihre Security-Card halt irgendwo rumliegen ).

3)
Ich hab' nie gesagt, dass ich einen Schlüssel im Client ablegen will. Dieser MUSS immer von einem gesicherten Medium kommen. Ein gutes Beispiel für ein derartiges Verfahren ist z.B. das alte BTX-Onlinebanking. Das Verfahren ist -sofern Punkt 1 nicht zutrifft- relativ sicher. Durch die Verwendung von TANs ist es noch nicht mal möglich, deinem Server ein abgehörtes unverändertes Datenpaket erneut unterzujubeln.

4) Mit der fast philosophischen Erkenntnis, dass jeder Algorithmus den sich jemand ausdenkt um seine Daten zu schützen von Dritten entschlüsselt werden kann, kommt man zu dem Schluss, dass Datensicherheit neben der Verschlüsselung durch weitere Verfahren ergänzt werden muss. So geschieht's ja heutzutage auch. Als Beispiel sei Auditing erwähnt.

5) Speziell an Memger: Ich dachte du suchst nach einer praktikablen Lösung um die Kommunikation zwischen C/S etwas sicherer zu machen und versuchst nicht eine ähnlich gelagerte Frage, wie die nach dem Sinn des Lebens zu ergründen. ;-)

6) Man kann aber mit einfachen Mitteln eine relativ sichere Umgebung schaffen, an der sich 999 von 1000 Hackern die Zähne ausbeissen:

- Beschränke den physikalischen Zugriff auf Hardware

- Setze nie ein BS ein, dass einer offenen Hose gleicht

- Sorge für Verständnis/Akzeptanz bzgl. Datensicherheit bei den Nutzern und zwinge Sie dazu, soweit möglich ( z.B. Stichwort Kennwortvalidierung., 80% aller Hacks bekommen mit einem brutforce Angriff auf Kennwörter zumindestens einen Fuss in die Tür )

- Übertrage Daten immer verschlüsselt

- Analysiere immer Log-files deiner zentralen Maschinen.

Gruß
Gesin

[Hagen Reddmann]

Hi

@Gesine, mit der Aussage das "dass jeder Algorithmus den sich jemand ausdenkt um seine Daten zu schützen von Dritten entschlüsselt werden kann" stimme ich NICHT überein. Das notwendige Geheimniss der sicheren Algortihmen besteht ja eben NICHT im Algortihmus sondern im zusätzlichen Passwort oder einer sehr schwierigen Trapdoor Funktion.<br>

Z.B. den Algortihmus einer hashfunktion kann jeder als Source haben. D.h. aber nicht das mit einem solchen Algo. gehashte Daten und deren Digest zurückberechnet bzw. geknackt werden können. <br>

Oder, mit einem guten Verschlüsselungsalgo. und einem gut gewähltem Passwort werden die daten so verschlüsselt das selbst bei Kenntniss des Algortihmus es unmöglich wird die Daten OHNE das Passwort wieder zu entschlüsseln.<br>

Oder, mit einer guten Trapdoor Funktion und NUR dem öffentlichen Schlüssel kann auch bei Kenntniss des Trapdoor Algortihmus nicht mehr auf den Privaten Schlüssel zurückgerechnet werden. Vorrausgesetzt die Sicherheitsparamerter (Schlüssellänge etc) werden berücksichtigt.<br>

Fazit: Wird eine SmartCard eingesetzt die ALL diese Operation intern durchführt und nur die verschlüsselten Daten rein und rauslässt, dann bleibt dem Attacker nur der Versuch der korrekten Simulation dieser SmartCard übrig. Ohne die notwendigen internen Daten geht das aber nicht. Das Prinzip der TAN Listen ließe sich mit SmartCards also sehr sehr einfach bewerkstelligen.<br>

Gruß Hage

[Gesine Kuhlmann]

Hi Hagen,

1)
Da habe ich mich ungenau ausgedrückt. Du hast natürlich recht, dass es zumindestens ( meines Wissens ) eine Verschlüsselungsmethode (One-Time-Pad) gibt, die auch theoretisch als unknackbar gilt. Diese hat aber den Nachteil, dass Sie im täglichen Einsatz beim Normaluser, wohl als unbrauchbar betrachtet werden muss. Ich meinte mit Algorithmus in diesem Fall mehr 'Verfahren'. Und mit entschlüsseln hab' ich z.B. das Bestechen eines 'Schlüsselkuriers' eingeschlossen :-)

2)
Es gibt natürlich auch symmetrische Verschlüsselungen mittels Hash-Funktionen, die ( zumindestens heute ) als sicher gelten, da sie praktisch nicht knackbar sind ( Da fragt sich der treudoofe NATO-Partner doch, warum Amis wohl Exportbeschränkungen auf 'hochbittige' ( > 40bit ) Verschlüsselungsmethoden haben. Wollen die etwa in Daten schnüffeln ?? ).

3)
Asymetrische Verfahren sind diesbezüglich noch empfindlicher gelten aber, bei Einhaltung gewisser Kriterien, ebenfalls als sicher.

4)
Die von dir genannte SmartCard ist natürlich ein extrem harter Brocken. Sie krankt ( wohlgemerkt theoretisch betrachtet ) aber zumindestens an einem Punkt. Um eine sichere Verschlüsselung zu gewährleisten, brauchst Du einen echten zufälligen Schlüssel. Den musst du in deiner Karte ablegen. Dort finde ich Ihn aufgrund seiner Entropie.

Gruß
Gesin

[Hagen Reddmann]

Hi Gesine

Punkt 4). Um kryptographisch sicher arbeiten zu können brauchen wir KEINE echten Zufallsgeneratoren, sondern nur NICHT vorhersagbare, bzw. beweisbar schwer vorhersagbare. Nun, und solche gibt es ! Z.b. der Blum Blum Shub RNG, BBS oder Quadratische Reste Generator. Die SmartCard erzeugt zwei geheime Primzahlen ca. 512Bit groß, daraus das Modul N = P * Q. P und Q, die beiden Primes können nun sogar zerstört werden. Der Rest ist einfach Seed = Seed^2 mod N; RandomBits := Seed and (1 shl Log2(Log2(N)) -1);<br>

Nun dieser BBS IST mathematisch bewiesen der sicherste Zufallsgenerator. Man kann über ihn nur folgende korrekte Aussage machen:<b>Das nächste oder vorherige Ausgabe-Bit ist mit einer Wahrscheinlichkeit von 50% eine NULL oder EINS !</b>. Selbst mit sehr langen Sequenzen kann man NUR diese EINE korrekte Aussage machen. Diese Aussage ist auch die einzigst mögliche bei ECHTEN Zufallsgeneratoren. Nur im Unterschied dazu kann man beim BBS mit dem Wissen der beiden Primes P und Q, dann sogar exakt sagen wie die Zufallsbits kommen.

Gruß Hage