Mercurial > trustbridge
view doc/help/client/techn-referenz.rst @ 1216:b46787ebbc05
Updated README. Added information about license and documentation.
author | Emanuel Schuetze <emanuel@intevation.de> |
---|---|
date | Wed, 24 Sep 2014 09:19:02 +0200 |
parents | cf1fdb254c41 |
children |
line wrap: on
line source
=================== Technische Referenz =================== Welche Zertifikatsspeicher werden verwendet? ============================================ Damit Zertifikaten in Anwendungen (wie z.B. Browser oder E-Mail-Klient) vertraut werden kann, müssen die zugehörigen Wurzelzertifikate in den passenden Zertifikatsspeichern des Systems installiert werden. TrustBridge übernimmt diesen Zugriff auf die Zertifikatsspeicher. Es gibt zwei gängige Zertifikatsspeicher, die von TrustBridge und den meisten Anwendungen unterstützt werden: * der Mozilla NSS-Zertifikatsspeicher ("Network Security Services") und * der Windows-System-Zertifikatsspeicher. Chrome bzw. Chromium verwendet unter Windows den Windows-System-Speicher und unter Ubuntu den NSS-Zertifikatsspeicher. Die nachfolgende Abbildung veranschaulicht die verwendeten Zertifikatsspeicher unter Windows und GNU/Linux. .. figure:: _static/stores.png :width: 100% :alt: Übersicht der Zertifikatsspeicher *Abbildung 1: Übersicht der Zertifikatsspeicher* Windows-Zertifikatsspeicher --------------------------- Der Windows 7 und 8 Zertifikatsspeicher kann in drei große Gruppen aufgeteilt werden: #. Zertifikate des aktuellen Benutzers #. Zertifikate für alle Benutzer (Lokaler Computer) #. Zertifikate für Systemdienste Diese Gruppen unterteilen sich wieder in eine Reihe von logischen Speichern. Für die Installation von vertrauenswürdigen Wurzelzertifikaten ist der logische *Root*-Speicher relevant. Nur dort eingetragene Zertifikate werden als *Trust Anchor* (Vertrauensanker) angesehen und zur Validierung des Vertrauenspfads zu den weiteren Zertifikaten verwendet. Der logische *Disallowed*-Speicher hat immer Vorrang. Befindet sich ein Zertifikat sowohl im *Root* als auch im *Disallowed*-Speicher, gilt es als nicht vertrauenswürdig. **Einschränkungen:** Um unbefugte Manipulationen am Zertifikatsspeicher zu verhindern, werden von Microsoft seit Windows XP SP2 folgende Schutzmaßnahmen vorgesehen: #. Um Zertifikate für alle Benutzer des lokalen Computers zu bearbeiten, sind erhöhte Privilegien (Administrationsrechte) erforderlich. #. Änderungen (Löschen / Hinzufügen von Zertifikaten) am *Root*-Speicher des aktuellen Nutzers erfordern die explizite Einwilligung des Nutzers (siehe nachfolgende Abbildung), sofern der Prozess keine erhöhten Privilegien besitzt. .. figure:: _static/sicherheitswarnung.png :alt: Windows-Sicherheitswarnung *Abbildung 2: Sicherheitswarnung beim Hinzufügen eines Wurzelzertifikats ohne Administrator-Rechte* Mozilla NSS-Zertifikatsspeicher ------------------------------- Die Mozilla-Anwendungen Thunderbird und Firefox, sowie Chromium unter Ubuntu, verwenden die Mozilla "Network Security Services" (NSS) Zertifikatsspeicher. Mozilla liefert den NSS-Zertifikatsspeicher mit einer Auswahl von voreingesetllten vertrauenswürdigen bzw. nicht vertrauenswürdigen Zertifikaten aus. **Einschränkungen:** * Anwendungen, die den NSS-Zertifikatsspeicher verwenden, sollten vor dem Zugriff geschlossen werden. * Um den NSS-Speicher anderer Nutzer zu manipulieren, sind erhöhte Rechte nötig. * Um den NSS-Standard für neue Profile vorzugeben, sind abhängig vom Installationsort ggf. erhöhte Rechte nötig. Wie wird der Transport abgesichert? =================================== TrustBridge sucht regelmäßig (alle 24 Stunden) auf dem offiziellen TrustBridge-Update-Server nach aktualisierten Zertifikatslisten und neuen Softwareversionen. Sämtliche Transportprozesse sind kryptografisch nach aktuellem Stand der Technik gegen unbefugte Manipulationen (Authentizität und Integrität) gesichert. Es gibt drei Transportwege, die abgesichert werden müssen: #. Verfügbarkeit von Aktualisierungen prüfen: Die regelmäßige Übertragung der Information, ob neue Aktualisierungen von Zertifikatsliste oder Software verfügbar sind, wird über eine HTTPS-Verbindung per TLS 1.2 (mit ECDSA brainpoolP256r1) durchgeführt. #. Zertifikatslisten-Update durchführen: Ist eine neue Zertifikatsliste verfügbar, wird die ganze Liste gebündelt übertragen. Die Zertifikatslistendatei ist signiert (RSA 3076). Vor einem Zertifikatslisten-Update wird sichergestellt, dass TrustBridge bereits in der neusten Version installiert ist. #. Software-Update durchführen: Ist eine neue TrustBridge-Version verfügbar, kann diese mit einem Klick auf eine entsprechende Meldung heruntergeladen und installiert werden. Es wird eine vollständige TrustBridge-Installationsdatei übertragen und im Hintergrund ausgeführt. Jede Software-Installationsdatei ist signiert. Bei Fehlschlagen der Signaturprüfung (z.B. durch fehlerhaftes Herunterladen) wird TrustBridge nicht aktualisiert. Wie sieht das Datenformat einer Zertifikatsliste aus? ===================================================== Die Zertifikatsliste ist eine einzelne Text-Datei, welche von der TrustBridge-Verwaltungsanwendung erzeugt wird. Diese Datei enthält alle benötigten Informationen und basiert auf einer zeilenbasierten Textformat. Dabei bleibt die Struktur für Menschen lesbar und die meisten Inhalte können mit Standardwerkzeugen sowohl de- als auch enkodiert werden. In der ersten Zeile der Datei ist die Base64-kodierte, kryptografische Signatur über alle folgenden Zeilen (inklusive der Zeilenenden) angegeben. So wird die Integrität und Authentizität dieser Daten vor der Verarbeitung gesichert. Einzelne Zeilen haben das Format ``<Buchstabe>:<Wert><CR><LF>``, wobei der Buchstabe angibt, welche Art von Wert folgt. Die Länge der Zeilen ist (für Version 1) auf 9999 Zeichen begrenzt, inklusive der beiden Zeichen für Zeilenenden. Die Anzahl der Zeilen ist auf 1000 beschränkt, was einer Dateigröße von maximal 10 Megabyte entspricht. (In der Praxis wird die Dateigröße aber deutlich unter 100 Kilobyte liegen.) Der Text wird in 7Bit-ASCII kodiert. Die Zertifikate selbst werden als Base64- und DER-kodierte Daten aufgeführt. Dies entspricht dem Inhalt gängiger .pem-Dateien - jedoch ohne den umschließenden BEGIN CERTIFICATE und END CERTIFICATE sowie ohne den Zeilenumbrüchen. Jede Zeile muss mit einem der folgenden gültigen Buchstaben beginnen: * ``S:`` Die Signatur der Zertifikatsliste. * ``F:`` Format-Version * ``D:`` Zeitpunkt der Listenerstellen (UTC) * ``I:`` Zu installierendes Zertifikat * ``R:`` Zu entfernendes Zertifikat Im Folgenden ein Beispiel für den Aufbau der Zertifikatslisten-Datei mit zwei zu installierenden Zertifikaten und einem zu löschenden Zertifikat. Die Signatur- und Zertifikatszeilen sind, aus Gründen der Übersichtlichkeit, in diesem Beispiel gekürzt: .. parsed-literal:: S:EjzX0sTkstnnGbPIC7n1a5WlYCFsthPl8OYplLyihR1RdqcUsSnikrVowFo8QgpMutcz0... F:1 D:2014-01-03T12:30Z I:MIIEiTCCA3GgAwIBAgIDAWn+MA0GCSqGSIb3DQBQUAMEAxCzAJBVBAYTAlVTMRcwFQYDV... I:MIIHojCCBoqgAwIBAgIDAW96MA0GCSqGSIb3DQEBBQUAGMMQswCDVQQGEwJJTDEWMBQGA... R:MIIGUjCCBTqgAwIBAgIODocAAQACqS54FrSbGvYwDQKoZIhvcNAQBQAwfDELMAkGA1UEB...