Teil I Aufbau und Betrieb einer Zertifizierungsinstanz - DFN-CERT

48 Kapitel 4. Konzept für eine Zertifizierungsstelle (“plan”)
Die DFN-PCA unterstützt bislang ebenfalls ausschließlich RSA-Schlüssel, insofern gibt es, zumindest
hinsichtlich der CA-Schlüssel, keine große Wahlmöglichkeit, sofern eine DFN-Zertifizierung
angestrebt wird. (Allerdings könnte eine nachgeordnete CA sich einen RSA-Schlüssel DFNzertifizieren
lassen, mit diesem dann aber auch DSS/DH-Keys zertifizieren, indem sie eine der
neueren PGP-Versionen einsetzt.)
4.8.2 Separate Signier- und Entschlüsselungsschlüssel
Die Medium-Level DFN-Policy schreibt für Zertifizierungsstellen eine Funktionstrennung bei ihren
Schlüsseln vor: Für Zertifizierungsaufgaben und für die vertrauliche Kommunikation mit der
jeweiligen Stelle müssen unterschiedliche Schlüssel verwendet werden.
Durch diese Trennung wird zum einen das kryptographische Material verringert, das einem Angreifer
für die Kryptanalyse zur Verfügung steht (jeder der beiden Schlüssel wird weniger oft benutzt,
als wenn nur ein Schlüssel für alle Anwendungszwecke verwendet würde), zum anderen werden die
Folgen einer Schlüssel-Kompromittierung begrenzt – es kann dann im Falle eines Falles eben nur
entweder die verschlüsselte Kommunikation vom Angreifer gelesen, oder Unterschriften der CA
gefälscht werden, aber nicht beides, wenn nur ein Schlüssel kompromittiert wurde [For94].
Eine weitere vorbeugende Schadensbegrenzung ist möglich, indem die Schlüssel regelmäßig gewechselt
werden und nur eine begrenzte Lebens- und Benutzungsdauer haben (siehe Abschnitt
4.8.7.2).
Ein weiterer Vorteil ergibt sich für die UNI-CA, wenn auch die Low-Level CA mit getrennten
Schlüsseln arbeitet (obwohl sie dazu nach der entsprechenden DFN-Policy nicht verpflichtet wäre):
Beide CAs können einen gemeinsamen Schlüssel als Kommunikationsschlüssel verwenden, so
daß es für Kommunikationspartner der UNI-CA einfacher wird, verschlüsselt an sie zu mailen, weil
dabei nicht noch einmal zwischen Low-Level- und Medium-Level-Verschlüsselungsschlüssel unterschieden
werden muß.
Da bei PGP-RSA-Schlüsseln die PGP-Versionen mit Ausnahme von PGP2.6.3in keine Software-
Unterstützung für eine automatische Berücksichtigung einer solchen Funktionstrennung bieten,
sollte diese (auch) durch entsprechende Klartext-Angaben in der Benutzerkennung wie etwa Zertifizierungsschlüssel
oder SIGN ONLY key signalisiert werden, so daß alle PGP-Anwender unabhängig
von der verwendeten Software-Version erkennen können, für welchen Zweck ein bestimmter CA-
Schlüssel vorgesehen ist.
4.8.3 Schlüssellängen
Bereits 1994 wurde ein 426-Bit-RSA-Key gebrochen – zwar dauerte dies damals acht Monate, aber
dafür wurde auch nicht der effizienteste bekannte Algorithmus für diesen Angriff verwendet. 1977
hatte der Auslober dieser Aufgabe, RSA-Miterfinder RON RIVEST, noch prognostiziert, er würde
deren Brechen nicht mehr miterleben [Fox95]. Anfang 1999 wurde bereits ein 465-Bit-RSA-Key
(die “RSA-140-Challenge”) geknackt [Con99], und inzwischen sind sogar 512-Bit-RSA-Schlüssel
gebrochen worden 3 .
3 http://www.rsasecurity.com/rsalabs/challenges/factoring/rsa155.html