HTTPS/XML-Schnittstelle und RSA/SHA
Lude#
- programmiertechnik
Yo!
Wer kennt das nicht? - Man programmiert so vor sich hin und auf einmal stellt sich eine Frage.
In diesem Fall geht es bei mir um die Programmierung der Schufa XML-Schnittstelle (Nachfolger der SCDI-Schnittstelle ;-). Der Datenaustausch ist HTTPS/XML-basiert, eine Signierung des an die Schufa gerichteten Requests erfolgt mittels RSA/SHA.
Nun zur Frage:
Warum ist die genannte Signierung des Requests ueberhaupt erforderlich, bzw. sinnvoll? (SSL sorgt doch fuer "verschluesselte Sicherheit", ein Schufa-spezifizierter Sicherheitskontext fuer die Authentifizierung. OK, man kann den Erhalt des waehrend des Transportwegs unveraenderten Requests sicherstellen, da ansonsten die Signatur nicht mehr passt, aber genuegt das als Rechtfertigung fuer den Einsatz der genannten Technologie?)
Gruss,
Lude
Hi Lude,
Nun zur Frage:
Warum ist die genannte Signierung des Requests ueberhaupt erforderlich, bzw. sinnvoll? (SSL sorgt doch fuer "verschluesselte
Aber Lude, bei so einem heiklen Thema wie schufa ist es doch selbstverfreilich das die Daten verknuddelt werden ;-)
Viele Grüße, Rolf
Halihallo Lude#
In diesem Fall geht es bei mir um die Programmierung der Schufa XML-Schnittstelle (Nachfolger der SCDI-Schnittstelle ;-). Der Datenaustausch ist HTTPS/XML-basiert, eine Signierung des an die Schufa gerichteten Requests erfolgt mittels RSA/SHA.
Ich habe auf die schnelle keine genügenden Informationen über diese
Schnittstelle finden können, trotzdem versuche ich eine kurze
Antwort auf die Frage:
Warum ist die genannte Signierung des Requests ueberhaupt erforderlich, bzw. sinnvoll? (SSL sorgt doch fuer "verschluesselte Sicherheit", ein Schufa-spezifizierter Sicherheitskontext fuer die Authentifizierung. OK, man kann den Erhalt des waehrend des Transportwegs unveraenderten Requests sicherstellen, da ansonsten die Signatur nicht mehr passt, aber genuegt das als Rechtfertigung fuer den Einsatz der genannten Technologie?)
Die Signierung hat nicht nur den Zweck Änderungen an der Nachricht
während des Transportweges aufzudecken, sondern erfüllt auch die
Authentifizierung.
Sicherheit:
- Kein Dritter kann die Daten lesen (RSA Verschlüsselung/SSL)
- Kein Dritter kann die Daten unbemerkt verändern (Signatur)
- Kein Dritter kann die Daten eines authentischen Benutzers
vortäuschen (Signatur)
SSL erfüllt nur das erste und zweite Kriterium. Die Daten können
weder gelesen, noch unbemerkt verändert werden. Aber die
Serverapplikation hat keine (oder ungenügende) Möglichkeit den
Benutzer als "berechtigt" zu identifizieren (das ist die Aufgabe des
Anwendungsprogrammes, nicht die der Transportschicht).
Die Signatur deckt das zweite und dritte Kriterium ab. Eine
Veränderung der Nachricht kann aufgedeckt werden (die
Entschlüsselung des verschlüsselten SHA-1 Fingerabdrucks der
Nachricht stimmt nicht mehr überein), zudem kann aber auch
festgestellt werden, ob der Benutzer auch *der* Benutzer ist, da man
davon ausgehen kann/muss, dass nur dieser (und der Server) Kenntnis
vom geheimen Schlüssel hat und somit nur er einen SHA-1 Fingerabdruck
so verschlüsseln kann, dass beim Server der entschlüsselte
Fingerabdruck mit dem der gesendeten Nachricht übereinstimmt.
Fazit:
a) Beim Verwenden der Signatur geht es nicht nur um das Feststellen
einer Änderung der Nachricht auf dem Transportweg, sondern auch
um die Authentizität des Senders.
b) Falls der eingebaute "Authentifizierungs Sicherheitskontext"
geknackt wird, bringt es nichts, da die Signatur damit noch
nicht geknackt ist => Doppelt genäht hält besser :-)
c) Falls die bereits eingebaute Authentifizierung gut ist, dürfte
die Signatur "redundant" sein (aber genaues kann man hierzu nur
sagen, wenn man die (interne Funktionsweise der) Schnittstelle
gut kennt). Redundant im Sinne von "nice-to-have".
d) weiteres kann ich nicht sagen, da ich die Schnittstelle nicht
kenne.
Viele Grüsse
Philipp