Prüfsumme für laufendes Skript

[__marcus__]

Ist es in Python möglich einen Server zu schreiben, mit dem sich ein ebenfalls von mir geschriebener Client A verbindet ohne dass ein von jemand anderem geschriebener Client B sich mit diesem Server verbindet und manipulierte Daten schickt? Ich hatte da an eine Prüfsumme gedacht, die man allerdings auch abfangen und dann von Client B schicken könnte...

[BlackJack]

@__marcus__: Das ist nicht möglich ohne eine Verankerung in vertrauenswürdiger Hardware, und selbst da nicht 100% sicher. Das ist auch nicht von der Programmiersprache abhängig. Solange der Anwender noch selber Einfluss darauf hat, was auf seinem Rechner läuft, ist es schwierig zu unterbinden, das er darauf laufen lässt, was er möchte.

[farid]

Ist es in Python möglich einen Server zu schreiben, mit dem sich ein ebenfalls von mir geschriebener Client A verbindet ohne dass ein von jemand anderem geschriebener Client B sich mit diesem Server verbindet und manipulierte Daten schickt? Ich hatte da an eine Prüfsumme gedacht, die man allerdings auch abfangen und dann von Client B schicken könnte...

Ich wuerde ssh(1) nutzen, und so vorgehen:

1. Fuer jeden zugelassenen Client (z.B. mit ssh-keygen) ein Public/Private Keypaar erzeugen.

2. Einen Unix-User fuer das Programm auf dem Server anlegen. Sagen wir 'serverprog'

3. In ~serverprog/.ssh/autorized_keys die public keys der zugelassenen Clients (aus Schritt 1) eintragen.

4. Als Login Shell fuer 'serverprog' das Programm selbst statt einer Shell eintragen.

5. Auf der Server-Seite laeuft natuerlich sshd und wartet wie gewohnt auf Verbindungen.

Wenn sich nun Client A beim Server anmelden soll, ruft er ssh und loggt sich erfolgreich in die 'serverprog' Kennung ein (da er ja in ~serverprog/.ssh/authorized_keys steht). A ist dank Schritt 4. direkt mit dem Python Programm verbunden und kann ueber dessen sys.stdin und sys.stdout kommunizieren.

Versucht es Client B, geht es nicht, weil der sshd auf der Server Seite erkennt, dass der angegebene Schluessel nicht in ~serverprog/.ssh/authorized_keys steht. Client B kann also gar nicht erst mit dem Python-Programm kommunizieren.

Ist nicht getestet, aber es duerfte als Verfahren sicher sein... solange die Umgebung auf der Server-Seite sicher ist. Wer auf absolut nummer sicher gehen will, kann zusaetzlich z.B. das Serverprogramm samt sshd in einem FreeBSD jail(8) oder so laufen lassen.

[Leonidas]

Wenn sich nun Client A beim Server anmelden soll, ruft er ssh und loggt sich erfolgreich in die 'serverprog' Kennung ein (da er ja in ~serverprog/.ssh/authorized_keys steht). A ist dank Schritt 4. direkt mit dem Python Programm verbunden und kann ueber dessen sys.stdin und sys.stdout kommunizieren.

Versucht es Client B, geht es nicht, weil der sshd auf der Server Seite erkennt, dass der angegebene Schluessel nicht in ~serverprog/.ssh/authorized_keys steht. Client B kann also gar nicht erst mit dem Python-Programm kommunizieren.

Was hält den Client B ab, den Private Key von Client A zu nutzen?

[sma]

Soll die Kommunikation z.B. für HTTP stattfinden, fällt etwas wie SSH oder TLS weg. Dann hilft nur selbst verschlüsseln und authentifizieren. Hierzu würde ich eine PKI (public key infrastructure) mit X.509-Zertifikaten vorschlagen, die zunächst ausgetauscht werden und denen die Clients vertrauen müssen. Dies kann durch eine dritte Stelle in Form eines OCSP (online certificate statuc providers) stattfinden, dem beide Seiten trauen (das Vertrauen wird hier wiederum über Zertifikate aufgebaut) oder aber, indem es fest verdrahtete Stammzertifikate gibt. In den Zertifikaten stecken öffentliche (RSA) Schlüssel, die dann benutzt werden können, um Signaturen zu prüfen. Signaturen sind mit privaten Schlüsseln verschlüsselte kryptografische Hashwerte (message digests), die dazu dienen, nachzuweisen, dass es nur der Besitzer des zu dem public key aus dem Zertifikat gehörigen private keys gewesen sein konnte, der diese Daten gesendet hat. Darf ein dritter die Nachricht nicht lesen, sollte man sie zusätzlich verschlüsseln. Dazu nimmt man am besten symetrische Schlüssel, weil diese effizienter sind und Nachrichten beliebiger Länge erlauben (bei pub/prv keys darf die Nachricht immer nur so lang sein wie der Schlüssel). Die Schlüssel muss man vorher mit speziellen Verfahren austauschen, die "man in the middle"-Angriffe unmöglich machen.

Im XML-Umfeld gibt es mit XENC und DSIG zwei Standards für das Verschlüssel und das Signieren von XML-Dokumenten. Ich weiß zwar nicht, um im Python-Umfeld dafür Implementierungen verfügbar sind, aber Java 6 könnte dies out of the box und Jython damit auch.

Stefan

[lunar]

(bei pub/prv keys darf die Nachricht immer nur so lang sein wie der Schlüssel).

Quelle?

Die Schlüssel muss man vorher mit speziellen Verfahren austauschen, die "man in the middle"-Angriffe unmöglich machen.

Man hat doch bereits asymmetrische Schlüssel zur Verfügung, warum also nochmal ein spezielles Verfahren? Normalerweise nutzt man die asymmetrischen Schlüssel, um den zufälligen symmetrischen Schlüssel zu chiffrieren, mit dem die Daten verschlüsselt wurden. So arbeitet jedes bekannte Verfahren, dass asymmetrische Schlüssel nutzt, wie z.B. PGP, SSL oder SSH.

[Y0Gi]

SSH ist schon mächtig. Speziell für HTTP-Einsatz würde ich SSL verwenden und zusätzliche (statische, aber je nach Client evtl. unterschiedliche) Autorisierungsparameter per Header oder als Cookie übergeben.

[veers]

Wenn das so ist, wie ich das verstehe, und die Person welche Programm B schreibt, Zugriff auf Programm A hat, dann ist das praktisch unmöglich. Jedes Programm was du schreibst kann von jemand anderem Nachgebaut werden. Das trifft Grundsätzlich auch auf Hardware zu. Auch wenn man es da sehr schwer machen kann, was in deinem Fall jedoch auch nichts bringen würde, da du ja nicht ein Zufälliges nicht kopierbares Verhalten willst. Vielleicht könne man da auf Grund der Heisenbergschen-Unschärferelation etwas zaubern.

Lunar,
Ich nehme an er meint das:
http://de.wikipedia.org/wiki/RSA-Krypto ... Sicherheit

[lunar]

Das hat aber wenig mit seiner ursprünglichen Aussagen zu tun, dass die Länge des Klartexts bei asymmetrischen Verfahren der Länge des Schlüssels entsprechen muss, sondern sagt nur, dass man Nachrichten mit zufälligen Werten versieht, um zu verhindern, dass Signaturen gefälscht werden können. Das bezieht sich aber ausschließlich auf RSA, ElGamal beispielsweise funktioniert ganz anders.

[__marcus__]

Ich hatt mir zwar schon gedacht, dass das nicht so einfach ist, aber das ist nun doch nicht so ganz meine Liga... Trotzdem danke.

[farid]

Was hält den Client B ab, den Private Key von Client A zu nutzen?

Natuerlich gar nichts. Erhaelt Client B Kenntnis vom Private Key von Client A, kann er sich als Client A ausgeben. Aber das ist ja ein grundsaetzliches Problem...

... dem man z.B. dadurch ein wenig begegnet, indem man z.B. die IP-Adressen (-Bloecke) der Clients mit in die private-key Generierung einstrickt, oder sie server-seitig nach der normalen sshd-Authentifizierung mit ueberprueft (ein extra PAM-Modul faellt mir da z.B. ein). In dem Fall wuerde Client B die Kenntnis von Client A's private key nicht viel nuetzen, es sei denn, er befindet sich im selben IP-Block. Aber das fuehrt uns natuerlich tief in heuristische Ueberlegungen hinein.

[farid]

Ich hatt mir zwar schon gedacht, dass das nicht so einfach ist, aber das ist nun doch nicht so ganz meine Liga... Trotzdem danke.

Eigentlich spielt sich das Meiste bei der SSH-Loesung ausserhalb des Python-Programms ab! Das ganze ist mehr administratives hantieren mit Schluesseln als etwas anderes.

Von Python aus, kannst Du server-seitig einfach auf sys.stdin lesen und sys.stdout schreiben. Richtige Einstellungen vorausgesetzt, bist Du dann via sshd mit dem Client ueber einen sicheren verschluesselten TCP-Kanal verbunden.

Client-seitig kannst Du ja z.B. mit, (sagen wir mal) subprocess.Popen das ssh Programm mit passenden Parametern (Adresse des Servers) aufrufen. ssh selbst kuemmert sich dann um den Rest. Anschliessend liest- und schreibst Du ganz normal ueber das subprocess Objekt, das die Verbindung zum Server darstellt.

[Sr4l]

Allgemein: Eine Möglichkeit ist die Befehle zwischen Server und Client so oft zu ändern das der Programmiere des alternativen Clienten die Lust verliert diesen zu pflegen

[farid]

Allgemein: Eine Möglichkeit ist die Befehle zwischen Server und Client so oft zu ändern das der Programmiere des alternativen Clienten die Lust verliert diesen zu pflegen

Und das Updaten des Clients koennte dann auch eine Funktion des Client-Server Protokolls sein...

[jens]

__marcus__: Willst du vielleicht ein Spiel programmieren?

Der einzige sichere Weg dies zu verhindern, wäre, keine Sourcen und binäre Dateien herauszugeben und das Programm als Web-Service bzw. als SaaS anzubieten.

von [wiki]FAQ#IchWillAberUnbedingtEinenCompiler[/wiki]

[__marcus__]

__marcus__: Willst du vielleicht ein Spiel programmieren?

Ich bin zu faul es zu erklären.