Public Key Infrastructure: Unterschied zwischen den Versionen

Aus Foxwiki
Versionsgeschichte interaktiv durchsuchen
VisuellWikitext
Die Seite wurde neu angelegt: „== Public Key Infrastructures == Public-Key Infrastructures try to solve the problem of verifying whether a public key belongs to a given entity, so as to prevent Man In The Middle attacks. There are two approaches to achieve that: ''Certificate Authorities'' and the ''Web of Trust''. Certificate Authorities (CAs) sign end-entities’ certificates, thereby associating some kind of identity (e.g. a domain name or an email address) with a public key. CAs ar…“
 
K Textersetzung - „Kryptografies“ durch „Kryptografie“
 
(34 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
== Public Key Infrastructures ==
== Public-Key-Infrastrukturen ==
Public-Key Infrastructures try to solve the problem of verifying whether a public key belongs to a given entity, so as to prevent Man In The Middle attacks.
Public-Key-Infrastrukturen versuchen das Problem zu lösen, zu überprüfen, ob ein öffentlicher Schlüssel zu einer bestimmten Einheit gehört, um Man-in-the-Middle-Angriffe zu verhindern.
There are two approaches to achieve that: ''Certificate Authorities'' and the ''Web of Trust''.
Certificate Authorities (CAs) sign end-entities’ certificates, thereby associating some kind of identity (e.g. a domain name or an email address) with a public key. CAs are used with TLS and S/MIME certificates, and the CA system has a big list of possible and real problems which are summarized in section [https://bettercrypto.org/#hardeningpki Hardening PKI] and ([https://bettercrypto.org/#bibliography-default-https13 Durumeric, Kasten, Bailey, & Halderman, 2013]).
The Web of Trust is a decentralized system where people sign each other’s keys, so that there is a high chance that there is a "trust path" from one key to another. This is used with PGP keys, and while it avoids most of the problems of the CA system, it is more cumbersome.
As alternatives to these public systems, there are two more choices: running a private CA, and manually trusting keys (as it is used with SSH keys or manually trusted keys in web browsers).
The first part of this section addresses how to obtain a certificate in the CA system. The second part offers recommendations on how to improve the security of your PKI.


=== Certificate Authorities ===
; Ansätze
In order to get a certificate, you can find an external CA willing to issue a certificate for you, run your own CA, or use self-signed certificates. As always, there are advantages and disadvantages for every one of these options; a balance of security versus usability needs to be found.
# Certificate Authorities
# Web of Trust


==== Certificates From an External Certificate Authority ====
; Zertifizierungsstellen (CA)
There is a fairly large number of commercial CAs that will issue certificates for money. Some of the most ubiquitous commercial CAs are Verisign, GoDaddy, and Teletrust. However, there are also CAs that offer certificates for free. The most notable examples are StartSSL, which is a company that offers some types of certificates for free, and CAcert, which is a non-profit volunteer-based organization that does not charge at all for issuing certificates. Finally, in the research and education field, a number of CAs exist that are generally well-known and well-accepted within the higher-education community.
* signieren die Zertifikate von Endteilnehmern und verknüpfen so eine Art von Identität (z. B.  einen Domänennamen oder eine E-Mail-Adresse) mit einem öffentlichen Schlüssel.  
A large number of CAs is pre-installed in client software’s or operating system’s`‘trust stores’'; depending on your application, you have to select your CA according to this, or have a mechanism to distribute the chosen CA’s root certificate to the clients.
* CAs werden mit TLS- und S/MIME-Zertifikaten verwendet, und das CA-System hat eine lange Liste möglicher und tatsächlicher Probleme, die im Abschnitt [https://bettercrypto.org/#hardeningpki Hardening PKI] und ([https://bettercrypto.org/#bibliography-default-https13 Durumeric, Kasten, Bailey, & Halderman, 2013]) zusammengefasst sind.
When requesting a certificate from a CA, it is vital that you generate the key pair yourself. In particular, the private key should never be known to the CA. If a CA offers to generate the key pair for you, you should not trust that CA.
Generating a key pair and a certificate request can be done with a number of tools. On Unix-like systems, it is likely that the OpenSSL suite is available to you.  


In this case, you can generate a private key and a corresponding certificate request as follows:
; Web of Trust
Das Web of Trust ist ein dezentralisiertes System, bei dem Menschen gegenseitig ihre Schlüssel signieren, so dass die Wahrscheinlichkeit hoch ist, dass es einen "Vertrauenspfad" von einem Schlüssel zum anderen gibt.
* Es wird mit PGP-Schlüsseln verwendet, und obwohl es die meisten Probleme des CA-Systems vermeidet, ist es umständlicher.
 
; Alternativen
Als Alternativen zu diesen öffentlichen Systemen gibt es zwei weitere Möglichkeiten
* Die Verwendung einer privaten Zertifizierungsstelle und das manuelle Vertrauen in Schlüssel (wie es bei SSH-Schlüsseln oder manuell vertrauenswürdigen Schlüsseln in Webbrowsern verwendet wird).
** Der erste Teil dieses Abschnitts befasst sich damit, wie man ein Zertifikat im CA-System erhält.
* Der zweite Teil enthält Empfehlungen, wie Sie die Sicherheit Ihrer PKI verbessern können.
 
=== Zertifizierungsstellen ===
Um ein Zertifikat zu erhalten, können Sie eine externe Zertifizierungsstelle finden, die bereit ist, ein Zertifikat für Sie auszustellen, Ihre eigene Zertifizierungsstelle betreiben oder selbst signierte Zertifikate verwenden.
* Wie immer gibt es Vor- und Nachteile für jede dieser Optionen; es muss ein Gleichgewicht zwischen Sicherheit und Benutzerfreundlichkeit gefunden werden.
 
==== Zertifikate von einer externen Zertifizierungsstelle ====
; Es gibt eine ziemlich große Anzahl kommerzieller Zertifizierungsstellen, die gegen Geld Zertifikate ausstellen.
* Einige der bekanntesten kommerziellen CAs sind Verisign, GoDaddy und Teletrust.
* Es gibt jedoch auch CAs, die kostenlose Zertifikate anbieten.
* Die bekanntesten Beispiele sind StartSSL, ein Unternehmen, das einige Arten von Zertifikaten kostenlos anbietet, und CAcert, eine gemeinnützige, ehrenamtlich tätige Organisation, die für die Ausstellung von Zertifikaten keinerlei Gebühren erhebt.
* Im Forschungs- und Bildungsbereich schließlich gibt es eine Reihe von Zertifizierungsstellen, die in der Regel in der Hochschulgemeinschaft bekannt und akzeptiert sind.
 
; Eine große Anzahl von Zertifizierungsstellen ist in den Vertrauensspeichern von Client-Software oder Betriebssystemen vorinstalliert
* je nach Anwendung müssen Sie Ihre Zertifizierungsstelle entsprechend auswählen oder über einen Mechanismus verfügen, um das Stammzertifikat der gewählten Zertifizierungsstelle an die Clients zu verteilen.
 
; Wenn Sie ein Zertifikat bei einer CA beantragen, müssen Sie das Schlüsselpaar unbedingt selbst erzeugen.
* Vor allem der private Schlüssel sollte der CA niemals bekannt sein.
* Wenn eine Zertifizierungsstelle anbietet, das Schlüsselpaar für Sie zu erzeugen, sollten Sie dieser Zertifizierungsstelle nicht vertrauen.
 
; Die Erzeugung eines Schlüsselpaares und einer Zertifikatsanforderung kann mit einer Reihe von Werkzeugen durchgeführt werden.
* Auf Unix-ähnlichen Systemen ist es wahrscheinlich, dass Ihnen die OpenSSL-Suite zur Verfügung steht.
 
; In diesem Fall können Sie einen privaten Schlüssel und eine entsprechende Zertifikatsanforderung wie folgt erzeugen:
  $ openssl req -new -nodes -keyout <servername>.key -out <servername>.csr -newkey rsa:<keysize> -sha256
  $ openssl req -new -nodes -keyout <servername>.key -out <servername>.csr -newkey rsa:<keysize> -sha256
  Country Name (2 letter code) [AU]:DE
  Country Name (2 letter code) [AU]:DE
Zeile 30: Zeile 55:
  An optional company name []:
  An optional company name []:


==== Setting Up Your Own Certificate Authority ====
==== Einrichten einer eigenen Zertifizierungsstelle ====
In some situations it is advisable to run your own certificate authority. Whether this is a good idea depends on the exact circumstances. Generally speaking, the more centralized the control of the systems in your environment, the fewer pains you will have to go through to deploy your own CA. On the other hand, running your own CA maximizes the trust level that you can achieve because it minimizes external trust dependencies.
In manchen Situationen ist es ratsam, eine eigene Zertifizierungsstelle zu betreiben.  
* Ob dies eine gute Idee ist, hängt von den genauen Umständen ab.  
* Im Allgemeinen gilt: Je zentralisierter die Kontrolle der Systeme in Ihrer Umgebung ist, desto weniger Aufwand müssen Sie für die Einrichtung Ihrer eigenen Zertifizierungsstelle betreiben.  
* Andererseits maximiert der Betrieb einer eigenen Zertifizierungsstelle das Vertrauensniveau, das Sie erreichen können, da externe Abhängigkeiten minimiert werden.


Again using OpenSSL as an example, you can set up your own CA with the following commands on a Debian system:
Wiederum unter Verwendung von OpenSSL als Beispiel, können Sie Ihre eigene CA mit den folgenden Befehlen auf einem Debian-System einrichten:
  $ cd /usr/lib/ssl/misc
  $ cd /usr/lib/ssl/misc
  $ sudo ./CA.pl -newca
  $ sudo ./CA.pl -newca
  Answer the questions according to your setup. Now that you have configured your basic settings and issued a new root certificate, you can issue new certificates as follows:
  Answer the questions according to your setup.  
* Now that you have configured your basic settings and issued a new root certificate, you can issue new certificates as follows:
  $ cd /usr/lib/ssl/misc
  $ cd /usr/lib/ssl/misc
  $ sudo ./CA.pl -newreq
  $ sudo ./CA.pl -newreq
Alternatively, software such as TinyCA that acts as a "wrapper" around OpenSSL and tries to make life easier is available.


==== Creating a Self-Signed Certificate ====
Alternativ gibt es Software wie TinyCA, die als "Wrapper" um OpenSSL herum agiert und versucht, das Leben einfacher zu machen.
If the desired trust level is very high and the number of systems involved is limited, the easiest way to set up a secure environment may be to use self-signed certificates. A self-signed certificate is not issued by any CA at all, but is signed by the entity that it is issued to. Thus, the organizational overhead of running a CA is eliminated at the expense of having to establish all trust relationships between entities manually.
 
With OpenSSL, you can self-sign a previously created certificate with this command:
==== Erstellen eines selbstsignierten Zertifikats ====
$ openssl req -new -x509 -key privkey.pem -out cacert.pem -days 1095
Wenn das gewünschte Vertrauensniveau sehr hoch und die Anzahl der beteiligten Systeme begrenzt ist, kann der einfachste Weg, eine sichere Umgebung einzurichten, die Verwendung selbst signierter Zertifikate sein.  
You can also create a self-signed certificate in just one command:
* Ein selbstsigniertes Zertifikat wird nicht von einer Zertifizierungsstelle ausgestellt, sondern von der Einrichtung, für die es ausgestellt wurde, signiert.  
$ openssl req -new -x509 -keyout privkey.pem -out cacert.pem -days 1095 -nodes -newkey rsa:<keysize> -sha256
* Auf diese Weise entfällt der organisatorische Aufwand, der mit dem Betrieb einer Zertifizierungsstelle verbunden ist, auf Kosten der Notwendigkeit, alle Vertrauensbeziehungen zwischen Entitäten manuell herzustellen.
The resulting certificate will by default not be trusted by anyone at all, so in order to be useful, the certificate will have to be made known a priori to all parties that may encounter it.


=== Hardening PKI ===
; Mit OpenSSL können Sie ein zuvor erstelltes Zertifikat mit diesem Befehl selbst signieren:
In recent years several CAs were compromised by attackers in order to get a hold of trusted certificates for malicious activities. In 2011 the Dutch CA Diginotar was hacked and all certificates were revoked&nbsp;([https://bettercrypto.org/#bibliography-default-diginotar-hack Elinor Mills, 2011]). Recently Google found certificates issued to them, which were not used by the company&nbsp;([https://bettercrypto.org/#bibliography-default-googlecahack Damon Poeter, 2011]). The concept of PKIs heavily depends on the security of CAs. If they get compromised the whole PKI system will fail. Some CAs tend to incorrectly issue certificates that were designated to do a different job than what they were intended to by the CA&nbsp;([https://bettercrypto.org/#bibliography-default-gocode Adam Langley, et. al., 2013]).
$ openssl req -new -x509 -key privkey.pem -out cacert.pem -days 1095
Therefore several security enhancements were introduced by different organizations and vendors&nbsp;([https://bettercrypto.org/#bibliography-default-tschofenig-webpki H. Tschofenig and E. Lear, 2013]). Currently two methods are used, DANE ([https://bettercrypto.org/#bibliography-default-rfc6698 Hoffman & Schlyter, 2012]) and Certificate Pinning&nbsp;([https://bettercrypto.org/#bibliography-default-draft-ietf-websec-key-pinning C. Evans and C. Palmer, 2013]). Google recently proposed a new system to detect malicious CAs and certificates called Certificate Transparency&nbsp;([https://bettercrypto.org/#bibliography-default-certtransparency Adam Langley, Ben Laurie, Emilia Kasper, 2013]). In addition, RFC 6844 describes Certification Authorization Records, a mechanism for domain name owners to signal which Certificate Authorities are authorized to issue certificates for their domain.
 
; Sie können auch ein selbstsigniertes Zertifikat mit nur einem Befehl erstellen:
$ openssl req -new -x509 -keyout privkey.pem -out cacert.pem -days 1095 -nodes -newkey rsa:<keysize> -sha256
Das daraus resultierende Zertifikat wird standardmäßig von niemandem als vertrauenswürdig eingestuft. Um also nützlich zu sein, muss das Zertifikat allen Parteien, die damit in Berührung kommen könnten, a priori bekannt gemacht werden.
 
=== Härtung der PKI ===
In den letzten Jahren wurden mehrere Zertifizierungsstellen von Angreifern kompromittiert, um an vertrauenswürdige Zertifikate für böswillige Aktivitäten heranzukommen.  
* Im Jahr 2011 wurde die niederländische Zertifizierungsstelle Diginotar gehackt und alle Zertifikate wurden widerrufen&nbsp;([https://bettercrypto.org/#bibliography-default-diginotar-hack Elinor Mills, 2011]).  
* Kürzlich fand Google auf sie ausgestellte Zertifikate, die von dem Unternehmen nicht verwendet wurden&nbsp;([https://bettercrypto.org/#bibliography-default-googlecahack Damon Poeter, 2011]).  
* Das Konzept der PKI hängt stark von der Sicherheit der Zertifizierungsstellen ab.  
* Wenn diese kompromittiert werden, fällt das gesamte PKI-System aus.  
* Einige Zertifizierungsstellen neigen dazu, fälschlicherweise Zertifikate auszustellen, die für eine andere Aufgabe als die von der Zertifizierungsstelle vorgesehene bestimmt sind&nbsp;([https://bettercrypto.org/#bibliography-default-gocode Adam Langley, et. al., 2013]).
Daher wurden verschiedene Sicherheitsverbesserungen von verschiedenen Organisationen und Anbietern eingeführt&nbsp;([https://bettercrypto.org/#bibliography-default-tschofenig-webpki H. Tschofenig und E. Lear, 2013]).  
* Derzeit werden zwei Methoden verwendet, DANE ([https://bettercrypto.org/#bibliography-default-rfc6698 Hoffman & Schlyter, 2012]) und Certificate Pinning&nbsp;([https://bettercrypto.org/#bibliography-default-draft-ietf-websec-key-pinning C. Evans und C. Palmer, 2013]).  
* Google hat kürzlich ein neues System zur Erkennung bösartiger CAs und Zertifikate namens Certificate Transparency&nbsp;([https://bettercrypto.org/#bibliography-default-certtransparency Adam Langley, Ben Laurie, Emilia Kasper, 2013]) vorgeschlagen.  
* Darüber hinaus beschreibt RFC 6844 Certification Authorization Records, einen Mechanismus, mit dem Inhaber von Domänennamen angeben können, welche Zertifizierungsstellen berechtigt sind, Zertifikate für ihre Domäne auszustellen.


=== Certification Authorization Records ===
=== Certification Authorization Records ===
RFC 6844 describes Certification Authorization Records, a mechanism for domain name owners to signal which Certificate Authorities are authorized to issue certificates for their domain.
RFC 6844 beschreibt Certification Authorization Records, einen Mechanismus, mit dem Inhaber von Domänennamen angeben können, welche Zertifizierungsstellen berechtigt sind, Zertifikate für ihre Domäne auszustellen.
When a CAA record is defined for a particular domain, it specifies that the domain owner requests Certificate Authorities to validate any request against the CAA record. If the certificate issuer is not listed in the CAA record, it should not issue the certificate.
Wenn ein CAA-Datensatz für eine bestimmte Domäne definiert ist, gibt er an, dass der Domäneninhaber die Zertifizierungsstellen auffordert, jede Anfrage anhand des CAA-Datensatzes zu validieren.  
The RFC also permits Certificate Evaluators to test an issued certificate against the CAA record, but should exercise caution, as the CAA record may change during the lifetime of a certificate, without affecting its validity.
* Wenn der Zertifikatsaussteller nicht im CAA-Eintrag aufgeführt ist, sollte er das Zertifikat nicht ausstellen.
CAA also supports an iodef property type which can be requested by a Certificate Authority to report certificate issue requests which are inconsistent with the issuer’s Certificate Policy.
Der RFC erlaubt auch Zertifikatsauswertern, ein ausgestelltes Zertifikat anhand des CAA-Datensatzes zu prüfen, wobei jedoch Vorsicht geboten ist, da sich der CAA-Datensatz während der Lebensdauer eines Zertifikats ändern kann, ohne dessen Gültigkeit zu beeinträchtigen.
CAA unterstützt auch einen iodef-Eigenschaftstyp, der von einer Zertifizierungsstelle angefordert werden kann, um Anträge auf Ausstellung von Zertifikaten zu melden, die nicht mit der Zertifikatsrichtlinie des Ausstellers übereinstimmen.


==== Configuration of CAA records ====
==== Konfiguration der CAA-Datensätze ====
BIND supports CAA records as of version 9.9.6.
BIND unterstützt CAA-Records ab Version 9.9.6.
A CAA record can be configured by adding it to the zone file:
; Ein CAA-Eintrag kann konfiguriert werden, indem er zur Zonendatei hinzugefügt wird:
$ORIGIN example.com
$ORIGIN example.com
       CAA 0 issue "ca1.example"
       CAA 0 issue "ca1.example"
       CAA 0 iodef "mailto:security@example.com"
       CAA 0 iodef "mailto:security@example.com"
If your organization uses multiple CA’s, you can configure multiple records:
 
; Wenn Ihr Unternehmen mehrere CAs verwendet, können Sie mehrere Datensätze konfigurieren:
       CAA 0 issue "ca1.example"
       CAA 0 issue "ca1.example"
       CAA 0 issue "ca2.example"
       CAA 0 issue "ca2.example"
"ca1.example" and "ca2.example" are unique identifiers for the CA you plan on using. These strings can be obtained from your Certificate Authority, and typically are its top level domain. An example is "letsencrypt.org" for the Let’s Encrypt CA operated by the Internet Security Research Group.
* "ca1.example" und "ca2.example" sind eindeutige Bezeichner für die CA, die Sie verwenden möchten.  
Knot-DNS supports CAA records as of version 2.2.0.
* Diese Zeichenfolgen können von Ihrer Zertifizierungsstelle bezogen werden und sind in der Regel die Top-Level-Domain.  
* Ein Beispiel ist "letsencrypt.org" für die von der Internet Security Research Group betriebene Let's Encrypt CA.Knot-DNS unterstützt CAA-Einträge ab Version 2.2.0.


==== Validation of CAA records ====
==== Validation of CAA records ====
Once a CAA record is deployed, it can be validated using the following dig query:
; Sobald ein CAA-Datensatz bereitgestellt wurde, kann er mit der folgenden Abfrage validiert werden:
  $ dig CAA google.com
  $ dig CAA google.com
  <nowiki>; <<>> DiG 9.10.3-P4-Debian <<>> CAA google.com</nowiki>
  <nowiki>; <<>> DiG 9.10.3-P4-Debian <<>> CAA google.com</nowiki>
  <nowiki>;; ANSWER SECTION:</nowiki>
  <nowiki>;; ANSWER SECTION:</nowiki>
  google.com.          3600 IN  CAA  0 issue "symantec.com"
  google.com.          3600 IN  CAA  0 issue "symantec.com"
On older versions of Dig, which do not support CAA records, you can query the record type manually:
 
; Bei älteren Versionen von Dig, die keine CAA-Datensätze unterstützen, können Sie die Datensatzart manuell abfragen:
  $ dig +short -t TYPE257 google.com
  $ dig +short -t TYPE257 google.com
  \# 19 0005697373756573796D616E7465632E636F6D
  \# 19 0005697373756573796D616E7465632E636F6D
= Aufbau einer PKICA Hierarchie =
=== Struktur einer PKI ===
=== Integration in die Zertifizierungshierarchie ===
=== Bestandteil des Gesamtkonzepts für einheitliche Authentifizierung und Identity Management ===
=== 3-stufige Hierarchie ===
=== Ebene 1 ohne Netzwerkanschluss, verschlüsselte Datenhaltung ===
=== Zugriff auf Ebene 1 CA nur über tresorgelagerten Datenträger, Ebene 2 über Token ===
=== Zugriff geregelt durch Policy, Rechner in Sicherheitsbereich ===
=== Ebene 2 für die Integration weiterer Institutionen ===
== X.509v3 Zertifikate  ==
* Bindet Identität an öffentlichen Schlüssel
* X.500 DN, DNS Name, Email-Adresse, URI, IP-Adresse
* Gibt verwendete Signaturalgorithmen an
* Zusatzfelder erlauben es weitere Information zu bestätigen
* Z.B. Zugriffsrechte
== Zertifikate in Web-Browsern ==
== Organisation und Technik ==
== Aufwand: Identifizierung! ==
=== Ablauf der Zertifizierung (bei GWDG-CA und Sub-CAs) ===
=== Benutzer stellt Zertifizierungsantrag (CSR: Certificate Signing Request) per Web (GWDG-CA) - erhält Bestätigungs-E-Mail ===
=== Benutzer druckt Formular mit digitalem Fingerabdruck (Fingerprint) aus, unterschreibt, persönliche Identifizierung ===
=== Operating oder GWDG-CA prüft Unterschrift, Lichtbild-Ausweis ===
=== Fingerprint des Formulars wird mit eingegangenem Antrag verglichen ===
=== Zertifizierungsantrag (Berechtigung?) und Schlüssel wird geprüft ===
=== Zertifikat wird ausgestellt (Benutzer erhält Verweis auf Zertifikat per E-Mail) ===
=== Ablauf der Zertifizierung (zukünftig zusätzlich) ===
=== Benutzer erhält PKCS12-File (privater Schlüssel und Zertifikat) auf Datenträger zum regulären Benutzeraccount (persönliche Identifizierung!) ===
=== Schlüsselpaar wird durch GWDG erzeugt, nach Aushändigung vernichtet ===
=== Smart Card / Token Integration bzw. Erzeugung am Benutzer-Terminal ===
== Auslagerung und Verwaltung ==
=== Zertifizierungsstelle (Sub-CA) mit externer RA: ===
* Registrierungsstelle (z.&nbsp;B.&nbsp; extern im Institut) prüft Identität
* Signiert CSR mit RA-Schlüssel, sendet ihn zur CA
* CA stellt Zertifikat aus
=== Veröffentlichung ===
* Sofern Veröffentlichung nicht verweigert, Speicherung in Datenbank und LDAP-Verzeichnis (OpenLDAP, Active Directory)
* Windows-CA automatische Veröffentlichung in Active Directory (GAL für Mail-Kryptografie), Verteilung der CA-Zertifikate über Active Directory
* Web-Zugriff auf Zertifikat-Datenbank
=== Sperrung von Zertifikaten ===
* Benutzer meldet CA oder RA den Schlüsselverlust o.ä.
* CRR (Certificate Revocation Request) wird bearbeitet
* Sperrliste veröffentlicht, bzw. OCSP Datenbank aktualisiert
== Anwendungen für Zertifikate ==
=== Anwendungen ===
=== E-Mail (Signatur,<span style="color:#008000;">KMail</span>, <span style="color:#008000;">Mail.app</span>, <span style="color:#008000;">Entourage</span>, <span style="color:#008000;">Mozilla</span>, <span style="color:#008000;">Netscape</span>, <span style="color:#000000;">mutt</span>, Kryptografie) <span style="color:#008000;">Outlook</span>, <span style="color:#000000;">pine</span>, <span style="color:#ff3300;">PC-Pine</span>, <span style="color:#008000;">Thunderbird</span>, (<span style="color:#008000;">ListProc</span>) … ===
=== Authentifizierung Server<span style="color:#008000;">Apache</span>, <span style="color:#008000;">IIS</span>, <span style="color:#008000;">Notes</span>, <span style="color:#008000;">LDAP</span>, <span style="color:#008000;">RADIUS</span>, … ===
=== Authentifizierung Client <span style="color:#008000;">802.1X (EAP)</span>, <span style="color:#008000;">Web</span>, <span style="color:#008000;">LDAP</span>,<span style="color:#008000;"> IPsec</span>, … ===
=== Verschl. u. Sig. Daten<span style="color:#000000;">Dateiverschlüsselung EFS</span>, <span style="color:#008000;">PDF-Dokumente</span>, <span style="color:#008000;">Word </span><span style="color:#008000;">bzw. MS Office-Dokumente</span>, … ===
=== Sub-CA<span style="color:#006600;">OpenCA</span>, <span style="color:#006600;">openssl</span>, <span style="color:#006600;">Windows-CA</span> ===
=== SCEP<span style="color:#000000;">Cisco im Test</span> ===
=== Smart Card / Token ===
=== Verwendung in Applikation<span style="color:#008000;">Firefox</span><span style="color:#000000;">, </span><span style="color:#008000;">Mozilla</span><span style="color:#000000;">, </span><span style="color:#008000;">Netscape</span><span style="color:#000000;">, </span><span style="color:#008000;">Windows</span><span style="color:#000000;">, </span><span style="color:#008000;">openssl</span> ===
=== Login<span style="color:#006600;">Windows (Aladdin, Microsoft)</span>,<span style="color:#000000;"> PAM / Linux</span> ===
=== Betriebssysteme ===
=== Unix / Linux<span style="color:#008000;">openssl</span>, <span style="color:#008000;">Firefox</span>, <span style="color:#008000;">Mozilla</span>, <span style="color:#008000;">KDE</span>,<span style="color:#000000;"> GNOME</span> ===
=== Mac OSX<span style="color:#008000;">Schlüsselbund</span>, <span style="color:#008000;">Safari</span>, <span style="color:#008000;">Firefox</span>,<span style="color:#008000;"> Camino</span> ===
=== Windows <span style="color:#008000;">„Windows“</span>, <span style="color:#008000;">Firefox</span>, <span style="color:#008000;">Mozilla</span>, <span style="color:#008000;">Netscape</span> ===
== Sicherheitstechnologie ==
* Sicherheit in VPN
* Sicherheit in Unternehmensdatennetzen
* Sicherheitsverfahren in VPN
* Sicherheit in der Netzwerkschicht mit IP-Security
* Sicherheit auf der Transportschicht mit Transport Layer Security (TLS) und Secure Socket Layer (SSL)
* Die Grundlagen der Kryptografie
* Geschichtliches
* Datenvertraulichkeit
* Verschleierung und Kryptografie
* Die Kunst der Kryptoanalyse
* Einführung in die Kryprografie
* Kryptografieverfahren
* Symmetrische Kryptografieverfahren
* Der Data Encryption Standard (DES)
* Ein Überblick über DES
* Die DES-Schlüsseltransformation
* Die DES-Funktion
* Die DES-Entschlüsselung
* Die Kryptoanalyse von DES
* Triple-DES
* Die Kryptoanalyse von Triple-DES
* Cipher Block Chaining (CBC)
* Die Funktionsweise von CBC
* Advanced Encryption Standard (AES)
== Kryptografie ==
* Motivation
* Entwicklung
* Grundlagen
* Message Authentication Code
* Tunneling
* Wie baut man eine sicheren Block Cipher?
* Angriffe auf Kryptografieen
* Kryptologische Verfahren
* Geschwindigkeit
* Public Key Infrastrukturen nach X.509
<noinclude>
== Anhang ==
=== Siehe auch ===
{{Special:PrefixIndex/Public Key Infrastructure}}
----
{{Special:PrefixIndex/PKI}}
==== Links ====
===== Projekt =====
===== Weblinks =====
# https://bettercrypto.org/
[[Kategorie:X.509]]
= TMP =
= Public Key Infrastrukturen - X.509 =
== Public Key Infrastrukturen nach X.509 ==
* Grundlagen für Public-Key-Verfahren
* Digitale Signaturen und Zertifikate
* Funktion und Aufgabe einer Infrastruktur für Public-Keys
* Aufbau einer PKI
* Ablauf der Zertifizierung
* Anwendungen für Zertifikate
== Grundlagen für Public-Key-VerfahrenMehr Sicherheit durch PKI… ==
== Kryptografie nach Caesar… ==
== privat… oder öffentlich? ==
== Performante Sicherheit! ==
== Schutz vor Veränderungen! ==
== Wer ist Alice? ==
== Zertifikate an der Kette! ==
= TMP =
= Public Key Infrastruktur =
== Funktionen einer PKI ==
== Bob vertraut Alice! ==
== Kryptografie per Zertifikat ==
= tmp =
= Aufbau einer PKICA Hierarchie =
=== Struktur einer PKI ===
=== Integration in die Zertifizierungshierarchie ===
=== Bestandteil des Gesamtkonzepts für einheitliche Authentifizierung und Identity Management ===
=== 3-stufige Hierarchie ===
=== Ebene 1 ohne Netzwerkanschluss, verschlüsselte Datenhaltung ===
=== Zugriff auf Ebene 1 CA nur über tresorgelagerten Datenträger, Ebene 2 über Token ===
=== Zugriff geregelt durch Policy, Rechner in Sicherheitsbereich ===
=== Ebene 2 für die Integration weiterer Institutionen ===
== X.509v3 Zertifikate  ==
* Bindet Identität an öffentlichen Schlüssel
* X.500 DN, DNS Name, Email-Adresse, URI, IP-Adresse
* Gibt verwendete Signaturalgorithmen an
* Zusatzfelder erlauben es weitere Information zu bestätigen
* Z.B. Zugriffsrechte
== Zertifikate in Web-Browsern ==
== Organisation und Technik ==
== Aufwand: Identifizierung! ==
=== Ablauf der Zertifizierung (bei GWDG-CA und Sub-CAs) ===
=== Benutzer stellt Zertifizierungsantrag (CSR: Certificate Signing Request) per Web (GWDG-CA) - erhält Bestätigungs-E-Mail ===
=== Benutzer druckt Formular mit digitalem Fingerabdruck (Fingerprint) aus, unterschreibt, persönliche Identifizierung ===
=== Operating oder GWDG-CA prüft Unterschrift, Lichtbild-Ausweis ===
=== Fingerprint des Formulars wird mit eingegangenem Antrag verglichen ===
=== Zertifizierungsantrag (Berechtigung?) und Schlüssel wird geprüft ===
=== Zertifikat wird ausgestellt (Benutzer erhält Verweis auf Zertifikat per E-Mail) ===
=== Ablauf der Zertifizierung (zukünftig zusätzlich) ===
=== Benutzer erhält PKCS12-File (privater Schlüssel und Zertifikat) auf Datenträger zum regulären Benutzeraccount (persönliche Identifizierung!) ===
=== Schlüsselpaar wird durch GWDG erzeugt, nach Aushändigung vernichtet ===
=== Smart Card / Token Integration bzw.&nbsp;Erzeugung am Benutzer-Terminal ===
== Auslagerung und Verwaltung ==
=== Zertifizierungsstelle (Sub-CA) mit externer RA: ===
* Registrierungsstelle (z.&nbsp;B.&nbsp;extern im Institut) prüft Identität
* Signiert CSR mit RA-Schlüssel, sendet ihn zur CA
* CA stellt Zertifikat aus
=== Veröffentlichung ===
* Sofern Veröffentlichung nicht verweigert, Speicherung in Datenbank und LDAP-Verzeichnis (OpenLDAP, Active Directory)
* Windows-CA automatische Veröffentlichung in Active Directory (GAL für Mail-Kryptografie), Verteilung der CA-Zertifikate über Active Directory
* Web-Zugriff auf Zertifikat-Datenbank
=== Sperrung von Zertifikaten ===
* Benutzer meldet CA oder RA den Schlüsselverlust o.ä.
* CRR (Certificate Revocation Request) wird bearbeitet
* Sperrliste veröffentlicht, bzw.&nbsp;OCSP Datenbank aktualisiert
== Anwendungen für Zertifikate ==
=== Anwendungen ===
=== E-Mail (Signatur,<span style="color:#008000;">KMail</span>, <span style="color:#008000;">Mail.app</span>, <span style="color:#008000;">Entourage</span>, <span style="color:#008000;">Mozilla</span>, <span style="color:#008000;">Netscape</span>, <span style="color:#000000;">mutt</span>, Kryptografie) <span style="color:#008000;">Outlook</span>, <span style="color:#000000;">pine</span>, <span style="color:#ff3300;">PC-Pine</span>, <span style="color:#008000;">Thunderbird</span>, (<span style="color:#008000;">ListProc</span>) … ===
=== Authentifizierung Server<span style="color:#008000;">Apache</span>, <span style="color:#008000;">IIS</span>, <span style="color:#008000;">Notes</span>, <span style="color:#008000;">LDAP</span>, <span style="color:#008000;">RADIUS</span>, … ===
=== Authentifizierung Client <span style="color:#008000;">802.1X (EAP)</span>, <span style="color:#008000;">Web</span>, <span style="color:#008000;">LDAP</span>,<span style="color:#008000;"> IPsec</span>, … ===
=== Verschl. u. Sig. Daten<span style="color:#000000;">Dateiverschlüsselung EFS</span>, <span style="color:#008000;">PDF-Dokumente</span>, <span style="color:#008000;">Word </span><span style="color:#008000;">bzw.&nbsp;MS Office-Dokumente</span>, … ===
=== Sub-CA<span style="color:#006600;">OpenCA</span>, <span style="color:#006600;">openssl</span>, <span style="color:#006600;">Windows-CA</span> ===
=== SCEP<span style="color:#000000;">Cisco im Test</span> ===
=== Smart Card / Token ===
=== Verwendung in Applikation<span style="color:#008000;">Firefox</span><span style="color:#000000;">, </span><span style="color:#008000;">Mozilla</span><span style="color:#000000;">, </span><span style="color:#008000;">Netscape</span><span style="color:#000000;">, </span><span style="color:#008000;">Windows</span><span style="color:#000000;">, </span><span style="color:#008000;">openssl</span> ===
=== Login<span style="color:#006600;">Windows (Aladdin, Microsoft)</span>,<span style="color:#000000;"> PAM / Linux</span> ===
=== Betriebssysteme ===
=== Unix / Linux<span style="color:#008000;">openssl</span>, <span style="color:#008000;">Firefox</span>, <span style="color:#008000;">Mozilla</span>, <span style="color:#008000;">KDE</span>,<span style="color:#000000;"> GNOME</span> ===
=== Mac OSX<span style="color:#008000;">Schlüsselbund</span>, <span style="color:#008000;">Safari</span>, <span style="color:#008000;">Firefox</span>,<span style="color:#008000;"> Camino</span> ===
=== Windows <span style="color:#008000;">„Windows“</span>, <span style="color:#008000;">Firefox</span>, <span style="color:#008000;">Mozilla</span>, <span style="color:#008000;">Netscape</span> ===
== Sicherheitstechnologie ==
* Sicherheit in VPN
* Sicherheit in Unternehmensdatennetzen
* Sicherheitsverfahren in VPN
* Sicherheit in der Netzwerkschicht mit IP-Security
* Sicherheit auf der Transportschicht mit Transport Layer Security (TLS) und Secure Socket Layer (SSL)
* Die Grundlagen der Kryptografie
* Geschichtliches
* Datenvertraulichkeit
* Verschleierung und Kryptografie
* Die Kunst der Kryptoanalyse
* Einführung in die Kryprografie
* Kryptografieverfahren
* Symmetrische Kryptografieverfahren
* Der Data Encryption Standard (DES)
* Ein Überblick über DES
* Die DES-Schlüsseltransformation
* Die DES-Funktion
* Die DES-Entschlüsselung
* Die Kryptoanalyse von DES
* Triple-DES
* Die Kryptoanalyse von Triple-DES
* Cipher Block Chaining (CBC)
* Die Funktionsweise von CBC
* Advanced Encryption Standard (AES)
= TMP =
= Public Key Infrastrukturen =
nach X.509
== Public Key Infrastrukturen nach X.509 ==
* Grundlagen für Public-Key-Verfahren
* Digitale Signaturen und Zertifikate
* Funktion und Aufgabe einer Infrastruktur für Public-Keys
* Aufbau einer PKI
* Ablauf der Zertifizierung
* Anwendungen für Zertifikate
== Grundlagen für Public-Key-VerfahrenMehr Sicherheit durch PKI… ==
== Kryptografie nach Caesar… ==
== privat… oder öffentlich? ==
== Performante Sicherheit! ==
== Schutz vor Veränderungen! ==
== Wer ist Alice? ==
== Zertifikate an der Kette! ==
== Public Key Infrastruktur ==
== Funktionen einer PKI ==
== Bob vertraut Alice! ==
== Kryptografie per Zertifikat ==
</noinclude>

Aktuelle Version vom 27. Juli 2024, 10:37 Uhr

Public-Key-Infrastrukturen

Public-Key-Infrastrukturen versuchen das Problem zu lösen, zu überprüfen, ob ein öffentlicher Schlüssel zu einer bestimmten Einheit gehört, um Man-in-the-Middle-Angriffe zu verhindern.

Ansätze
  1. Certificate Authorities
  2. Web of Trust
Zertifizierungsstellen (CA)
  • signieren die Zertifikate von Endteilnehmern und verknüpfen so eine Art von Identität (z. B.  einen Domänennamen oder eine E-Mail-Adresse) mit einem öffentlichen Schlüssel.
  • CAs werden mit TLS- und S/MIME-Zertifikaten verwendet, und das CA-System hat eine lange Liste möglicher und tatsächlicher Probleme, die im Abschnitt Hardening PKI und (Durumeric, Kasten, Bailey, & Halderman, 2013) zusammengefasst sind.
Web of Trust

Das Web of Trust ist ein dezentralisiertes System, bei dem Menschen gegenseitig ihre Schlüssel signieren, so dass die Wahrscheinlichkeit hoch ist, dass es einen "Vertrauenspfad" von einem Schlüssel zum anderen gibt.

  • Es wird mit PGP-Schlüsseln verwendet, und obwohl es die meisten Probleme des CA-Systems vermeidet, ist es umständlicher.
Alternativen

Als Alternativen zu diesen öffentlichen Systemen gibt es zwei weitere Möglichkeiten

  • Die Verwendung einer privaten Zertifizierungsstelle und das manuelle Vertrauen in Schlüssel (wie es bei SSH-Schlüsseln oder manuell vertrauenswürdigen Schlüsseln in Webbrowsern verwendet wird).
    • Der erste Teil dieses Abschnitts befasst sich damit, wie man ein Zertifikat im CA-System erhält.
  • Der zweite Teil enthält Empfehlungen, wie Sie die Sicherheit Ihrer PKI verbessern können.

Zertifizierungsstellen

Um ein Zertifikat zu erhalten, können Sie eine externe Zertifizierungsstelle finden, die bereit ist, ein Zertifikat für Sie auszustellen, Ihre eigene Zertifizierungsstelle betreiben oder selbst signierte Zertifikate verwenden.

  • Wie immer gibt es Vor- und Nachteile für jede dieser Optionen; es muss ein Gleichgewicht zwischen Sicherheit und Benutzerfreundlichkeit gefunden werden.

Zertifikate von einer externen Zertifizierungsstelle

Es gibt eine ziemlich große Anzahl kommerzieller Zertifizierungsstellen, die gegen Geld Zertifikate ausstellen.
  • Einige der bekanntesten kommerziellen CAs sind Verisign, GoDaddy und Teletrust.
  • Es gibt jedoch auch CAs, die kostenlose Zertifikate anbieten.
  • Die bekanntesten Beispiele sind StartSSL, ein Unternehmen, das einige Arten von Zertifikaten kostenlos anbietet, und CAcert, eine gemeinnützige, ehrenamtlich tätige Organisation, die für die Ausstellung von Zertifikaten keinerlei Gebühren erhebt.
  • Im Forschungs- und Bildungsbereich schließlich gibt es eine Reihe von Zertifizierungsstellen, die in der Regel in der Hochschulgemeinschaft bekannt und akzeptiert sind.
Eine große Anzahl von Zertifizierungsstellen ist in den Vertrauensspeichern von Client-Software oder Betriebssystemen vorinstalliert
  • je nach Anwendung müssen Sie Ihre Zertifizierungsstelle entsprechend auswählen oder über einen Mechanismus verfügen, um das Stammzertifikat der gewählten Zertifizierungsstelle an die Clients zu verteilen.
Wenn Sie ein Zertifikat bei einer CA beantragen, müssen Sie das Schlüsselpaar unbedingt selbst erzeugen.
  • Vor allem der private Schlüssel sollte der CA niemals bekannt sein.
  • Wenn eine Zertifizierungsstelle anbietet, das Schlüsselpaar für Sie zu erzeugen, sollten Sie dieser Zertifizierungsstelle nicht vertrauen.
Die Erzeugung eines Schlüsselpaares und einer Zertifikatsanforderung kann mit einer Reihe von Werkzeugen durchgeführt werden.
  • Auf Unix-ähnlichen Systemen ist es wahrscheinlich, dass Ihnen die OpenSSL-Suite zur Verfügung steht.
In diesem Fall können Sie einen privaten Schlüssel und eine entsprechende Zertifikatsanforderung wie folgt erzeugen
$ openssl req -new -nodes -keyout <servername>.key -out <servername>.csr -newkey rsa:<keysize> -sha256
Country Name (2 letter code) [AU]:DE
State or Province Name (full name) [Some-State]:Bavaria
Locality Name (eg, city) []:Munich
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Example
Organizational Unit Name (eg, section) []:Example Section
Common Name (e.g. server FQDN or YOUR name) []:example.com
Email Address []:admin@example.com
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Einrichten einer eigenen Zertifizierungsstelle

In manchen Situationen ist es ratsam, eine eigene Zertifizierungsstelle zu betreiben.

  • Ob dies eine gute Idee ist, hängt von den genauen Umständen ab.
  • Im Allgemeinen gilt: Je zentralisierter die Kontrolle der Systeme in Ihrer Umgebung ist, desto weniger Aufwand müssen Sie für die Einrichtung Ihrer eigenen Zertifizierungsstelle betreiben.
  • Andererseits maximiert der Betrieb einer eigenen Zertifizierungsstelle das Vertrauensniveau, das Sie erreichen können, da externe Abhängigkeiten minimiert werden.

Wiederum unter Verwendung von OpenSSL als Beispiel, können Sie Ihre eigene CA mit den folgenden Befehlen auf einem Debian-System einrichten: 

$ cd /usr/lib/ssl/misc
$ sudo ./CA.pl -newca
Answer the questions according to your setup.
  • Now that you have configured your basic settings and issued a new root certificate, you can issue new certificates as follows:
$ cd /usr/lib/ssl/misc
$ sudo ./CA.pl -newreq

Alternativ gibt es Software wie TinyCA, die als "Wrapper" um OpenSSL herum agiert und versucht, das Leben einfacher zu machen.

Erstellen eines selbstsignierten Zertifikats

Wenn das gewünschte Vertrauensniveau sehr hoch und die Anzahl der beteiligten Systeme begrenzt ist, kann der einfachste Weg, eine sichere Umgebung einzurichten, die Verwendung selbst signierter Zertifikate sein.

  • Ein selbstsigniertes Zertifikat wird nicht von einer Zertifizierungsstelle ausgestellt, sondern von der Einrichtung, für die es ausgestellt wurde, signiert.
  • Auf diese Weise entfällt der organisatorische Aufwand, der mit dem Betrieb einer Zertifizierungsstelle verbunden ist, auf Kosten der Notwendigkeit, alle Vertrauensbeziehungen zwischen Entitäten manuell herzustellen.
Mit OpenSSL können Sie ein zuvor erstelltes Zertifikat mit diesem Befehl selbst signieren
$ openssl req -new -x509 -key privkey.pem -out cacert.pem -days 1095
Sie können auch ein selbstsigniertes Zertifikat mit nur einem Befehl erstellen
$ openssl req -new -x509 -keyout privkey.pem -out cacert.pem -days 1095 -nodes -newkey rsa:<keysize> -sha256

Das daraus resultierende Zertifikat wird standardmäßig von niemandem als vertrauenswürdig eingestuft. Um also nützlich zu sein, muss das Zertifikat allen Parteien, die damit in Berührung kommen könnten, a priori bekannt gemacht werden.

Härtung der PKI

In den letzten Jahren wurden mehrere Zertifizierungsstellen von Angreifern kompromittiert, um an vertrauenswürdige Zertifikate für böswillige Aktivitäten heranzukommen.

  • Im Jahr 2011 wurde die niederländische Zertifizierungsstelle Diginotar gehackt und alle Zertifikate wurden widerrufen (Elinor Mills, 2011).
  • Kürzlich fand Google auf sie ausgestellte Zertifikate, die von dem Unternehmen nicht verwendet wurden (Damon Poeter, 2011).
  • Das Konzept der PKI hängt stark von der Sicherheit der Zertifizierungsstellen ab.
  • Wenn diese kompromittiert werden, fällt das gesamte PKI-System aus.
  • Einige Zertifizierungsstellen neigen dazu, fälschlicherweise Zertifikate auszustellen, die für eine andere Aufgabe als die von der Zertifizierungsstelle vorgesehene bestimmt sind (Adam Langley, et. al., 2013).

Daher wurden verschiedene Sicherheitsverbesserungen von verschiedenen Organisationen und Anbietern eingeführt (H. Tschofenig und E. Lear, 2013).

  • Derzeit werden zwei Methoden verwendet, DANE (Hoffman & Schlyter, 2012) und Certificate Pinning (C. Evans und C. Palmer, 2013).
  • Google hat kürzlich ein neues System zur Erkennung bösartiger CAs und Zertifikate namens Certificate Transparency (Adam Langley, Ben Laurie, Emilia Kasper, 2013) vorgeschlagen.
  • Darüber hinaus beschreibt RFC 6844 Certification Authorization Records, einen Mechanismus, mit dem Inhaber von Domänennamen angeben können, welche Zertifizierungsstellen berechtigt sind, Zertifikate für ihre Domäne auszustellen.

Certification Authorization Records

RFC 6844 beschreibt Certification Authorization Records, einen Mechanismus, mit dem Inhaber von Domänennamen angeben können, welche Zertifizierungsstellen berechtigt sind, Zertifikate für ihre Domäne auszustellen. Wenn ein CAA-Datensatz für eine bestimmte Domäne definiert ist, gibt er an, dass der Domäneninhaber die Zertifizierungsstellen auffordert, jede Anfrage anhand des CAA-Datensatzes zu validieren.

  • Wenn der Zertifikatsaussteller nicht im CAA-Eintrag aufgeführt ist, sollte er das Zertifikat nicht ausstellen.

Der RFC erlaubt auch Zertifikatsauswertern, ein ausgestelltes Zertifikat anhand des CAA-Datensatzes zu prüfen, wobei jedoch Vorsicht geboten ist, da sich der CAA-Datensatz während der Lebensdauer eines Zertifikats ändern kann, ohne dessen Gültigkeit zu beeinträchtigen. CAA unterstützt auch einen iodef-Eigenschaftstyp, der von einer Zertifizierungsstelle angefordert werden kann, um Anträge auf Ausstellung von Zertifikaten zu melden, die nicht mit der Zertifikatsrichtlinie des Ausstellers übereinstimmen.

Konfiguration der CAA-Datensätze

BIND unterstützt CAA-Records ab Version 9.9.6.

Ein CAA-Eintrag kann konfiguriert werden, indem er zur Zonendatei hinzugefügt wird
$ORIGIN example.com
      CAA 0 issue "ca1.example"
      CAA 0 iodef "mailto:security@example.com"
Wenn Ihr Unternehmen mehrere CAs verwendet, können Sie mehrere Datensätze konfigurieren
     CAA 0 issue "ca1.example"
     CAA 0 issue "ca2.example"
  • "ca1.example" und "ca2.example" sind eindeutige Bezeichner für die CA, die Sie verwenden möchten.
  • Diese Zeichenfolgen können von Ihrer Zertifizierungsstelle bezogen werden und sind in der Regel die Top-Level-Domain.
  • Ein Beispiel ist "letsencrypt.org" für die von der Internet Security Research Group betriebene Let's Encrypt CA.Knot-DNS unterstützt CAA-Einträge ab Version 2.2.0.

Validation of CAA records

Sobald ein CAA-Datensatz bereitgestellt wurde, kann er mit der folgenden Abfrage validiert werden
$ dig CAA google.com
; <<>> DiG 9.10.3-P4-Debian <<>> CAA google.com
;; ANSWER SECTION:
google.com.          3600 IN   CAA  0 issue "symantec.com"
Bei älteren Versionen von Dig, die keine CAA-Datensätze unterstützen, können Sie die Datensatzart manuell abfragen
$ dig +short -t TYPE257 google.com
\# 19 0005697373756573796D616E7465632E636F6D

Aufbau einer PKICA Hierarchie

Struktur einer PKI

Integration in die Zertifizierungshierarchie

Bestandteil des Gesamtkonzepts für einheitliche Authentifizierung und Identity Management

3-stufige Hierarchie

Ebene 1 ohne Netzwerkanschluss, verschlüsselte Datenhaltung

Zugriff auf Ebene 1 CA nur über tresorgelagerten Datenträger, Ebene 2 über Token

Zugriff geregelt durch Policy, Rechner in Sicherheitsbereich

Ebene 2 für die Integration weiterer Institutionen

X.509v3 Zertifikate

  • Bindet Identität an öffentlichen Schlüssel
  • X.500 DN, DNS Name, Email-Adresse, URI, IP-Adresse
  • Gibt verwendete Signaturalgorithmen an
  • Zusatzfelder erlauben es weitere Information zu bestätigen
  • Z.B. Zugriffsrechte

Zertifikate in Web-Browsern

Organisation und Technik

Aufwand: Identifizierung!

Ablauf der Zertifizierung (bei GWDG-CA und Sub-CAs)

Benutzer stellt Zertifizierungsantrag (CSR: Certificate Signing Request) per Web (GWDG-CA) - erhält Bestätigungs-E-Mail

Benutzer druckt Formular mit digitalem Fingerabdruck (Fingerprint) aus, unterschreibt, persönliche Identifizierung

Operating oder GWDG-CA prüft Unterschrift, Lichtbild-Ausweis

Fingerprint des Formulars wird mit eingegangenem Antrag verglichen

Zertifizierungsantrag (Berechtigung?) und Schlüssel wird geprüft

Zertifikat wird ausgestellt (Benutzer erhält Verweis auf Zertifikat per E-Mail)

Ablauf der Zertifizierung (zukünftig zusätzlich)

Benutzer erhält PKCS12-File (privater Schlüssel und Zertifikat) auf Datenträger zum regulären Benutzeraccount (persönliche Identifizierung!)

Schlüsselpaar wird durch GWDG erzeugt, nach Aushändigung vernichtet

Smart Card / Token Integration bzw. Erzeugung am Benutzer-Terminal

Auslagerung und Verwaltung

Zertifizierungsstelle (Sub-CA) mit externer RA:

  • Registrierungsstelle (z. B.  extern im Institut) prüft Identität
  • Signiert CSR mit RA-Schlüssel, sendet ihn zur CA
  • CA stellt Zertifikat aus

Veröffentlichung

  • Sofern Veröffentlichung nicht verweigert, Speicherung in Datenbank und LDAP-Verzeichnis (OpenLDAP, Active Directory)
  • Windows-CA automatische Veröffentlichung in Active Directory (GAL für Mail-Kryptografie), Verteilung der CA-Zertifikate über Active Directory
  • Web-Zugriff auf Zertifikat-Datenbank

Sperrung von Zertifikaten

  • Benutzer meldet CA oder RA den Schlüsselverlust o.ä.
  • CRR (Certificate Revocation Request) wird bearbeitet
  • Sperrliste veröffentlicht, bzw. OCSP Datenbank aktualisiert

Anwendungen für Zertifikate

Anwendungen

E-Mail (Signatur,KMail, Mail.app, Entourage, Mozilla, Netscape, mutt, Kryptografie) Outlook, pine, PC-Pine, Thunderbird, (ListProc) …

Authentifizierung ServerApache, IIS, Notes, LDAP, RADIUS, …

Authentifizierung Client 802.1X (EAP), Web, LDAP, IPsec, …

Verschl. u. Sig. DatenDateiverschlüsselung EFS, PDF-Dokumente, Word bzw. MS Office-Dokumente, …

Sub-CAOpenCA, openssl, Windows-CA

SCEPCisco im Test

Smart Card / Token

Verwendung in ApplikationFirefox, Mozilla, Netscape, Windows, openssl

LoginWindows (Aladdin, Microsoft), PAM / Linux

Betriebssysteme

Unix / Linuxopenssl, Firefox, Mozilla, KDE, GNOME

Mac OSXSchlüsselbund, Safari, Firefox, Camino

Windows „Windows“, Firefox, Mozilla, Netscape

Sicherheitstechnologie

  • Sicherheit in VPN
  • Sicherheit in Unternehmensdatennetzen
  • Sicherheitsverfahren in VPN
  • Sicherheit in der Netzwerkschicht mit IP-Security
  • Sicherheit auf der Transportschicht mit Transport Layer Security (TLS) und Secure Socket Layer (SSL)
  • Die Grundlagen der Kryptografie
  • Geschichtliches
  • Datenvertraulichkeit
  • Verschleierung und Kryptografie
  • Die Kunst der Kryptoanalyse
  • Einführung in die Kryprografie
  • Kryptografieverfahren
  • Symmetrische Kryptografieverfahren
  • Der Data Encryption Standard (DES)
  • Ein Überblick über DES
  • Die DES-Schlüsseltransformation
  • Die DES-Funktion
  • Die DES-Entschlüsselung
  • Die Kryptoanalyse von DES
  • Triple-DES
  • Die Kryptoanalyse von Triple-DES
  • Cipher Block Chaining (CBC)
  • Die Funktionsweise von CBC
  • Advanced Encryption Standard (AES)

Kryptografie

  • Motivation
  • Entwicklung
  • Grundlagen
  • Message Authentication Code
  • Tunneling
  • Wie baut man eine sicheren Block Cipher?
  • Angriffe auf Kryptografieen
  • Kryptologische Verfahren
  • Geschwindigkeit
  • Public Key Infrastrukturen nach X.509


Anhang

Siehe auch

Links

Projekt
Weblinks
  1. https://bettercrypto.org/

TMP

Public Key Infrastrukturen - X.509

Public Key Infrastrukturen nach X.509

  • Grundlagen für Public-Key-Verfahren
  • Digitale Signaturen und Zertifikate
  • Funktion und Aufgabe einer Infrastruktur für Public-Keys
  • Aufbau einer PKI
  • Ablauf der Zertifizierung
  • Anwendungen für Zertifikate

Grundlagen für Public-Key-VerfahrenMehr Sicherheit durch PKI…

Kryptografie nach Caesar…

privat… oder öffentlich?

Performante Sicherheit!

Schutz vor Veränderungen!

Wer ist Alice?

Zertifikate an der Kette!

TMP

Public Key Infrastruktur

Funktionen einer PKI

Bob vertraut Alice!

Kryptografie per Zertifikat

tmp

Aufbau einer PKICA Hierarchie

Struktur einer PKI

Integration in die Zertifizierungshierarchie

Bestandteil des Gesamtkonzepts für einheitliche Authentifizierung und Identity Management

3-stufige Hierarchie

Ebene 1 ohne Netzwerkanschluss, verschlüsselte Datenhaltung

Zugriff auf Ebene 1 CA nur über tresorgelagerten Datenträger, Ebene 2 über Token

Zugriff geregelt durch Policy, Rechner in Sicherheitsbereich

Ebene 2 für die Integration weiterer Institutionen

X.509v3 Zertifikate

  • Bindet Identität an öffentlichen Schlüssel
  • X.500 DN, DNS Name, Email-Adresse, URI, IP-Adresse
  • Gibt verwendete Signaturalgorithmen an
  • Zusatzfelder erlauben es weitere Information zu bestätigen
  • Z.B. Zugriffsrechte

Zertifikate in Web-Browsern

Organisation und Technik

Aufwand: Identifizierung!

Ablauf der Zertifizierung (bei GWDG-CA und Sub-CAs)

Benutzer stellt Zertifizierungsantrag (CSR: Certificate Signing Request) per Web (GWDG-CA) - erhält Bestätigungs-E-Mail

Benutzer druckt Formular mit digitalem Fingerabdruck (Fingerprint) aus, unterschreibt, persönliche Identifizierung

Operating oder GWDG-CA prüft Unterschrift, Lichtbild-Ausweis

Fingerprint des Formulars wird mit eingegangenem Antrag verglichen

Zertifizierungsantrag (Berechtigung?) und Schlüssel wird geprüft

Zertifikat wird ausgestellt (Benutzer erhält Verweis auf Zertifikat per E-Mail)

Ablauf der Zertifizierung (zukünftig zusätzlich)

Benutzer erhält PKCS12-File (privater Schlüssel und Zertifikat) auf Datenträger zum regulären Benutzeraccount (persönliche Identifizierung!)

Schlüsselpaar wird durch GWDG erzeugt, nach Aushändigung vernichtet

Smart Card / Token Integration bzw. Erzeugung am Benutzer-Terminal

Auslagerung und Verwaltung

Zertifizierungsstelle (Sub-CA) mit externer RA:

  • Registrierungsstelle (z. B. extern im Institut) prüft Identität
  • Signiert CSR mit RA-Schlüssel, sendet ihn zur CA
  • CA stellt Zertifikat aus

Veröffentlichung

  • Sofern Veröffentlichung nicht verweigert, Speicherung in Datenbank und LDAP-Verzeichnis (OpenLDAP, Active Directory)
  • Windows-CA automatische Veröffentlichung in Active Directory (GAL für Mail-Kryptografie), Verteilung der CA-Zertifikate über Active Directory
  • Web-Zugriff auf Zertifikat-Datenbank

Sperrung von Zertifikaten

  • Benutzer meldet CA oder RA den Schlüsselverlust o.ä.
  • CRR (Certificate Revocation Request) wird bearbeitet
  • Sperrliste veröffentlicht, bzw. OCSP Datenbank aktualisiert

Anwendungen für Zertifikate

Anwendungen

E-Mail (Signatur,KMail, Mail.app, Entourage, Mozilla, Netscape, mutt, Kryptografie) Outlook, pine, PC-Pine, Thunderbird, (ListProc) …

Authentifizierung ServerApache, IIS, Notes, LDAP, RADIUS, …

Authentifizierung Client 802.1X (EAP), Web, LDAP, IPsec, …

Verschl. u. Sig. DatenDateiverschlüsselung EFS, PDF-Dokumente, Word bzw. MS Office-Dokumente, …

Sub-CAOpenCA, openssl, Windows-CA

SCEPCisco im Test

Smart Card / Token

Verwendung in ApplikationFirefox, Mozilla, Netscape, Windows, openssl

LoginWindows (Aladdin, Microsoft), PAM / Linux

Betriebssysteme

Unix / Linuxopenssl, Firefox, Mozilla, KDE, GNOME

Mac OSXSchlüsselbund, Safari, Firefox, Camino

Windows „Windows“, Firefox, Mozilla, Netscape

Sicherheitstechnologie

  • Sicherheit in VPN
  • Sicherheit in Unternehmensdatennetzen
  • Sicherheitsverfahren in VPN
  • Sicherheit in der Netzwerkschicht mit IP-Security
  • Sicherheit auf der Transportschicht mit Transport Layer Security (TLS) und Secure Socket Layer (SSL)
  • Die Grundlagen der Kryptografie
  • Geschichtliches
  • Datenvertraulichkeit
  • Verschleierung und Kryptografie
  • Die Kunst der Kryptoanalyse
  • Einführung in die Kryprografie
  • Kryptografieverfahren
  • Symmetrische Kryptografieverfahren
  • Der Data Encryption Standard (DES)
  • Ein Überblick über DES
  • Die DES-Schlüsseltransformation
  • Die DES-Funktion
  • Die DES-Entschlüsselung
  • Die Kryptoanalyse von DES
  • Triple-DES
  • Die Kryptoanalyse von Triple-DES
  • Cipher Block Chaining (CBC)
  • Die Funktionsweise von CBC
  • Advanced Encryption Standard (AES)

TMP

Public Key Infrastrukturen

nach X.509

Public Key Infrastrukturen nach X.509

  • Grundlagen für Public-Key-Verfahren
  • Digitale Signaturen und Zertifikate
  • Funktion und Aufgabe einer Infrastruktur für Public-Keys
  • Aufbau einer PKI
  • Ablauf der Zertifizierung
  • Anwendungen für Zertifikate

Grundlagen für Public-Key-VerfahrenMehr Sicherheit durch PKI…

Kryptografie nach Caesar…

privat… oder öffentlich?

Performante Sicherheit!

Schutz vor Veränderungen!

Wer ist Alice?

Zertifikate an der Kette!

Public Key Infrastruktur

Funktionen einer PKI

Bob vertraut Alice!

Kryptografie per Zertifikat

Abgerufen von „https://wiki.foxtom.de/index.php?title=Public_Key_Infrastructure&oldid=103989“