Ich habe den Auftrag bekommen, Teile einer SOAP Nachricht mit einem
x509v3 Zertifikat und einer Signatur abzusichern (in Java, nicht auf
µC). Ich habe mich zu dem Thema eingelesen und ein schon ein bisschen
programmiert. Aber ich bin nicht sicher, ob ich das Thema korrekt
verstanden habe.
Ich würde mich freuen, wenn jemand vom Fach meine folgenden Annahmen
prüfen kann und ggf. Fehler aufdeckt:
Die Signatur wird von einem Algorithmus erstellt, der die zu
signierenden Daten und meinen privaten Schlüssel als Eingabe Verwendet.
Der Empfänger der Nachricht braucht zur Überprüfung der Signatur die
signierten Daten sowie entweder meinen öffentlichen Schlüssel oder mein
Zertifikat. Technisch gesehen eignen sich beide gleichermaßen, der
Unterschied ist nur deren Glaubwürdigkeit.
Mein Zertifikat besteht im Wesentlichen aus meinem öffentlichen
Schlüssel, sowie zusätzliche Informationen, welche meine Identität
bestätigen.
Ist das soweit richtig? Fragen dazu:
Gibt es zu jedem privaten Schlüssel immer genau einen öffentlichen
Schlüssel, oder können mehrere unterschiedliche passende öffentliche
Schlüssel existieren?
Da das Zertifikat meine Identität bestätigt, ist es nicht sehr unsicher,
das gesamte Zertifikat als Bestandteil der SOAP Nachricht an den Server
des Geschäftspartners zu senden? Könnte ein dortiger Mitarbeiter dann
nicht einfach mein Zertifikat aus einem Logfile entnehmen und damit
meine Identität stehlen?
Im öffentlichen Internet ist das Zertifikat immer an eine Domain
gebunden, aber in meinem konkreten Fall kann das nicht sein. Denn ich
soll ein Zertifikat wieder verwenden, dass bereits in einem anderen
Rechenzentrum meines Arbeitgebers für eine ganz andere Schnittstelle
benutzt wurde. Angeblich kann ich es zu Testzwecken auch auf meinem
Desktop Computer benutzen obwohl der einen ganz andere IP Adresse auf
einer anderen Domain hat.
Wodurch unterscheidet sich ein x509v3 Zertifikat von einem beglaubigten
PGP Schlüssel (aus dem Email Umfeld)? Ist das abgesehen vom Dateiformat
und wer die Identität beglaubigen darf, prinzipiell das Selbe?
Stefan U. schrieb:> Ich habe den Auftrag bekommen, Teile einer SOAP Nachricht mit einem> x509v3 Zertifikat und einer Signatur abzusichern (in Java, nicht auf> µC).
Du kennst XML-DSig?
> Der Empfänger der Nachricht braucht zur Überprüfung der Signatur die> signierten Daten sowie entweder meinen öffentlichen Schlüssel oder mein> Zertifikat. Technisch gesehen eignen sich beide gleichermaßen, der> Unterschied ist nur deren Glaubwürdigkeit.
korrekt
> Mein Zertifikat besteht im Wesentlichen aus meinem öffentlichen> Schlüssel, sowie zusätzliche Informationen, welche meine Identität> bestätigen.
korrekt, sowie der digitalen Signatur der CA über diese Daten.
> Gibt es zu jedem privaten Schlüssel immer genau einen öffentlichen> Schlüssel, oder können mehrere unterschiedliche passende öffentliche> Schlüssel existieren?
nur einen
> Da das Zertifikat meine Identität bestätigt, ist es nicht sehr unsicher,> das gesamte Zertifikat als Bestandteil der SOAP Nachricht an den Server> des Geschäftspartners zu senden? Könnte ein dortiger Mitarbeiter dann> nicht einfach mein Zertifikat aus einem Logfile entnehmen und damit> meine Identität stehlen?
nein, er bräuchte den privaten Schlüssel um selbst Signaturen erzeugen
zu können und damit Deine Identität zu stehlen.
> Im öffentlichen Internet ist das Zertifikat immer an eine Domain> gebunden, aber in meinem konkreten Fall kann das nicht sein. Denn ich> soll ein Zertifikat wieder verwenden, dass bereits in einem anderen> Rechenzentrum meines Arbeitgebers für eine ganz andere Schnittstelle> benutzt wurde. Angeblich kann ich es zu Testzwecken auch auf meinem> Desktop Computer benutzen obwohl der einen ganz andere IP Adresse auf> einer anderen Domain hat.
Domain oder nicht ist nicht relevant. Spannend ist was da für
Inhaberdaten (Subject) und Erweiterte Inhaberdaten (Subject Alternative
Name) drinstehen.
> Wodurch unterscheidet sich ein x509v3 Zertifikat von einem beglaubigten> PGP Schlüssel (aus dem Email Umfeld)? Ist das abgesehen vom Dateiformat> und wer die Identität beglaubigen darf, prinzipiell das Selbe?
PGP verwendet das Web of Trust. Also jeder der mag, kann bestätigen, daß
der Inhaber eines Schlüssels der darin angegebene Inhaber ist. Über
mehrere Mittelsmänner findet sich dann der Theorie nach ein Pfad des
Vertrauens in die Inhaberdaten zwischen Dir und dem Empfänger einer
Nachricht. Desto kürzer dieser Pfad ist und desto mehr mögliche Wege es
gibt, desto vertrauenswürdiger wird das ganze.
X.509 verwendet dagegen das Modell der Zertifizierungsstellen. Eine
Zertifizierungsstelle prüft die Inhaberdaten und stellt dann ihr
Zertifikat aus. Entweder vertraust Du dieser Zertifizierungsstelle oder
nicht.
> Du kennst XML-DSig?
Ich hab es erst einmal mit den On-Board Klassen von Java 7 versucht.
Scheint zu klappen, denn ich kann meine Signatur erfolgreich überprüfen.
Ein Integrationstest gegen den Server des Geschäftspartner steht noch
aus. Wahrscheinlich wird er fehlschlagen, bei mir geht nämlich immer
alles schief, was schief gehen kann. Aber ich bin schnell geworden, auf
Pannen zu reagieren :-)
>> Könnte ein dortiger Mitarbeiter dann>> nicht ... meine Identität stehlen?> nein, er bräuchte den privaten Schlüssel um selbst Signaturen erzeugen> zu können und damit Deine Identität zu stehlen.
Ja, ist eigentlich logisch, jetzt wo ich nochmal darüber nachdenke.
Danke, auch für deine anderen Antworten.
Stefan U. schrieb:> Ich habe den Auftrag bekommen, Teile einer SOAP Nachricht mit einem> x509v3 Zertifikat und einer Signatur abzusichern (in Java, nicht auf> µC). Ich habe mich zu dem Thema eingelesen und ein schon ein bisschen> programmiert. Aber ich bin nicht sicher, ob ich das Thema korrekt> verstanden habe.
Was heißt in dem Zusammenhang "absichern"? Was soll erreicht werden?
Später schreibst du:
Stefan U. schrieb:> Ein Integrationstest gegen den Server des Geschäftspartner steht noch> aus.
Also geht es hier um gesicherte Datenübertragung, nicht um das Signieren
von Daten? Also, wenn es um sichere Übertragung mit Authentifizierung
und Integrity-Protection geht, da würde ich zuerst einmal gar nichts
selber basteln, sondern den vorhandenen Dingen ihren Lauf lassen.
* TLS aktivieren, also SOAP über https als Transport.
* Je nachdem, wer wen authentifizieren soll, nur die übliche TLS
Server-Authentifizierung verwenden oder zusätzlich TLS
Client-Authentifizierung einschalten.
* Die aushandelbaren TLS Cyphersuits so wählen das nur solche die ein
MAC verwenden zugelassen sind. Dabei aufpassen, dass man nicht
versehentlich einen der alten unsicheren Algorithmen wie MD4
einschaltet.
* Wenn man schon dabei ist: nur Cyphersuits mit vernünftiger
Verschlüsselung zulassen. Das TLS eine NULL-Encryption kennt heißt
nicht, dass das eine gute Idee ist.
> Mein Zertifikat besteht im Wesentlichen aus meinem öffentlichen> Schlüssel, sowie zusätzliche Informationen, welche meine Identität> bestätigen.
Ein Zertifikat ist selber ein signiertes Dokument. Das ist eine ganz
wichtige Eigenschaft eines Zertifikates. Erst die Signierung durch eine
vertrauenswürdige Stelle (eine CA), macht das Zertifikat, einschließlich
der Identitätsinformationen, vertrauenswürdig.
(in der Praxis gab es schon genug CAs die direkt oder indirekt jeden
Scheiß signiert haben, das ganze PKI-System steht auf ziemlich tönernen
Füßen, aber das ist ein anderes Thema).
> Gibt es zu jedem privaten Schlüssel immer genau einen öffentlichen> Schlüssel, oder können mehrere unterschiedliche passende öffentliche> Schlüssel existieren?
Das macht keinen Sinn. Ein öffentlicher Schlüssel ist öffentlich. Den
kann jeder haben. Mehrere öffentliche Schlüssel ergeben keinen besseren
Schutz, denn bereits einen zu besitzen reicht.
Es gibt ein paar Algorithmen, bei denen es für selektive Anwendungen
mehrere private (nicht öffentliche) Schlüssel zu einem öffentlichen
Schlüssel gibt. Aber das ist eine ganz andere Nummer.
> Da das Zertifikat meine Identität bestätigt,
Es bestätige nicht die Identität des "Besitzers", sondern, dass der
enthaltene öffentliche Schlüssel und die enthaltenen Identitätsdaten
zusammen gehören.
> ist es nicht sehr unsicher,> das gesamte Zertifikat als Bestandteil der SOAP Nachricht an den Server> des Geschäftspartners zu senden?
Das Zertifikat selber kannst du, wenn du willst ausdrucken und ans
schwarze Brett anschlagen. Das sind Informationen die öffentlich völlig
frei zugängig sein dürfen. Die Sicherheit liegt in den richtig
angewendeten Algorithmen.
> Könnte ein dortiger Mitarbeiter dann> nicht einfach mein Zertifikat aus einem Logfile entnehmen und damit> meine Identität stehlen?
Dann wäre grundsätzlich mit der Art und Weise wie dieses Zertifikat
verwendet wird was falsch - aber so richtig falsch. Ein
selbstgebastelter Algorithmus, der auf der Geheimhaltung von
Zertifikaten aufbaut ist kompletter Müll.
Wenn das reine Zusenden des Zertifikates der Identitätsnachweis ist,
statt der Abgleich der Daten im Zertifikat (d.h. die positive
Überprüfung der Daten), dann ist grundsätzlich was falsch.
> Im öffentlichen Internet ist das Zertifikat immer an eine Domain> gebunden,
Da ist nichts gebunden. Eine oder mehrere Domain-Namen sind in den
üblichen Zertifikaten Teil der Identitätsdaten.
Wenn die Information da ist und man sie beim Überprüfen des Zertifikats
ignoriert, dann ignoriert man die halt. Sollte man nicht, aber kann man.
Eine andere Information in Zertifikaten ist der Verwendungszweck (ist
eine gängige X509 Extension). Auch die sollte man aus gutem Grund
beachten, aber auch die kann man ignorieren wenn man richtig Mist bauen
möchte.
> aber in meinem konkreten Fall kann das nicht sein. Denn ich> soll ein Zertifikat wieder verwenden, dass bereits in einem anderen> Rechenzentrum meines Arbeitgebers für eine ganz andere Schnittstelle> benutzt wurde.
Jetzt fängt es an ganz merkwürdig zu riechen. "Wir haben da ein
Zertifikat für irgendwas, dass wir für was anderes einsetzen wollen"
WTF?!?
> Angeblich kann ich es zu Testzwecken auch auf meinem> Desktop Computer benutzen obwohl der einen ganz andere IP Adresse auf> einer anderen Domain hat.
Was heißt benutzen? Es kommt drauf an wozu. Als ein Zertifikat dem man
selbst vertraut, oder als eins, das man zum Nachweis der eigenen
Identität benutzt? Letzteres wäre fatal. Nicht zuletzt, weil du dafür
den privaten Schlüssel bekommen müsstest.
Nochmal zurück zu:
> Ein Integrationstest gegen den Server des Geschäftspartner steht noch> aus.
Heißt das, der Geschäftspartner liefert Daten über seinen Server? Soll
der die etwa mit Hilfe eures Zertifikats signieren?!?
Stefan U. schrieb:> bei mir geht nämlich immer> alles schief, was schief gehen kann.
Wie sage ich das jetzt? Vielleicht mal die
Hobbybastler-Schrauber-Mentalität ablegen und mehr die
Ingenieurs-Mentalität annehmen?
Weniger Wikipedia und Google, mehr Fachbücher und Normen?
Weniger kreatives Chaos, weniger Try-und-Error, mehr zielgerichtetes
Planen und methodisches Vorgehen?
Hannes, dein Verbesserungsvorschlag in allen ehren, er geht völlig an
meinem Auftrag vorbei. Ich habe die Schnittstelle nicht gestaltet und
niemand interessiert sich darüber, wie du oder ich das Konstrukt finden.
Das ist eher so: Entweder mache ich das wie verlangt, oder ich bin
meinen Job los.
Das Zertifikat soll den Absender "authorisieren" und die Signatur soll
Manipulaton der Daten unterbinden. So heisst es in der
Schnittstellenspezifikation. Als Transfer-Medium wird HTTPS mit fest
definierten Zertifikaten verwendet, aber das ist momentan nicht meine
Sorge.
Den privaten Schlüssel habe ich natürlich vorliegen. Den brauche ich ja
ohnehin zum signieren der Nachricht.
> Heißt das, der Geschäftspartner liefert Daten über seinen Server?
Mein Programm sendet eine Kundennummer und erhält in der Antwort des
Servers Daten über diesen Kunden.
Ich kann leider nicht alle Details offen legen, das ist kein Hobby
Projekt. Ganz im Gegenteil, es geht um sensitive persönliche Daten.
Danke für deine Antworten.
Deine abschließenden Unterstellungen ignoriere ich mal.
ich mache etwas das wohl in deine richtung geht.
ein webservice mit axis2 und rampart als WS-security. das zertifikat
liegt in einem java keystore, und wird vom webservice benutzt um
authentizität und integrität der emfangenen und dann gesendeten daten zu
gewährleisten.
hast du einen JKS bekommen? evtl auch ein XSL mit dem du java klassen
erzeugen kannst/sollst?
Stefan U. schrieb:> Ich kann leider nicht alle Details offen legen, das ist kein Hobby> Projekt. Ganz im Gegenteil, es geht um sensitive persönliche Daten.
Richtig. Und weil es sehr sensible Daten sind, macht das auch jemand
(nämlich Du), der so etwas noch nie gemacht hat.
Schöne neue Kryptowelt: Laien spielen mit Krypto rum, Hauptsache auf dem
Endprodukt kann "verschlüsselt" drauf gedruckt werden. Ist ja nun alles
"sicher"...
Haha. Wenn's nicht so traurig wäre...
Unbekannt U. schrieb:> Schöne neue Kryptowelt: Laien spielen mit Krypto rum
stell dir vor: ich benutze ssh ohne zu wissen wie es intern
funktioniert, ebenso SSL, und genau so verwende ich crypto apis wie
rampart und boucycastle. schocker
solche "man muss überall bis in jedes detail wissen wie was
funktioniert" apologeten haben unter garantie noch nie komplexe
frameworks benutzt um fette software zu erstellen, sondern immer nur
standard sprachelemente ihrer jeweiligen programmiersprache.
na dann viel spass beim selbst implementieren einer crypto api, eines
xml-parsers, eines PDF-generators… am besten noch mit assembler - ist eh
das beste (tm) ^^
oh, und wenn der scheff meckert, dass das ein paar 10 mannjahre braucht,
einfach darauf hinweisen das er ein laie ist.
@TO
vergessen… SoapUI kannst du benutzen um deinen webservice zu testen,
inclusive WS security.
Stefan U. schrieb:> Das Zertifikat soll den Absender "authorisieren" und die Signatur soll> Manipulaton der Daten unterbinden. So heisst es in der> Schnittstellenspezifikation. Als Transfer-Medium wird HTTPS mit fest> definierten Zertifikaten verwendet, aber das ist momentan nicht meine> Sorge.
Im Prinzip kann Transport Layer Security (TLS -- das "S" in HTTPS) in
den modernen Web Application Servern schon alles, was Du willst, bis auf
eine feingranulierte Autorisierung. Habe ich das Problem nicht
verstanden?
> hast du einen JKS bekommen? e
Nein, nur einzelne Files.
> schon alles, was Du willst
Was ich will, interessiert nicht. Ich habe einen Auftrag zu erledigen,
und zwar schnell, weil meine Andere ihn lange liegen gelassen haben und
dann absagten. Ich bin mal wieder die Feuerwehr.
DAS ist der Grund, warum ich heute dreimal so viel Geld verdiene, als
damals im Handwerk. Ich bade den Scheiß aus, den andere verbockt haben.
Sei es falsche Versprechungen, kaputte Software oder verpatzte Termine.
Da ist höchste Flexibilität und Kreativität gefragt - nicht
Professionalität. Für professionelles Arbeiten werden Akademiker
bezahlt, die im selben Raum sitzen.
> Schöne neue Kryptowelt: Laien spielen mit Krypto rum
Im Prinzip hast du damit Recht. Aber herum heulen hilft weder mir noch
der Firma die mir und meiner Familie das tägliche Brot besorgt.
Ergebnisse zählen.
Stefan U. schrieb:>> Schöne neue Kryptowelt: Laien spielen mit Krypto rum>> Im Prinzip hast du damit Recht. Aber herum heulen hilft weder mir noch> der Firma die mir und meiner Familie das tägliche Brot besorgt.> Ergebnisse zählen.
Mir schwant aber, Du (oder der Chef) reduzieren hier "Ergebnis" auf
"Programm funktioniert irgendwie".
Daß die Crypto korrekt eingesetzt wird und auch einem Audit standhält
wird vermutlich nicht dazugehören. Und das ist bei Crypto manchmal nicht
ganz so offensichtlich zu sehen wenn man die Mechanismen dahinter nicht
genau kennt und verstanden hat. Das Beispiel von Hannes mit dem
Anwaltspostfach zeigt genau dieses Problem und steht leider bei weitem
nicht alleine.
Von daher kann ich Hannes und den Unbekannten oben mit ihren Beiträgen
schon verstehen.
Mein Rat daher: Aufschlauen, dann echte Ergebnisse liefern.
Ein Weg dazu wäre meine obige Literaturempfehlung.
> Mir schwant aber, Du (oder der Chef) reduzieren hier "Ergebnis"> auf "Programm funktioniert irgendwie".
So ist. Die Vorgabe, wie die Schnittstelle zu funktionieren hat, ist
bereits von außen gegeben und steht nicht zu Diskussion. Sie wurde
bereits auditiert (schreibt man das so?).
Hast du schon einmal versucht, als Bittsteller eine Schnittstelle der
Telekom zu benutzen die seit 5 Jahren ungenutzt herum gammelt und bist
dabei auch noch in den Genuss gekommen, der erste Benutzer zu sein?
Vielleicht genügt das schon als Hinweis, um Mitleid zu erregen.
