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.
Übrigens noch eine Buchempfehlung für jeden, der ein wenig was mit Crypto entwickeln muss: Ferguson: Cryptography Engineering
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 J. schrieb: > das ganze PKI-System steht auf ziemlich tönernen > Füßen, aber das ist ein anderes Thema). Kleiner Nachtrag: Wenn man es dann richtig versaut (private statt öffentliche Schlüssel verteilen) kommt dieser 1a Clusterfuck raus: https://www.heise.de/newsticker/meldung/beA-Schwere-Panne-beim-besonderen-elektronischen-Anwaltspostfach-3927314.html "Damit wird die Lage zunehmend kritisch."
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.