Fail-Safe-Konzept für Public-Key-Infrastrukturen - tuprints ...

4.5 Funktionalität im Schadensfall 123
5. Was passiert, wenn der Benutzer den Austausch nicht bestätigt?
Dann wird kein Austausch durchgeführt. Der Certificate Holder muss mit Problemen in
der Verfügbarkeit rechnen, wenn die Redundanz-PKI PKI u ebenfalls ausfallen sollte.
6. Wie reagiert der Ablauf in Phase 3 auf einen Stromausfall oder Rechnerabsturz?
In diesem Fall kann ein erneuter Anlauf versucht werden.
Bevor mit Client-relevanten Aktionen fortgefahren wird, wird die Sicherheit des UpdateComponents
thematisiert.
4.5.5 Sicherheit des UpdateComponents
Angenommen, das UMP initiierende UpdateComponent ist bei der PSE eines Certificate Holders
angekommen – also bei der Software-PSE in Mail Client, Rechner S, Rechner C oder
Zugangskontroll-Client oder bei einer Chipkarte. Die Verifikation des UpdateComponents unterscheidet
sich deutlich von den bisher betrachteten Verifikationen von Signaturen, weil ein
UpdateComponent als ein Kommando nicht nur authentisch und integer, sondern auch richtig
adressiert und aktuell sein muss. Dadurch werden existenzielle Fälschungen, gefälschte Kommandos,
korrekte Kommandos bei falschen Certificate Holdern und Replay-Attacken verhindert.
In diesem Abschnitt wird die Sicherheit des UpdateComponents in fünf Teilen analysiert. Zunächst
wird das UMP-Signatur/UMP-Verifikations-Modell für UpdateComponents dargestellt
und anschließend für die Sicherheitsbetrachtungen genutzt. In diesen Betrachtungen wird argumentiert,
weshalb ein derart abgesichertes UpdateComponent die bei Kommandos üblichen
Sicherheitsziele Authentizität, Integrität, korrekte Adressierung und Aktualität erfüllt. Ein für
die Sicherheit wesentliches Hilfsmittel ist die Registry des Fail-Safe-Konzepts, die im dritten Teil
erläutert wird. Die vom Modell abweichende Realität – Verfahren werden in Providern zusammengefasst
und es werden Provider statt einzelne Verfahren ausgetauscht – wird im vierten Teil
betrachtet. Und schließlich werden mit dieser Konstruktion vereitelte Angriffe diskutiert.
UMP-Signatur/UMP-Verifikations-Modell
Das Update Management Protocol (UMP) wird auf besondere Weise signiert und auf besondere
Weise verifiziert.
Ein UpdateComponent wird mit einer UMP-Signatur abgesichert. Eine UMP-Signatur besteht
aus zwei digitalen Signaturen, die von zwei voneinander unabhängigen Signaturverfahren
erzeugt worden sind, die keine kryptographische Primitive gemeinsam haben, und eine der beiden
Signaturen muss mit einem Signaturverfahren aus der vom Schaden kompromittierten Teil-PKI
erzeugt worden sein. In Abschnitt 4.5.3 auf Seite 117 werden alle möglichen Fälle diskutiert.
Diese beiden Maßnahmen spiegeln sich in der für ein Akzeptieren eines UpdateComponents
notwendigen Verifikation wider – der UMP-Verifikation. Die UMP-Verifikation besteht aus
festen und variablen Sicherheitsbedingungen, so genannten Security Conditions, die für eine
positive UMP-Verifikation erfüllt sein müssen. Die festen Security Conditions überwachen, ob
das Format eingehalten wird und ob zwei Signaturen vorhanden und mathematisch korrekt
sind, während die variablen Sicherheitsbedingungen für die Einhaltung der zuvor geschilderten
Maßnahmen sorgen: Benutzung zweier voneinander unabhängiger Signaturverfahren, von denen
eines vom Schaden tangiert ist. Die Variabilität ist nötig, weil sich diese Fakten durch neue
Erkenntnisse oder neue Algorithmen ändern können. Aus diesem Grund werden die variablen
Security Conditions über eine Registry definiert, die auf Seite 127 im Detail erläutert wird.