Prüfsumme für laufendes Skript

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
__marcus__
User
Beiträge: 92
Registriert: Mittwoch 10. September 2008, 22:10
Wohnort: Hamburg

Dienstag 28. Oktober 2008, 15:55

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

Dienstag 28. Oktober 2008, 16:05

@__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
User
Beiträge: 95
Registriert: Mittwoch 8. Oktober 2008, 15:37

Mittwoch 29. Oktober 2008, 01:41

__marcus__ hat geschrieben: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
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Mittwoch 29. Oktober 2008, 09:48

farid hat geschrieben: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?
My god, it's full of CARs! | Leonidasvoice vs Modvoice
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Mittwoch 29. Oktober 2008, 09:53

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

Mittwoch 29. Oktober 2008, 11:46

sma hat geschrieben:(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
User
Beiträge: 1454
Registriert: Freitag 22. September 2006, 23:05
Wohnort: ja

Mittwoch 29. Oktober 2008, 12:52

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.
Benutzeravatar
veers
User
Beiträge: 1219
Registriert: Mittwoch 28. Februar 2007, 20:01
Wohnort: Zürich (CH)
Kontaktdaten:

Mittwoch 29. Oktober 2008, 13:28

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
[url=http://29a.ch/]My Website - 29a.ch[/url]
"If privacy is outlawed, only outlaws will have privacy." - Phil Zimmermann
lunar

Mittwoch 29. Oktober 2008, 13:39

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__
User
Beiträge: 92
Registriert: Mittwoch 10. September 2008, 22:10
Wohnort: Hamburg

Mittwoch 29. Oktober 2008, 18:26

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
User
Beiträge: 95
Registriert: Mittwoch 8. Oktober 2008, 15:37

Mittwoch 29. Oktober 2008, 19:30

Leonidas hat geschrieben: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
User
Beiträge: 95
Registriert: Mittwoch 8. Oktober 2008, 15:37

Mittwoch 29. Oktober 2008, 19:39

__marcus__ hat geschrieben: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.
Benutzeravatar
Sr4l
User
Beiträge: 1091
Registriert: Donnerstag 28. Dezember 2006, 20:02
Wohnort: Kassel
Kontaktdaten:

Mittwoch 29. Oktober 2008, 22:23

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
User
Beiträge: 95
Registriert: Mittwoch 8. Oktober 2008, 15:37

Donnerstag 30. Oktober 2008, 18:38

Sr4l hat geschrieben: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... :lol:
Benutzeravatar
jens
Moderator
Beiträge: 8461
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Freitag 31. Oktober 2008, 15:25

__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]

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Antworten