"eigenes" Protokoll: Verschlüsselung

[DerNeueDa]

Hallo,

für eine Schnittstelle wird ein "eigenes" Protokoll auf Basis von TCP verwendet. Das Protokoll soll nun verschlüsselt werden.

Nun stellt sich die Frage: TLS oder Eigenbau?

Eigenbau würde sich wie folgt gestalten: Protokoll mit AES beim Sender verschlüsseln und beim Empfänger entschlüsseln. Die Schlüssel sind festgelegt und beiden Seiten bekannt, sie müssen nicht generiert oder zu Beginn von einer Seite übertragen werden.

Die Authentifizierung (Wer ist der Empfänger?) wird schon im Protokoll abgehandelt: Der Empfänger stellt eine Anfrage mit Zugangsdaten (Kundennummer und Passwort), der Server überprüft diese und sendet (im Erfolgsfall) dann die Antwort.

Ich stecke nicht so in der Zertifikatsthematik rund um TLS, so sehe ich vermutlich nicht die Vorteile von TLS.

Was meint ihr?

 

[Lord Gurke]

Naja, der Vorteil von TLS ist wohl, dass es schon fertig ist und aus so ziemlicher jeder Programmiersprache heraus verwendet werden kann.
Das Abrufen von Clientzertifikaten wird ebenfalls standardmäßig von SSLv3 und TLS unterstützt, so dass du auch da keinen großen Aufwand betreiben müsstest.

 

[DerNeueDa]

Da hast Du recht!

Der Nachteil der SSL-verschlüsselten Übertragung besteht darin, dass der Verbindungsaufbau auf Serverseite rechenintensiv und deshalb langsamer ist. Die Verschlüsselung selbst nimmt je nach verwendetem Algorithmus nur noch wenig Rechenzeit in Anspruch.

Trifft das aktuell noch zu?

Dank Hardwareunterstützung für AES und meiner einfachen (aber sicheren) Authentifizierung könnte ich doch performanter daher kommen, als wenn ich TLS nutze.

Zumal ich den Zertifikatskram nicht brauche und diesbezüglich eher Probleme bei Zugriffen von mobilen Plattformen (vor allem iOS) auf die Schnittstelle sehe -> können die das überhaupt?

 

[d4f]

meiner einfachen (aber sicheren) Authentifizierung

Der einzige Vorteil von asymmetrischer Verschlüsslung ist dass der Key nicht im Voraus sicher übertragen werden musste und somit keinem Angreifer bekannt sein kann. Dies gilt natürlich nur wenn die Chain-of-trust der SSL-Zertifikate sicher ist, im Idealfall über selbst-signierte Root-Zertifikate welche in der Applikation hinterlegt wurden.

Nach dem ressourcenintensiven asymmetrischen Handshake (welcher eigentlich nichts anderes tut als ein Passwort auswürfeln und übertragen) kommt eine Vielzahl von Algorithmen zum Zug, einer davon wäre AES.
Somit gibt es, bei entsprechender Konfiguration, die Wahl zwischen:

-TLS
Kein pre-shared key notwendig, jede Verbindung jedes Clients verwendet ein eigenes Passwort welches nur für diese eine Session gültig ist. Replay-Attacken und ähnliches sind ausgeschlossen. Nachteil ist ein rechenintesiver und langwieriger Handshake-Prozess zum Verbindungsbeginn

- reines AES
Einfach und schnell implementiert, aber jeder Client hat das gleiche Passwort. Auslesen einer Session und nachträgliches Entschlüsseln über ein extrahiertes Passwort (leicht aus der Binary zu erhalten) ist möglich, Protokoll verhindert keine Replay-Angriffe. Der Erhalt des Passworts aus dem Client kompromittiert alle Verbindungen.
Vorteil ist der niedrige Ressourcenhunger

[quotr]diesbezüglich eher Probleme bei Zugriffen von mobilen Plattformen (vor allem iOS) auf die Schnittstelle sehe -> können die das überhaupt?[/quote]
Natürlich, tls ist in https, startssl, ,in allen gängeigen Plattformen enthalten =)

 

[DerNeueDa]

Vielen Dank für Deine Meinung

- reines AES
Einfach und schnell implementiert, aber jeder Client hat das gleiche Passwort. Auslesen einer Session und nachträgliches Entschlüsseln über ein extrahiertes Passwort (leicht aus der Binary zu erhalten) ist möglich, Protokoll verhindert keine Replay-Angriffe. Der Erhalt des Passworts aus dem Client kompromittiert alle Verbindungen.
Vorteil ist der niedrige Ressourcenhunger

Jeder Client muss ja nicht zwingend das selbe Passwort haben. Gehen wir davon aus, dass viele Benutzer ihre eigenen (bei uns gespeicherten) Daten über die Schnittstelle abfragen, können wir je Benutzer ein anderes Passwort zur Verschlüsselung verwenden. Das Passwort könnte durch uns generiert und dem Benutzer mitgeteilt (bswp. per Post) werden. In dem Client kann der Benutzer das Passwort dann eintragen und mit seinen Zugangsdaten seine Daten abholen und entschlüsseln.

Natürlich, tls ist in https, startssl, ,in allen gängeigen Plattformen enthalten =)

Ja, klar. Ich meinte, ob TLS für Entwickler unter iOS im dem Maße zur Verfügung steht, das ein eigenes Protokoll über TCP mit TLS implementiert werden kann? iOS ist ja recht restriktiv.

 

[d4f]

iOS ist nicht _so_ restriktiv solange es nicht um etwas geht was Apple ein paar Cent weniger Einnahmen bringen könnte
Hier ist ein Beispiel wie du deine eigenen Zertifikate validieren kannst und somit das schwächste Glied von TLS, nämlich die Zertifierungsstellen, umgehst.
http://blog.asolutions.com/2011/02/...tificates-or-custom-root-certificates-in-ios/

Solange dein Server keine so begrenze Leistung hat dass der Unterschied zwischen reinem AES und TLS relevant ist würde ich TLS einsetzen - dessen Handshake Protokoll gilt als sicher und ist in einer App generell einfach zu implementieren.