Systeme und ihr Umfeld

Qualitätssicherung

Der Weg zur Zertifizierung: Die Sicht eines Herstellers

Von Ilja Ohliger, Wildberg

Zertifizierungen sind notwendig – sie sollen dem Anwender Produkt-Sicherheit bieten. Dass die aufwendigen Verfahren nicht unbedingt wirtschaftlich sind, monieren vor allem die Hersteller. Der Beitrag spiegelt deren Situation.

Für ein als international tätiges Unternehmen stellen sich die Anforderungen von Seiten der Kunden bezüglich der Prüfanforderungen (ITSEC, TCSEC, CC, FIPS 140-1) weltweit unterschiedlich dar. Während in Nordamerika seit 1985 die TCSEC (Trusted Computer System Evaluation Criteria) und seit 1994 die FIPS 140-1 (Federal Information Processing Standards Publication 140-1) zur Bewertung von IT-Security Produkten herangezogen werden, finden in Europa und in Australien seit 1991 vor allem die ITSEC (Information Technology Security Evaluation Criteria) und in jüngster Zeit auch die CC (Common Criteria) Anwendung.

Wegen des "Alters" der TCSEC spielt diese heute eine eher zu vernachlässigende Rolle. In Tabelle 1 ist ein Vergleich zwischen den Kriterien ITSEC, CC und der FIPS 140-1 dargelegt. Eine wesentliche Ursache für die hierzulande mitunter hohen Prüfanforderungen an IT-Security Produkte ist auch die Verabschiedung des Deutschen Signaturgesetzes im Jahre 1997 (SigG-D, siehe [externer Link] www.bsi.de) und die zugehörige Verordnung (SigV-D), welche konkrete Prüfanforderungen an Komponenten einer SigG konformen Zertifizierungsstelle und dort eingesetzte Komponenten festlegt.

[Tabelle 1]
Tabelle 1: Vergleich der Prüfkriterien ITSEC/CC/FIPS 140-1

Mit der Veröffentlichung der EU-Direktive für elektronische Signaturen am 19. Januar 2000 werden gemeinschaftliche Rahmenbedingungen für elektronische Signaturen festgelegt. Die Inhalte der Direktive müssen von den Mitgliedsstaaten innerhalb von 18 Monaten in die nationale Gesetzgebung umgesetzt werden.

Als erster Mitgliedsstaat hat Österreich mit dem Österreichischen Signaturgesetz der EU-Direktive Rechnung getragen. Das SigG-At und die SigV-At traten zum 01.01. 2000 in Kraft. Eine Gegenüberstellung des Deutschen Signaturgesetzes, des Österreichischen Signaturgesetzes und der EU-Direktive bietet Tabelle 2.

[Tabelle 2]
Tabelle 2: Vergleich der deutschen und österreichischen Signaturgesetze mit der EU-Direktive

Sicherheitsprüfung kontra Rentabilität

Im August 1997 trat das Deutsche Signaturgesetz in Kraft. Bis zum heutigen Tage sind aber nur zwei SigG konforme Zertifizierungsstellen verfügbar. Zuerst wurde das Trust Center der Deutschen Telekom AG fertig gestellt. Erst in diesem Jahr ging die Deutsche Post AG mit ihrem Unternehmen "SignTrust" an den Start.

Hinsichtlich der für die Rentabilität eines Herstellers von geeigneten Komponenten für den Einsatz in SigG konformen Zertifizierungsstellen notwendigen Nachfrage, ist das oben beschriebene Marktgeschehen dürftig. Die Anzahl der absetzbaren Produkte an diese beiden Anbieter düfte im Bereich von unter zehn Hardware Security Modules liegen. So erklärt es sich, dass bis heute noch keine SigG konformen Komponenten zur Schlüsselgenerierung, -speicherung und -anwendung (des private keys), welche als Produkte erstanden und als technische Komponenten innerhalb der technischen Umgebung eines Zertifizierungsdiensteanbieters eingesetzt werden können, auf dem Markt erschienen sind. Wie aber haben die beiden Unternehmen es dennoch geschafft, eine bestätigte Zertifizierungsstelle aufzubauen?

Die Deutsche Telekom AG hat schon seit einiger Zeit vor der Verabschiedung des SigG an ihrem Trust Center gearbeitet. So sind einige Komponenten zumindest ansatzweise schon in Studien erarbeitet worden. Andere Komponenten wurden in enger Zusammenarbeit mit einem Dienstleis-ter, welcher ausschließlich im Bereich IT-Sicherheit tätig ist, entwickelt und aufgebaut.

Unter vergleichsweise großem finanziellem Aufwand hat die Deutsche Post AG die vollständige Entwicklung aller Komponenten an denselben Dienstleister abgetreten.

Wenn von "Entwicklung" der Komponenten gesprochen wurde, so wurde noch nicht die "Verstrickung" mit den Anforderungen des SigG einerseits, und der ITSEC andererseit erwähnt. Da bei Komponenten zur Schlüsselgenerierung, Speicherung und Anwendung privater Schlüssel die hohe Prüfstufe ITSEC "E4" gefordert wird, sind bei diesen Komponenten umfangreiche Prüfarbeiten und Dokumentationen durchzuführen bzw. zu erstellen.

So stellt gerade die Korrektheits-Prüfstufe "E4" eine immens hohe Hürde dar. Neben der Forderung nach "semiformaler" Notation, bereitet insbesondere die Anforderung, ein Formales Sicherheitsmodell erstellen zu müssen, große Schwierigkeiten. Werden zudem moderne Programmiertechniken, wie z. B. die Objektorientierte Programmierung, während der Entwicklung verwendet, so kann ein Feinentwurf, welcher für jede so genannte Basiskomponente eine semiformale und informelle Beschreibung der Schnittstelle und der Funktionsweise beinhaltet, in die Nähe von 1000 Seiten gelangen.

Im formalen Sicherheitsmodell müssen die wesentlichen Sicherheitseigenschaften in formaler Weise modelliert und deren Invarianz während des Betriebs des Prüfgegenstands bewiesen werden. Dabei entsteht schon bei der Modellierung ein erheblicher Zeitaufwand – der Beweis dauert hiernach noch ungefähr doppelt so lange.

Für einen Hersteller von Produkten, welche in PKI, insbesondere für Zertifizierungsdiensteanbieter, eingesetzt werden können, ist die Integration möglichst vieler Komponenten geboten. Hierdurch erhöht sich die Anzahl der Sicherheitsfunktionen des Prüfgegenstandes erheblich. Bei einem Produkt, welches Schlüsselgenerierung, -speicherung und -anwendung vereint, ist so mit weniger als zehn Sicherheitsfunktionen nicht zu rechnen.

Zum Vergleich: Ein Schlüsselgenerator, der lediglich die Generierung von Schlüsseln und den Transport derselben auf etwa Smart Cards zu bewerkstelligen hat, benötigt rund vier Sicherheitsfunktionen.

Durch die Komplexität des Produkts ist somit mit einer Evaluationsdauer (die Evaluation wird entwicklungsbegleitend durchgeführt) von mindestens 14 Monaten zu rechnen. Daraus ergibt sich die Frage, warum ein Hersteller eine solche Investition bei den heute essentiell wichtigen, kurzen "time-to-market" Zeiten tätigen soll? Bis das Produkt evaluiert wurde und auf dem Markt verfügbar sein kann, ist die Technik meist so weit fortgeschritten, dass das Produkt zwar eine "bestätigte Sicherheitvermutung" aufweist, aber technisch weitgehend veraltet ist.

Auswirkungen der EU-Direktive

Spätestens mit der Veröffentlichung der EU-Direktive ist die Diskussion um die Auswirkungen hinsichtlich der nationalen Signaturgesetzgebungen bei allen Beteiligten entbrannt.

Die Direktive deckt im Gegensatz zum Deutschen Signaturgesetz auch (einfache) elektronische Signaturen ab. Dies sind Signaturen, die nicht die Anforderungen des Art.2 Abs.2a-d erfüllen. Zum Beispiel fällt das bloße Einfügen des Namens unter einer E-mail in diese Kategorie. Jede elektronische Signatur ist grundsätzlich in Gerichtsverfahren als Beweismittel zugelassen. Jedoch sind ausschließlich fortgeschrittene elektronische Signaturen, die auf einem qualifizierten Zertifikat beruhen und mit einer sicheren Signaturerstellungseinheit erstellt wurden, der handschriftlichen Unterschrift gleichzustellen.

Des weiteren erlaubt die EU-Direktive ein freiwilliges Akkreditierungssystem für Zertifizierungsdiensteanbieter. Dies bedeutet, dass Zertifizierungsdiensteanbieter ausdrücklich ohne vorherige Genehmigung ihren Betrieb aufnehmen können. Hierbei sind sie nach der EU-Direktive ermächtigt, qualifizierte Zertifikate auszustellen, ohne die in-house eingesetzten Komponenten evaluieren lassen zu müssen. Sie müssten lediglich in einer "Anmeldung zur allgemeinen Betriebserlaubnis" darlegen, dass sie die Anforderungen aus dem Anhang II der Direktive erfüllen.

Angesichts dieser Lockerung der bestehenden Regulierungen innerhalb des deutschen SigG stellt sich die Frage, wie sich kurzfristig bis mittelfristig das Angebot an Zertifizierungsdiensteanbieter hierzulande und in Europa darstellen wird.

Aufgrund ökonomischer Gründe werden wohl eine Vielzahl von nicht-akkreditierten Zertifizierungsdiensteanbietern am Markt erscheinen und ihre zu den akkreditierten Zertifizierungsdiensteanbietern preisgünstigeren Dienste anbieten. Dabei werden sowohl Zertifizierungsdiensteanbieter, welche qualifizierte Zertifikate ausstellen und den Anforderungen des Anhangs II der Direktive entsprechen, als auch Zertifizierungsdiensteanbieter, die alle sicherheitstechnisch gesehen "niederwertigeren" Dienste anbieten, in vielen Bereichen des Wirtschaftslebens aufzufinden sein.

Die Möglichkeit, als Zertifizierungsdiensteanbieter ohne vorherige Genehmigung Dienstleistungen anbieten zu können, wird den PKI-Markt spürbar beleben und in allen Bereichen, in denen Public Key Infrastrukturen sinnvoll eingesetzt werden können, rege Anwendung finden.

Alternativen

Dass durchaus Alternativen zu den hohen "Prüfhürden" bei der Regelung der Verbindlichkeit einer elektronischen Unterschrift existieren, zeigt zum Beispiel das Unternehmen [externer Link] Identrus.

Die weltweit führenden Banken haben sich in jüngster Zeit zusammengeschlossen, um eine globale PKI aufzubauen. Als Root-CA dient dabei die Zertifizierungsinstanz, welche vom Unternehmen "Identrus" aufgebaut wird.

Alle CAs der Banken oder hierarchisch darunter liegender Instanzen müssen für die Generierung, Speicherung und Anwendung von Schlüsseln sogenannte "Hardware Security Modules (HSMs)" verwenden. Diese HSMs müssen neben Anforderungen hinsichtlich der Funktionalität eine sicherheitstechnische Prüfung absolvieren. Die Prüfung kann nach FIPS 140-1 durchgeführt werden. Die HSMs müssen dabei die Prüfung mit der Prüfstufe "Level 3" erfolgreich durchlaufen.

Angesichts der signifikant kürzeren Prüfdauer im Vergleich zur ITSEC oder CC (vgl. Tabelle 1) liegt die Annahme nahe, dass dem HSM, welches eine FIPS 140-1 Evaluation erfolgreich durchlaufen hat, ein geringeres Vertrauen entgegenzubringen sei.

Diese Annahme ist aber nicht gerechtfertigt. Im Gegensatz zur ITSEC oder CC konzentriert sich das Kriterienwerk der FIPS 140-1 auf die sicherheitstechnischen Kernbereiche des Prüfgegenstands. So beziehen sich die Korrektheitsanforderungen der ITSEC/CC u. a. auf die geeignete Verfeinerung des Entwurfs von den Sicherheitsanforderungen bis hin zu den auf der hierarchisch untersten Ebene identifizierbaren Basiskomponenten. Weiterhin wird die Korrektheit der Implementierung durch Tests -bei hohen Prüfstufen- auch der Basiskomponenten gefordert. Die ausreichende Dokumentierung für Administratoren und Benutzer, die geregelte Inbetriebnahme und Auslieferung mit Konfiguration und – bei der CC – die Definition des gesamten Life-Cycles, werden bei ITSEC und CC gefordert.

Diese Korrektheitsanforderungen der ITSEC/CC werden im Wesentlichen von den ohnehin bei hinsichtlich der Qualitätssicherung fortgeschrittenen Unternehmen durch entsprechende Qualitätssicherungsmaßnahmen gewährleistet. Insofern sind die Anforderungen hinsichtlich der Korrektheit bei der ITSEC oder den CC als eine Art "Qualitätssicherungsmaßnahmen" einzustufen.

Diese Qualitätssicherungsmaßnahmen tragen sicherlich zu einem gewissen Maße zur Sicherheit eines Prüfgegenstandes bei, sind aber als sicherheitstechnisches Bewertungskriterium alleine nicht aussagekräftig genug. Deshalb wird die Bewertung der Stärke der Mechanismen, angenommenen Bedrohungen entgegenzuwirken, bei ITSEC/CC getrennt untersucht. Die Bewertungsergebnisse werden in "niedrig", "mittel" oder "hoch" eingestuft und an die Korrektheitsbewertung "angehängt" (E4/hoch oder "EAL3/mittel").

In den letzten Jahren sind große Fortschritte bei der Entwicklung von Qualitätssicherungsmodellen innerhalb des Software-Entwicklungsprozesses erreicht worden. Als Beispiel seien hier die "Software, Systems Engineering, and Product Development Capability Maturity Models® (CMMs®)", die sich in zunehmendem Maße auch außerhalb der Vereinigten Staaten vor allem bei Großunternehmen etablieren, genannt.

Neuer Ansatz

Die Annahme liegt nahe, dass während einer ITSEC und CC Evaluation deshalb ein so großer Aufwand in die Korrektheitsuntersuchung investiert werden muss, weil sich zur Entstehung der ITSEC Ende der 80er/Anfang der 90er-Jahre noch keine entsprechenden Qualitätsmodelle bei der Software-Entwicklung etabliert hatten.

Diese Annahme ist heute für viele Unternehmen nicht mehr zutreffend. Sinnvoller erscheint der Ansatz, die Qualitätssicherung bei dem Entwicklungsprozess generell zu bewerten und zur Bewertung der Sicherheitsaspekte das FIPS 140-1 Kriterienwerk heranzuziehen. Dies hat den Vorteil, dass ein erworbenes Qualitätssicherungszertifikat für die Gesamtbewertung zusammen mit der sicherheitstechnischen Bewertung mittels FIPS 104-1 Evaluation von mehreren Prüfgegenständen herangezogen werden kann und nicht bei jeder neuen Evaluation die Korrektheit erneut untersucht werden muss.

Aussicht

Angesichts der zu Beginn des Jahres 2000 in Kraft getretenen EU-Direktive und der öffentlich von Seiten der zuständigen EU-Kommissare verkündeten Initiative zur Förderung des elektronischen Geschäftsverkehrs innerhalb der EU-Mitgliedsstaaten, bleibt zu hoffen, dass sich eine eher pragmatische, nicht ausschließlich den Sicherheitsbedenken folgende, Sichtweise bei allen Beteiligten etablieren wird.

Erste Anzeichen hierfür können in dem Österreichischen Signaturgesetz und aus vorläufigen Stellungnahmen der ETSI/CEN (EESSI, European Electronic Signature Standardization Initiative) Arbeitsgruppen, die Empfehlungen für den Artikel 9 Ausschuss erarbeiten, gesehen werden.

Wünschenswert wäre es, dass auch die noch nicht verabschiedeten Signaturgesetze der Mitgliedsstaaten, dem pragmatischen "Geist der Direktive" folgen werden. Dies gilt insbesondere für das Deutsche SigG, da es im Europäischen Umfeld die Rolle des "Pioniers" inne hat.

Ilja Ohliger ist Leiter der Produktevaluation bei Concord-Eracom Computer Security GmbH

© SecuMedia-Verlags-GmbH, D-55205 Ingelheim,
KES 3/2000, Seite 69