Public Key Infrastructure: Unterschied zwischen den Versionen

Aus Foxwiki
Versionsgeschichte interaktiv durchsuchen
← Zum vorherigen VersionsunterschiedZum nächsten Versionsunterschied →
VisuellWikitext
Zeile 20: Zeile 20:
* Der zweite Teil enthält Empfehlungen, wie Sie die Sicherheit Ihrer PKI verbessern können.
* Der zweite Teil enthält Empfehlungen, wie Sie die Sicherheit Ihrer PKI verbessern können.


=== Certificate Authorities ===
=== Zertifizierungsstellen ===
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.  
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.  
* As always, there are advantages and disadvantages for every one of these options; a balance of security versus usability needs to be found.
* Wie immer gibt es Vor- und Nachteile für jede dieser Optionen; es muss ein Gleichgewicht zwischen Sicherheit und Benutzerfreundlichkeit gefunden werden.


==== Certificates From an External Certificate Authority ====
==== Zertifikate von einer externen Zertifizierungsstelle ====
There is a fairly large number of commercial CAs that will issue certificates for money.  
Es gibt eine ziemlich große Anzahl kommerzieller Zertifizierungsstellen, die gegen Geld Zertifikate ausstellen.  
* Some of the most ubiquitous commercial CAs are Verisign, GoDaddy, and Teletrust.  
* Einige der bekanntesten kommerziellen CAs sind Verisign, GoDaddy und Teletrust.  
* However, there are also CAs that offer certificates for free.  
* Es gibt jedoch auch CAs, die kostenlose Zertifikate anbieten.  
* 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.  
* 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.  
* 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.
* Im Forschungs- und Bildungsbereich schließlich gibt es eine Reihe von Zertifizierungsstellen, die in der Regel in der Hochschulgemeinschaft bekannt und akzeptiert sind.
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.
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.
When requesting a certificate from a CA, it is vital that you generate the key pair yourself.  
Wenn Sie ein Zertifikat bei einer CA beantragen, müssen Sie das Schlüsselpaar unbedingt selbst erzeugen.  
* In particular, the private key should never be known to the CA.  
* Vor allem der private Schlüssel sollte der CA niemals bekannt sein.  
* If a CA offers to generate the key pair for you, you should not trust that CA.
* Wenn eine Zertifizierungsstelle anbietet, das Schlüsselpaar für Sie zu erzeugen, sollten Sie dieser Zertifizierungsstelle nicht vertrauen.
Generating a key pair and a certificate request can be done with a number of tools.  
Die Erzeugung eines Schlüsselpaares und einer Zertifikatsanforderung kann mit einer Reihe von Werkzeugen durchgeführt werden.  
* On Unix-like systems, it is likely that the OpenSSL suite is available to you.  
* Auf Unix-ähnlichen Systemen ist es wahrscheinlich, dass Ihnen die OpenSSL-Suite zur Verfügung steht.  


In this case, you can generate a private key and a corresponding certificate request as follows:
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 52: Zeile 52:


==== Setting Up Your Own Certificate Authority ====
==== Setting Up Your Own Certificate Authority ====
In some situations it is advisable to run your own certificate authority.  
In manchen Situationen ist es ratsam, eine eigene Zertifizierungsstelle zu betreiben.  
* Whether this is a good idea depends on the exact circumstances.  
* Ob dies eine gute Idee ist, hängt von den genauen Umständen ab.  
* 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.  
* 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.  
* On the other hand, running your own CA maximizes the trust level that you can achieve because it minimizes external trust dependencies.
* 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
Zeile 65: Zeile 65:
  $ 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.
Alternativ gibt es Software wie TinyCA, die als "Wrapper" um OpenSSL herum agiert und versucht, das Leben einfacher zu machen.


==== Creating a Self-Signed Certificate ====
==== Creating a Self-Signed Certificate ====
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.  
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.  
* A self-signed certificate is not issued by any CA at all, but is signed by the entity that it is issued to.  
* Ein selbstsigniertes Zertifikat wird nicht von einer Zertifizierungsstelle ausgestellt, sondern von der Einrichtung, für die es ausgestellt wurde, signiert.  
* Thus, the organizational overhead of running a CA is eliminated at the expense of having to establish all trust relationships between entities manually.
* 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.


With OpenSSL, you can self-sign a previously created certificate with this command:
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
  $ openssl req -new -x509 -key privkey.pem -out cacert.pem -days 1095


You can also create a self-signed certificate in just one command:
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
  $ openssl req -new -x509 -keyout privkey.pem -out cacert.pem -days 1095 -nodes -newkey rsa:<keysize> -sha256
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.
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.


=== Hardening PKI ===
=== Hardening PKI ===

Version vom 18. Januar 2023, 11:01 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 []:

Setting Up Your Own Certificate Authority

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.

Creating a Self-Signed Certificate

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.

Hardening PKI

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 (Elinor Mills, 2011).
  • Recently Google found certificates issued to them, which were not used by the company (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 (Adam Langley, et. al., 2013).

Therefore several security enhancements were introduced by different organizations and vendors (H. Tschofenig and E. Lear, 2013).

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. 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.

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. 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.

Configuration of CAA records

BIND supports CAA records as of version 9.9.6. A CAA record can be configured by adding it to the zone file: $ORIGIN example.com 

      CAA 0 issue "ca1.example"
      CAA 0 iodef "mailto:security@example.com"

If your organization uses multiple CA’s, you can configure multiple records: 

     CAA 0 issue "ca1.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.

Knot-DNS supports CAA records as of version 2.2.0.

Validation of CAA records

Once a CAA record is deployed, it can be validated using the following dig query: 

$ dig CAA google.com
; <<>> DiG 9.10.3-P4-Debian <<>> CAA google.com
;; ANSWER SECTION:
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: 

$ dig +short -t TYPE257 google.com
\# 19 0005697373756573796D616E7465632E636F6D

Weblinks

  1. https://bettercrypto.org/
Abgerufen von „https://wiki.foxtom.de/index.php?title=Public_Key_Infrastructure&oldid=51516“