Kniffliges Verschlüsselungsproblem

[Benne]

allo!
Ich bräuchte einmal Euren Rat bezüglich einer Verschlüsselungsstrategie.
Ihr kennt ja vielleicht das Programm TVBrowser (http://www.tvbrowser.org). Dieses Programm stellt die Informationen von über 140 TV-Sendern zur Verfügung. Ich habe jetzt ein Programm für den PocketPC geschrieben für das ich TVDaten aus dem TVBrowser exportiere. Das ExportPlugin ist in Java geschrieben und soll OpenSource bleiben. Der PocketTVBrowser ist in C# geschrieben und sollte wenn möglich auch OpenSource werden (ist aber kein Muss).
Dadurch, dass das TVBrowser Team viel Arbeit damit hat die TVDaten zu sammeln und aufzubereiten möchte man es anderen Konkurrenten möglichst schwer machen die Daten zu klauen. Also soll das Export-Plugin die Daten verschlüsseln. Ein symmetrisches Verschlüsselungsverfahren scheidet aus, weil das Export-Plugin auf jeden Fall OpenSource bleiben soll. Also dachten wir an ein Public-Key-Verfahren. Im Export-Plugin werden also die Daten mit dem öffentlichen Schlüssel verschlüsselt und nur der private Schlüssel im PocketTVBrowser kann die Daten entschlüsseln.
Also habe ich eine 1024 Bit RSA-Verschlüsselung implementiert. Dabei bin ich dann über den Fehler gestolpert, dass maximal 117Byte verschlüsselt werden können. Ich denke mal es ist nicht im Sinne des Erfinders jetzt jede Nachricht in 117 Byte Blöcke zu teilen. Das muss doch auch anders gehen.


Uns ist bewusst, dass man den Export nicht 100%ig sicher bekommt, denn schließlich ist die Plugin-Schnittstelle des Programms offen und jeder könnte sich sein eigenen Plugin schreiben. Es soll halt nur so umständlich wie möglich sein, so dass zumindest nicht das fertige ExportPlugin genutzt werden kann.
Würde mich wirklich sehr über einige Tipps freuen!
Bis denne
Benne

 

[SlaterB]

hmm, lässt sich der gesamte Inhalt deines Postings reduzieren auf

'ich habe 200 Byte und möchte die nicht in 117 Byte-Blöcke zerlegt verschlüsseln'
?

ich selbst kann dazu nicht viel beitragen, aber willst du nicht noch irgendwas zum verwendeten Verschüsselungsprogramm/ Verfahren sagen?

> Dabei bin ich dann über den Fehler gestolpert

welche Fehlermeldung, welches Programm, welche Vorlage?
wenn du alles selber gebaut hast, wieso gibt es dann diese Hürde in deinem Programm,
oder: entferne sie einfach

 

[Benne]

nein - eigentlich lässt sich mein Posting daruaf reduzieren, dass ich gerne eine Empfehlung für eine Verschlüsselungsstrategie hätte.
Eigentlich dachte ich meine bisherige Idee ganz gut zu beschreiben. Aber ich versuche es gerne nochmal.
Ich wollte die TV-Daten mit einem Public-Key verschlüsseln. Das hat den Vorteil, dass das Export-Plugin auch weiterhin Opensource bleiben kann. Der Private Key, der zur Entschlüsselung benötigt wird, wird im PocketPc Programm versteckt (closed source). Also kann (idealerweise) nur das PocketPC Programm die TVdaten entschlüsseln.
Als Public-Key Verfahren habe ich mich für RSA entschieden. Dabei wurde allerdings eine Exception geworfen mit dem sinngemäßen Inhalt, dass maximal 117 Byte mit RSA verschlüsselt werden können. Die Texte die ich verschlüsseln muss sind aber länger. Also habe ich mir gedacht, dass der von mir angestrebte Ansatz vielleicht doch nicht der richtige ist und jetzt hoffe ich auf ein paar Vorschläge wie ich das Problem besser lösen könnte.

welche Fehlermeldung, welches Programm, welche Vorlage?
wenn du alles selber gebaut hast, wieso gibt es dann diese Hürde in deinem Programm,
oder: entferne sie einfach

Ok mit Fehlermeldung meinte ich eben benannte Exception. Programm/Vorlage? Ich benutze die Standard sun Funktionen.
Also diese Hürde MUSS ich doch einbauen, damit die Daten eben nicht so einfach geklaut werden können. Natürlich wäre es ohne Verschlüsselung einfacher.[/quote]

 

[SlaterB]

ich meinte, entferne die Hürde, nicht entferne die Verschlüsselung

du beziehst dich also auf die vorgegebenen API-Verschlüsselungsklassen,
das erscheint mir eine wichtige Info zu sein

leider kann ich wie gesagt sonst nix sinnvolles beitragen ;(

 

[Benne]

;-)
"entferne die Hürde" ist aber auch ein ganz toller Hinweis.

 

[Murray]

Dabei wurde allerdings eine Exception geworfen mit dem sinngemäßen Inhalt, dass maximal 117 Byte mit RSA verschlüsselt werden können.

Könntest du mal den kompletten Stacktrace dieser Exception posten und evtl. auch die entsprechende Code-Stelle?

 

[wranger nicht eingeloggt]

Moin,

mal ne Frage was spricht gegen die Verschlüsselung von 117Byte? Wird das im Netzwerk zu langsam?? Ich weiß es jetzt nicht gerade auswendig wieviel Daten denn in ein IP-Datagramm gehen. Und wenns das nicht sein soll warum teilst du dann den Stream nicht in 117.000Byte und lässt ne Schleife das ganze 1000 x verschlüsseln um es anschließend wieder zusammen zu bauen? Dann senden und so wieder entschlüsseln?

Gruß
Carsten

 

[Gast]

kenn das programm nicht, aber wenn es so ist, dass sich jemand eh einfach nur sein eigenes plugin einzuhängen braucht, um wieder an alle daten zu kommen, dann brauchst du keine verschlüsselung. warum sollte jemand überhaupt versuchen, die zu knacken, wenn er viel schmerzfreier einfach nen plugin bastelt?

deshalb reicht es, wenn du die daten in nem proprietären (binär) format speicherst. die spezifikationen dazu kann natürlich jedermann problemlos rausfinden, aber bevor sich jemand anderes dann ne lib und was nicht alles besorgt, um die exports verwenden zu können, kann er lieber nen anderes export plugin verwenden.

 

[Guest]

also erstmal so grob (gekürzt) der Code:

//rgendwo in der main: 
  try{
    		KeyPairGenerator keyPairGenerator = KeyPairGenerator.getInstance("RSA");
    		keyPairGenerator.initialize(1024);
    		KeyPair keyPair = keyPairGenerator.generateKeyPair();
    		this.cipher = Cipher.getInstance("RSA");
    		this.cipher.init(Cipher.ENCRYPT_MODE, keyPair.getPublic());
    	}
    	catch (Exception ex){
    		System.out.println("Error: "+ ex.getMessage());
    	}



//die Verschlüsselungsfunktion
//funktioniert bei kurzem Text
public String encrypt(String text){
    	String result = "";
    	try {
    		result = new String(this.cipher.doFinal(text.getBytes()));
    	}
    	catch (Exception ex){
    		System.out.println(ex.getMessage());
    	}
    	return result;
    }

Die Exception in der encrypt Funktion lautet "Data must not be longer than 117 bytes" und tritt immer dann auf wenn der zu verschlüsselnde Text länger als der Key ist. Darum bin ich davon ausgegangen, dass meine ganze Überlegung RSA zu nutzen für diesen Zweck ungeeignet ist.


Also ich glaube ich habe das Thema wohl wirklich nicht ausgiebig genug erklärt.
Die Daten, so wie sie der Desktop TV-Browser verarbeitet sind Java-Binaries. Der PocketTVBrowser ist hingegen in C# geschrieben und kann mit den Binaries nur recht wenig anfangen. Außerdem hätte der PocketPC nicht genug Power umd die Datenflut in gescheiter Zeit zu verarbeiten. Darum habe ich in Java ein Export-Plugin für das Desktop Programm geschrieben das ausgewählte Inforamtionen in eine SQLite Datenbank schreibt. Nun möchte ich aber, dass die Daten verschlüsselt in der Datenbank stehen, damit nicht jeder OHNE PROBLEME die Daten direkt auslesen kann. Das jeder sich selbst ein Export-Plugin schreiben könnte oder das vorhandene Ändern könnte ist schon klar. Es soll denen nur möglichst schwer gemacht werden.
Es findet auch kein richtiger Netzwerkverkehr statt - nach dem exportieren wird die SQlite Datei auf beliebigen Weg auf den PDA übertragen.

 

[Benne]

ups hatte gerade vergessen mich einzuloggen.
für die die es interessiert:
Das Desktop Programm http://www.tv-browser.org
Die PPC Version http://benedikt.grabenmeier.com/2007-04-08/pockettvbrowser-tv-programm-fur-den-pocketpc/

 

[Murray]

Die Exception in der encrypt Funktion lautet "Data must not be longer than 117 bytes" und tritt immer dann auf wenn der zu verschlüsselnde Text länger als der Key ist. Darum bin ich davon ausgegangen, dass meine ganze Überlegung RSA zu nutzen für diesen Zweck ungeeignet ist.

Das ist wohl so - RSA ist zum Verschlüsseln von Keys gedacht, nicht für grössere Datenpakete. Dafür wäre wohl z.B. AES besser (und auch schneller).

 

[Benne]

aber bei AES muss ich doch das Passwort im Klartext reinschreiben, oder? Bei RSA hätte ich wenigstens den Vorteil, dass derjenige das Plugin aktiv ändern muss und nicht nur reinschauen muss.

 

[madboy]

Verschlüssele doch das Passwort für AES mit RSA.
Alternative: Verschlüssele immer Blöcke von 117 Bytes mit RSA.

 

[Murray]

Verschlüssele doch das Passwort für AES mit RSA.

Genau dafür ist RSA gedacht.

 

[Benne]

Verschlüssele doch das Passwort für AES mit RSA.

Genau dafür ist RSA gedacht.

sowas habe ich auch schon mal irgendwo gelesen. Aber mir erschleicht sich noch nicht so ganz der Sinn. Wenn ich zum Beispiel das Passwort "1234" habe. Dann würde ich das mit dem öffentlichen Schlüssel verschlüsseln "!2§$". Wenn ich danach meine Text mit diesem Schlüssel symmetrisch verschlüssle, dann brauche ich doch auf PPC Seite auch wieder "!2§$" zum entschlüsseln und eben nicht den privaten Schlüssel. Naja zumindest müsste der Benutzer in den Quellcode eingreifen um das Passwort zu bekommen und dann könnte er auch gleich die Verschlüsselungsfunktion auskommentieren. Muss ich wohl noch nen bisschen drüber nachdenken. Aber Danke schon mal!
Bis denne
Benne

 

[SlaterB]

verschlüsselt wird mit 1234,
diesen Schlüssel brauchen beide

um den Schlüssel zu übertragen RSA verwenden, das ist sicher, aber aufwendig

 

[Benne]

naja wenn nur mit "1234" verschlüsselt wird habe ich ja nun das Problem, dass ich nur in den Quellcode gucken muss um das PW herauszufinden. Das Plugin ist doch OpenSource. Da müsste der Angreifer nicht einmal was am Plugin ändern.
Und dann das Problem mit dem Schlüssel übertragen - ich habe ja gar keinen Netzwerkverkehr. Es gibt ganz unterschiedliche Möglichkeiten wie der Benutzer die SQLite Datei überträgt.

 

[Murray]

naja wenn nur mit "1234" verschlüsselt wird habe ich ja nun das Problem, dass ich nur in den Quellcode gucken muss um das PW herauszufinden. Das Plugin ist doch OpenSource. Da müsste der Angreifer nicht einmal was am Plugin ändern.

Auch bei einer asymmetrischen Verschlüsselung muss doch der öffentliche Schlüssel für die Entschlüsselung auf der Empfängerseite hinterlegt sein. Der Vorteil ist doch lediglich, dass nicht der geheime Schlüssel (der eben auch zum Verschlüsseln dienen kann) ebenfalls bekannt sein muss. Damit kann man sicherstellen, dass der Sender einer Nachricht im Besitz des geheimen Schlüssels war und damit sicherstellen, dass die Nachricht wirklich vom Absender stammt.

Wenn man Zugriff auf den Source-Code hat, wird es - wie du ja schon eingangs selbst gesagt hast - immer möglich sein, die Daten zu entschlüsseln. M.E. hat so eine Verschlüsselung eher den Sinn, a) das Abhören oder sogar Manipulieren der Daten auf der Übertragungsstrecke zu verhindern und b) (für asyymetrische Verfahren) die Authenizität einer Sendung zu gewährleisten.

 

[SlaterB]

der Unterschied ist, dass der Schlüssel für AES fest wäre, im Quellcode stehen müsste,

während die Daten aus einen Stream oder sonstwoher kommen,
da ist es kein Problem, dass diese z.T. unterverschlüsselt durch das Programm laufen,
dem Quelltext kann man es nicht ansehen



vielleicht sollte der Schlüssel zufällig erzeugt werden..

 

[Murray]

Aber wo hätte denn der öffentliche Schlüssel für RSA stehen sollen? Nicht ebenfalls im Quelltext?

 

[Benne]

also bei RSA hätte der öffentliche Schlüssel im Export-Plugin gestanden. Das ist ja auch ok. Verschlüsseln darf ja jeder. Nur der private Schlüssel (der, mit dem man entschlüsseln kann) würde dann im PocketPC Programm hinterlegt sein. Dieses Programm ist ja closed-source.

 

[Murray]

Alles klar, ich hatte zwischenzeitlich leicht den Überblick verloren, wer hier hier verschlüsseln und wer entschlüsseln soll, sorry.

 

[Benne]

Ich denke ich werde einfach eine Symmetrische Verschlüsselung nehmen dessen Klartextpasswort innerhalb einer Funktion generiert wird.
So steht z.B. das Passwort "1234" fest im ExportPlugin - wird aber vor der Verwendung noch manipuliert (vielleicht Bitverschieberei oder so - wäre für Vorschläge dankbar). So muss der "Angreifer" zumindest das Export-Plugin debuggen. Und wenn er so weit ist könnte er aber dann auch einfach die Verschlüsselungsfunktion auskommentieren. Denke das wäre das Maximum an Sicherheit das zu garantieren ist.

 

[SlaterB]

wie gesagt: nimm doch einen Zufallswert als Schlüssel,
der bei der Übertragung vorne weg mitgeliefert wird

oder der Schlüssel steht in einer separaten Textdatei

 

[Benne]

ne das geht nicht. Ich habe ja keine wirkliche Kommunikation zwischen den beiden Geräten. Es wird nur eine Datei generiert und der Benutzer kann selbst entscheiden wie die übertragen wird. Ich könnte höchstens das Passwort mit in die SQLite Datenbank schreiben - aber das wäre ja ganz schlecht ;-)