Teil I Aufbau und Betrieb einer Zertifizierungsinstanz - DFN-CERT

5.2. Vorgehen bei Einrichtung der CA (“build”) 107
Wenn dann die CA-Schlüssel generiert werden und z.B. PGP um Tastendrücke bittet, um seinen
Zufallszahlen-Pool für die Schlüsselerzeugung zu füllen, dann sollte besonders darauf geachtet
werden, zufällige Eingaben zu machen, denn die sind nach [Lin98] unter Unix die einzige wirkliche
Zufallszahlen-Quelle bei der Schlüsselerzeugung. Alle anderen vermeintlichen Zufallsquellen
– system calls von times() und gettimeofday() – liefern recht gut vorhersagbare oder im Nachhinein
für einen Angreifer eingrenzbare Werte.
Die dann erforderliche Festlegung der Passphrase sollte unter Berücksichtigung des PGP passphrase
FAQs [Wil97] bzw. der Tips von RALF SENDEREK [Sen98] zur Wahl einer guten Passphrase
erfolgen. Falls das vorgeschlagene Vier-Augen-Prinzip für den Zugriff auf den Medium-Level UNI-
CA-Signierschlüssel realisiert werden soll, müssen beide involvierten CA-Mitarbeiter getrennt voneinander
ihren Teil der Passphrase festlegen, ohne daß der jeweils andere sehen kann, was eingeben
wird.
Wie wichtig eine gute Passphrase ist, belegt der Vorfall mit dem Caligula-Word-Makrovirus, das auf
befallenen Rechnern nach einem eventuell vorhandenen PGP-Secret-Keyring sucht und diesen per
FTP an einen anderen Rechner übermittelt (wo vermutlich versucht wurde bzw. wird, die Passphrase
zu knacken, die den Private-Key schützt) [CZ99a].
Der geheime Kommunikationsschlüssel der CA ist sodann an alle CA-Mitarbeiter unter Mitteilung
der ihn schützenden Passphrase zu verteilen. Falls dafür eine initiale, einfach zu merkende/ratende
Passphrase benutzt wurde, sind alle Betroffenen nochmals darauf hinzuweisen, daß sie umgehend
eine eigene, nicht-triviale Passphrase für den Schlüssel setzen müssen.
5.2.9 Vorbereitung der CA-Mitarbeiter
5.2.9.1 Zu verwendendes PGP-Nachrichtenformat
Diejenigen Rechenzentrumsmitarbeiter, die CA-Aufgaben wahrnehmen sollen, müssen darauf hingewiesen
werden, welche Form PGP-Mails der UNI-CA haben sollen. Es muß eine Entscheidung
getroffen werden zwischen dem „klassischen“ Format [ASZ96], bei dem die Nachrichten üblicherweise
als MIME-Typ text/plain verschickt werden, und einem etwas neueren Format [Elk96], das
den Vorteil bietet, daß die Content-Types der MIME-Bodyparts der E-Mail als multipart/encrypted;
protocol="application/pgp-encrypted" respektive als multipart/signed; protocol="application/pgpsignature"
gekennzeichnet sind (was die automatische Erkennung und Verarbeitung durch das Mailprogramm
erleichtert), das aber nicht von allen Mail-Useragents erzeugt und erkannt wird.
Die Entscheidung für das eine oder andere Format dürfte auch stark von den Vorlieben der einzelnen
Beteiligten hinsichtlich ihres bevorzugten Mail-UAs abhängen: mutt unterstützt beispielsweise
ausschließlich das neuere MIME-PGP-Format nach RFC 2015, andere Mail-Programme nur das
alte (so beispielsweise manche elm-Versionen oder Skripte für pine).
Was bei dieser Entscheidung nicht unberücksichtigt bleiben sollte, sind die Kommunikationspartner,
die mit dem gewählten Format klarkommen müssen. Da Prognosen darüber, ob das MIME-PGP-
Format mehr oder weniger Schwierigkeiten und Nachfragen nach sich ziehen würde, nur schwer
möglich sind, kommt es hier wohl wirklich auf die Erfahrungen in der Praxis an – falls die meisten
der Zertifizierungsinteressierten mutt benutzen, ist das MIME-Format möglicherweise unproblema-