Auf Thema antworten

Allgemeiner Standard in der Kryptographie sind Public-Key (jedem zugaenglich)/Private Key(nur dem Versender zugaenglich) Verfahren, oder sogenannte asymmetrische Verschluesselungsverfahren. Damit sind 2 Methoden moeglich:


1. ich als Versender unterzeichne mit dem Private Key eine Nachricht (z.B. Parameter oder Programm), und jeder kann mit dem  Public Key die Authenzitaet der Nachricht ueberpruefen.


2. ich hole mir den Public Key des Empfaengers zur Verschluesselung, und nur dieser kann mit dem Private Key die Nachricht entschluesseln


Grundannahme 1: ich kann in meinem Dialer keinen Private Key einsetzen, der dort gespeichert ist, den kann ein findiger Hacker herauskriegen durch Debugger/Disassembler. Somit bleiben (aus meiner Sicht) drei Varianten:


1. der Dialer ist mit dem Private Key unterzeichnet, und der Anwender kann dann die Authenzitaet verifizieren mit dem Public Key, was ebenso effektiv ist wie das derzeitig verwendete Hash Verfahren. Also Sackgasse, so lange nicht das Betriebssytem zwingend vorschreibt, dass alle Programme signiert sein muessen (was aus anderen Gruenden problematisch ist, siehe allgemeine Debatte um Digital Rights Management, z.B. auf http://www.eff.org ).


2. der Dialer verschluesselt mit dem Public Key Kontrollinfos, die nach Einwahl Serverseitig entschluesselt werden. Dann kann ich diese Routinen kopieren, und in meinen manipulierten Dialer stecken.


3. der Dialer erhaelt Kontrollinfos, deren Authenzitaet er verifizieren kann, und ihm Anweisungen geben, wie er sich beim Server authentifizieren muss. Problem wie 2, ein manipulierter Dialer kann diese Routinen kopieren.  


Ich sehe nicht, wie ohne zusaetzlich dazwischengeschaltete Kontrollinstanz (z.B. der Benutzer oder das OS, zur  Hash/Signatur Verifikation) Kryptographie an dem Problem aendert. Deshalb halte ich diese Aussage fuer Marketing Blub blub. Lasse mich uebrigens gerne eines Besseren belehren.


edit: eine Auslassung u einen Rechtschreibfehler korrigiert


Zurück
Oben