Kennzeichen (S)icherheit: Verschlüsselungstechniken richtig eingesetzt

Verschlüsselung ist einer der Bereiche in der Programmierung, über den es viele falsche Vorstellungen gibt. Daraus resultiert eine oft unsichere Software. Unterschieden wird zwischen Verschlüsselungen für die Authentifizierung, der Kommunikation und der von Daten.

Mehr Infos

Kennzeichen (S)icherheit

In der "Kennzeichen S(icherheit)"-Kolumne setzen sich die Analysten des Unternehmens KuppingerCole mit Themen wie Identity- und Access Management sowie IT-Governance aus Softwareentwicklungsperspektive auseinander. Es geht vor allem um die Frage, wie man Sicherheit für Anwendungen standardisieren und externalisieren kann, um Sicherheit und Nachvollziehbarkeit bei optimiertem Entwicklungsaufwand zu erreichen.

Es gibt immer wieder Programmierneulinge – und leider auch erfahrene Softwareentwickler –, die für eine Authentifizierung mit Passwörtern eben diese mit einer Verschlüsselung schützen, gegebenenfalls sogar mit einer selbst geschriebenen Verschlüsselungsfunktion. Das hat mehrere gravierende Nachteile: Zum einen birgt die selbst geschriebene Verschlüsselung das erhebliche Risiko, dass die Funktion unsicher ist und sich leicht knacken lässt. Zum anderen ist das Verwenden von Betriebssystem-Funktionen nicht ohne Gefahr, denn bei einer Verschlüsselung ist ja ein Schlüssel zu verwenden. Wird dieser "hart kodiert", also in die Software fest verdrahtet, können Angreifer den Schlüssel leicht auslesen, sobald sie der Software habhaft werden. Und auch wenn der Schlüssel nicht fest oder sogar benutzerabhängig gewählt wird, besteht die Gefahr, dass er leichter herauszubekommen ist als das Passwort selbst. Best Practice bei der Passwort-Authentifizierung ist hingegen, sogenannte "Salted Hashes" zu verwenden, also parametrisierte Einwegfunktionen und eben keine Verschlüsselung.

Die gleichen Überlegungen zur "eigenen" Verschlüsselungsroutine bestehen auch für die Anwendungsfälle zum Schutz der Kommunikation und von Daten. Beim Schutz der Übertragung sollte idealerweise gar keine anwendungsspezifische Verschlüsselung verwendet werden, denn es gibt unzählige Fallstricke, etwa beim Aushandeln von Sitzungsschlüsseln; selbst wenn etablierte Verschlüsselungsbibliotheken im Einsatz sind. Hier gilt, die Verschlüsselung der Protokollschicht zu überlassen, etwa SSL/TLS bei HTTP oder WS-Secure Communication bei Webservices.

Sind Daten direkt in der Anwendung zu verschlüsseln, etwa um den Anforderungen einer PCI-DSS-Standardisierung (Payment Card Industry Data Security Standard) zu genügen, gibt es auch hier viele Möglichkeiten, in einen Fettnapf zu treten. Wenn etwa alle Daten mit einem gemeinsamen Schlüssel von der Anwendung geschützt werden, schützt die Maßnahme zwar gegen Angreifer auf Datenbank- beziehungsweise Betriebssystemebene, aber nicht gegen Angriffe, die über die Schnittstellen der Anwendung laufen. Und diese stellen heute den überwiegenden Teil der Angriffe dar. Verwendet man umgekehrt benutzerspezifische Schlüssel, die nur dem Benutzer zugänglich sind, besteht die Gefahr, dass die Daten gegebenenfalls nicht mehr verfügbar sind, wenn der Benutzer den Schlüssel nicht mehr findet – was durchaus oft passieren kann, wenn er die Anwendung nur selten benutzt. Für diesen Anwendungsfall lautet die Empfehlung, nicht nur etablierte Verschlüsselungsroutinen zu verwenden, sondern gleich ein vollständiges Paket zum kryptographischen Schutz von Daten, inklusive Schlüsselverwaltung, PKI und gegebenenfalls sogar Komponenten für das Information Rights Management.

Dieser kurze Überblick zeigt, dass das Verwenden von Verschlüsselung bei der Programmierung viele Fallstricke bietet und mit Bedacht anzugehen ist. Bei Zweifeln sollte man einen Experten hinzuziehen.

Sachar Paulus
ist Senior Analyst bei Kuppinger Cole, einem auf IAM, GRC, Cloud Computing und verwandten Themen spezialisierten Analystenunternehmen.

Die Kolumne bisher:

1. Anwendungsentwicklung und Sicherheit
2. An Ausbildung führt kein Weg vorbei
3. Fünf Gründe für die Externalisierung der Sicherheit
4. "Cloud-readiness" – Auswirkungen für Softwareentwickler
5. U-Prove – Microsofts Technik für Datensicherheit
6. Trends von der European Identity Conference
7. Braucht es eine andere Softwareentwicklung für sichere Cloud-Anwendungen?
8. Security bei der Entwicklung für die Cloud
9. Über den effizienten LDAP-Einsatz
10. Externalisierte Sicherheit – richtig gemacht
11. Türöffner für die sichere Cloud
12. Externalisierung von Identitäten für ein erfolgreiches Cloud Computing
13. XACML
    

(ane)