Joint Interpretation Library. Anwendung der ITSEC auf Integrierte Schaltungen

Transkript

1 Joint Interpretation Library Anwendung der ITSEC auf Integrierte Schaltungen Stand: Januar 1999

2 Inhaltsverzeichnis Vorwort Zielsetzung Abbildung der ITSEC auf Integrierte Schaltungen Einführung Vertrauenswürdigkeit Korrektheit Sicherheitsvorgaben Architekturentwurf Feinentwurf Implementierung Konfigurationskontrolle Programmiersprachen und Compiler Sicherheit beim Entwickler Benutzerdokumentation Systemverwalter-Dokumentation Auslieferung und Konfiguration Anlauf und Betrieb Vertrauenswürdigkeit Wirksamkeit Eignung der Funktionalität Zusammenwirken der Funktionalität Stärke der Mechanismen Bewertung der Konstruktionsschwachstellen Benutzerfreundlichkeit Bewertung der operationellen Schwachstellen Abkürzungsverzeichnis und Glossar Quellen Januar 1999

3 1 Vorwort Durch den zunehmenden Einsatz der Informationstechnik hat sich nicht nur die Gesellschaft gewandelt, sondern auch die Formen der Informationsspeicherung und Verarbeitung. Aufgrund der Packungsdichte auf Silizium in Form eines Mikrochips und der Steigerung der Taktfrequenz ist es möglich, immer mehr Informationen parallel und schnell zu verarbeiten. Diese informationsverarbeitenden komplexen Mikrochips bringen neben den immensen Vorteilen jedoch auch Risiken und Gefahren mit sich. Die Abhängigkeit sowohl vom reibungslosen Funktionieren als auch von der Wirksamkeit der realisierten Schutzkonzepte auf Systemwie auf Chipebene hat sich sehr vergrößert. Es müssen daher verstärkt Möglichkeiten wahrgenommen werden, wichtige informationstechnische Systeme einschließlich der Hardware nach anerkannten Kriterien zu prüfen, um damit die Vertrauenswürdigkeit der Sicherheitsfunktionalität für den Hersteller, Betreiber und den Anwender transparenter zu machen. Diese Publikation wurde bei der Zertifizierungsstelle im Bundesamt für Sicherheit in der Informationstechnik (BSI) entwickelt und mit der JIWG ( Joint Interpretation Working Group) abgestimmt. Nach dem BSI-Errichtungsgesetz [BSIG] hat BSI, das in viele Aktivitäten zur Erhöhung der IT-Sicherheit involvierte ist, u.a. die Aufgabe, die Sicherheit von IT-Systemen bzw. IT-Komponenten (im Sinne eines IT-Produktes) auf Antrag zu prüfen und Sicherheitszertifikate zu vergeben ( 3 Abs.1 Nr.3 BSIG). Diese Druckschrift wurde im Rahmen der Grundlagenarbeit zur Zertifizierung erstellt und soll insbesondere Herstellern, Evaluatoren und Zertifizierern als Handbuch für die Anwendung der ITSEC auf Hardwarekomponenten in Form Integrierter Schaltungen dienen. 2 Zielsetzung Eine wichtige Aufgabe der Zertifizierungsstelle ist die Sicherstellung der Einheitlichkeit der Durchführung und der Vergleichbarkeit der Ergebnisse von Evaluationen. Voraussetzung dafür ist die Gleichwertigkeit der Anwendung der Sicherheitskriterien ITSEC durch die evaluierende Prüfstelle und die Zertifizierungsstelle selbst. Nach den ITSEC können die Sicherheitseigenschaften sowohl von Hardware- als auch von Softwareprodukten zertifiziert werden (vgl. ITSEC 1.2). Die Formulierungen der ITSEC sprechen hingegen vielfach Software an, oder die Terminologie macht eine Abbildbarkeit auf Hardware nicht gleich erkennbar. Dies hat dazu geführt, daß bisher die ITSEC im wesentlichen auf Software angewandt wurden. Es setzt sich jedoch zunehmend die Erkenntnis durch, daß auch die Hardware in die Sicherheitsüberprüfung nach ITSEC einbezogen werden muß. Die folgenden Erläuterungen zu den einzelnen Prüfaspekten der ITSEC sollen die Anwendung der ITSEC auf Integrierte Schaltungen bis zur Evaluationsstufe E4 unterstützen und eine einheitliche Interpretation der ITSEC-Anforderungen in der Anwendung erleichtern. Auf Softwareaspekte wird in diesem Skriptum nur zur Verdeutlichung und zur Gegenüberstellung an einigen Stellen eingegangen, da ITSEC, ITSEM sowie die ITSEC-JIL (siehe Kap. 5, Quellen) hierzu bereits ausführliche Informationen vermitteln. Januar

4 3 Abbildung der ITSEC auf Integrierte Schaltungen 3.1 Einführung Bei der Abbildung der ITSEC-Aspekte auf Hardwarekomponenten können grundsätzlich zwei Arten von Evaluationsgegenständen (EVG) betrachtet werden. Ein EVG wird realisiert aus einer Menge von diskreten Bauteilen auf einer Platine oder als Hybrid durch verschiedene oder mehrere Dice auf einem Träger. Ein EVG wird realisiert als einzelner integrierter Schaltkreis (Integrated Circuit, IC). Die ITSEC-Aspekte der Vertrauenswürdigkeit eines EVG beziehen sich im folgenden auf die Hardware eines IC. Generell können z.b. die Funktionalitäten in einem IC in einfachen PLD-Strukturen (Programmable Logic Device), FPGA-Strukturen (Field Programmable Gate Array), als ASIC (Application Specific Integrated Circuit) sowie als kundenspezifischer Schaltkreis realisiert sein. Im Bereich der Sicherheitsanwendungen werden für die elementaren Kernbestandteile der Sicherheitsfunktionalität hauptsächlich intelligente Speicher-ICs mit einer festverdrahteten Sicherheitslogik (z.b. Telefonkarte) oder ICs im ASIC-Design mit Mikrocontroller verwendet (z.b. EC-Geldkarte). Speicher-ICs basieren auf EPROM- oder E 2 PROM-Zellen, die ein nichtflüchtiges Speichern von Daten ermöglichen. Eine Sicherheitslogik kann der Identifikation und Authentisierung, der Verwaltung der Speicherzugriffe oder der IC-internen Ablaufkontrolle dienen. Die auf Mikrocontroller basierten ICs bieten die Möglichkeit, selbständig komplexe Vorgänge betriebssystemgesteuert auszuführen. Dazu zählen zu den bereits genannten Funktionalitäten auch Beweissicherungsfunktionen und Dienstleistungen wie Verschlüsselung und digitale Signatur. Die Funktionalitäten werden hier sowohl in Hardware als auch in Software realisiert. Die Mechanismen zum Schutz der Programm- und Arbeitsdaten in den verschiedenen Speichern und der internen Abläufe werden durch die Hardware eines Mikrochips (z.b. durch bestimmte technische Maßnahmen und technologische Eigenschaften) zur Unterstützung logischer Funktionalitäten zur Verfügung gestellt. So ist beispielsweise das Betriebssystem eines Mikrocontroller-ICs in einem ROM und/oder einem E 2 PROM-Speicher untergebracht und in der Betriebsphase durch technische oder technologische Eigenschaften der Hardware vor einer Veränderung und Ausspähung geschützt. Während technologische Eigenschaften EVGinhärent sind, müssen technische Eigenschaften nicht unbedingt EVG-inhärent sein. 3.2 Vertrauenswürdigkeit Korrektheit Sicherheitsvorgaben Das Dokument 'Sicherheitsvorgaben' dient sowohl der Spezifikation der Sicherheitseigenschaften eines IT-Produktes auf einem abstrakten Niveau, als auch der Beschreibung des Produktes und der Einsatzumgebung, unabhängig davon, ob es sich dabei um Software und/oder Hardware handelt. Diese Spezifikation ist i.d.r. unabhängig von der Art der Implementierung. Dennoch werden im folgenden einige Anmerkungen zu Einzelanforderungen gemacht. 4 Januar 1999

5 1. Produktbeschreibung / Identifikation des EVG (E1-E4) Ein IC als EVG kann im Sinne der ITSEC als Produkt betrachtet werden. Dieses Produkt muß, wie im Falle eines Software-EVG, beschrieben, eindeutig identifiziert und gegen seine technische und administrative Einsatzumgebung abgegrenzt werden. Da die Hardwareteile auf einem Mikrochip sowohl physisch wie funktional schwer voneinander trennbar sind, ist es i.d.r. nicht ohne weiteres möglich, Teile der Hardware nicht als Teil des EVG zu betrachten. Es ist sinnvoll, die gesamte Chip-Hardware als EVG zu betrachten. Im Falle einer Ausgrenzung bestimmter Teile des Chips muß eine klare, logische und physische Schnittstelle erkennbar sein (vgl. auch ITSEC-JIL, Kap ). Die Einbeziehung von hardware-orientierter Software/Firmware in den EVG ist zweckmäßig. Es könnte sinnvoll sein, einen IC als Ganzes zu betrachten und nicht nur die Hardware oder nur die Software. Im Zusammenhang mit der Abgrenzung des EVG muß in jedem Falle klar festgelegt werden, ab welchem Zeitpunkt im Produktionsprozess der EVG als vollständig vorhanden gilt. Im Gegensatz zu reinen Software-EVGs ist diese Festlegung in den hier betrachteten Fällen nur mit genauer Kenntnis des Produktionsprozesses möglich. Diese Festlegung hat dann jedoch auch unmittelbaren Einfluß auf die Bedrohungs- und Angriffsszenerien im Betrieb des EVG, die im Kontext der Evaluation des EVG angenommen werden können. Dieser Zeitpunkt könnte bei einem IC frühestens nach dem Testen als Die oder spätestens nach Abschluß des Packaging und der damit verbundenen Tests vorliegen. Wenn der EVG ebenfalls eine Personalisierung durchläuft, so muß diese Phase auch in der Evaluation berücksichtigt werden. 2. Produktbeschreibung / vorgesehene Art der Nutzung des Produktes (E1-E4) Für die Art der Nutzung des EVG im Betrieb ist es von Interesse zu erfahren, wer den Chip nach der Auslieferung benutzen kann und in welchen Betriebsmodi die Nutzung des Chips möglich ist. Es sind entsprechende Subjekte, Objekte und Zugriffsarten zu definieren, um die Art der Nutzung besser verstehen zu können. In diesem Zusammenhang müssen auch die Handlungen aller Personen betrachtet werden, die nach der Auslieferung mit dem EVG in Berührung kommen. 3. Produktbeschreibung / vorgesehene Einsatzumgebung (E1-E4) Entsprechend den Ausführungen zu (2.) sind ggf. entsprechende Anforderungen zu formulieren. Ansonsten ergibt sich keine spezifische Interpretation der ITSEC. 4. Sicherheitspolitik / Sicherheitsziele (E1-E4) / Formales Sicherheitsmodell (E4) Grundsätzlich gibt es keine Unterschiede gegenüber der Betrachtung eines Software- EVG, jedoch sollten hier auch Sicherheitsziele in Zusammenhang mit den technischen und technologischen Eigenschaften des Chips formuliert werden. Das formale Sicherheitsmodell (ab E4) ist eine formale Beschreibung der Sicherheitspolitik mittels geeigneter formaler Sprachen (siehe ITSEC-JIL, Kap. 19). Die Beschreibung erfolgt auf einer abstrakten Ebene und ist unabhängig von der Implementierung des EVG in Hardware oder Software. Eine spezifische Interpretation ist hier nicht erforderlich. 5. Angenommene Bedrohungen (E1-E4) Die Bedrohungen richten sich gegen die Sicherheitsziele, die man unter Punkt (4.) definiert hat. Januar

6 Neben logischen Funktionalitäten können auch technische und technologische Eigenschaften in der Betriebsphase des EVG angegriffen werden. Somit ist es von Bedeutung, daß entsprechende Bedrohungen formuliert werden (z.b.: Auslesen von Objekten auch mittels physikalischem Angriff, Betrieb des EVG außerhalb spezifizierter Parameterbereiche wie Spannung, Frequenz, Temperatur). Es sollte bei der Festlegung der angenommenen Bedrohungen beachtet werden, daß Angriffe auf einen EVG während des Produktionsprozesses insbesondere in der Testphase möglich sind und sich in der Betriebsphase in Form von Schwachstellen auswirken können (vgl. Sicherheit beim Entwickler, Schwachstellenanalyse). 6. Definition der sicherheitsspezifischen Funktionen (E1-E4) Bei der Betrachtung von ICs muß die Bedeutung des Begriffs der sicherheitsspezifischen Funktionen erweitert werden, da die Sicherheitseigenschaften des EVG sowohl in Form logischer Funktionalitäten als auch in Form implementierter technischer Eigenschaften oder in Form technologischer Eigenschaften vorliegen (vgl. ITSEC-JIL, Kap ). Dabei sind technologische Eigenschaften EVG-inhärent, während technische Eigenschaften nicht unbedingt EVG-inhärent sein müssen. Folgende Typen von sicherheitsspezifischen Funktionen können unterschieden werden: sicherheitsspezifische Funktionen in Form logischer Funktionalitäten 1 (z.b. Authentisierungslogik), die sich gegen logische Angriffe richten. Sie wirken einer Bedrohung direkt entgegen. sicherheitsspezifische Funktionen, die nicht nur aus logischen Funktionalitäten bestehen, sondern zusätzlich auch technische oder technologische Eigenschaften beinhalten. Diese Funktionen könnten durch eine Kombination von passiver Struktur mit aktiver Logik realisiert worden sein (z.b. mögliche Überwachung der Versorgungsspannung durch integrierte CMOS-Technologieparameter in bestimmten Bereichen des ICs). sicherheitsspezifische Funktionen im Sinne technischer Eigenschaften, die einen Angriff erschweren. Mit Hilfe solcher technischer Eigenschaften werden beispielsweise Speicherbereiche und Funktionselemente der Hardware vor Angriffen geschützt. Diese technischen Eigenschaften des EVG ergeben sich aus Maßnahmen im Entwicklungs-/Produktionsprozess. Dabei kann es sich um die Verwendung bestimmter Strukturen, wie besondere Busstrukturen (Verschleierung) oder Schutzschichten (Passivierung der Metallisierungsschicht), handeln. Bei der Spezifikation der Sicherheitseigenschaften ist es wichtig, daß alle o.g. Typen von sicherheitsspezifischen Funktionen berücksichtigt werden. 7. Zu Zweckmäßigkeit der Funktionalität und Entgegenwirken gegen Bedrohungen Die von den ITSEC geforderten Begründungen müssen alle betrachteten Typen von Sicherheitsfunktionen berücksichtigen Architekturentwurf Der Architekturentwurf muß für jede Evaluationsstufe u.a. die grundsätzliche Struktur und die externen Schnittstellen auf einem hohen Abstraktionsniveau mit einer Untergliederung in die 1 Gemeint sind Funktionalitäten, die in Hardware realisiert sind und mit Software vergleichbare Funktionalitäten haben. 6 Januar 1999

7 Hauptkomponenten beinhalten. Dazu kann ein Blockdiagramm, das in der Design- und Konzeptionsphase entsteht, neben einer informellen Beschreibung Bestandteil des Architekturentwurfs sein. 1. Grundsätzliche Struktur des EVG (E1-E4) Da die Sicherheitseigenschaften eines IC sowohl aus logischen Funktionalitäten als auch aus technischen und technologischen Eigenschaften bestehen können, ist es notwendig, sowohl die grundsätzliche Struktur der funktionalen Komponenten aufzuzeigen als auch die technische und technologische Struktur darzulegen, da sie für die Hardware- Sicherheitseigenschaften und deren Evaluation von Bedeutung sind. In vielen Fällen können Komponenten, die die grundsätzliche Struktur des IC darstellen, bestimmte logische Einheiten sein, die möglicherweise auch in derselben Abgrenzung unmittelbar als physische Einheiten auf dem Chip realisiert sind. Beispiele: Speicher, Daten-/Adreßbus-Speicherinterface, Arithmetikblock, Kontaktinterface, Watchdog- Timer, Sensoren mit Auswertelogik, Versorgungsspannungskontrolle, Logikblöcke zur Zugriffskontrolle oder Authentisierung bei Speicher-ICs mit Sicherheitslogik, Mikrocontrollerblock bei Mikrocontroller-ICs. Ebenso könnte beispielsweise eine Schutzschicht als Komponente der grundsätzlichen Struktur des physisches Aufbaus des EVG gesehen werden. 2. Externe Schnittstellen des EVG (E1-E4) Externe Schnittstellen können sein: Schnittstellen zu Hardware-Teilen des IC, die nicht Teil des EVG sind (sofern der EVG so abgegrenzt wird), oder Schnittstellen zu Software/Firmware, die im Chip gespeichert ist und nicht Teil des EVG ist, aber auf der betrachteten Chip-Hardware abläuft (z.b. Auslösen eines Interrupts über Hardware) oder logische und physische Schnittstellen des IC (Kontakte des IC), die die Verbindung zur Außenwelt sicherstellen. Externe Schnittstellen sollten nicht nur auf der logischen Ebene (funktionale Eigenschaften), sondern auch im Hinblick auf die von außen einstellbaren Betriebsparameter und deren Grenzwerte betrachtet werden, da sich daraus möglicherweise direkte Angriffe oder Schwachstellen ableiten lassen. 3. Hard- und Firmware, die der EVG benötigt (E1-E4) Da der EVG selbst aus Hardware besteht, kann weitere Hardware für den Betrieb benötigt werden. Es ist zu bemerken, daß eine externe Spannungs- und Taktversorgung oder ein bestimmtes Daten-Interface zum Betrieb des EVG notwendig werden kann. Für den Fall, daß nicht die gesamte Hardware des Chips zum EVG hinzugezählt wird, kann es Hardwareanteile auf dem Chip geben, die der EVG im Betrieb benötigt. Diese Hardwareanteile darf der Evaluator nicht aus den Augen verlieren, da sich daraus Schwachstellen entstehen können. 4. Funktionalität der unterstützenden Schutzmechanismen (E1-E4) Für den Fall, daß unterstützende externe Schutzmechanismen vorhanden sind, ist eine klare Unterscheidung zwischen internen Mechanismen des EVG und den externen Mechanismen notwendig. Dabei sind die Abhängigkeiten innerhalb der Hardware oder Januar

8 zu möglicherweise relevanter Firmware zu berücksichtigen. Nur die EVG-internen Mechanismen unterliegen den Evaluationsanforderungen der ITSEC. Es könnte z.b. ein Prüfsummenalgorithmus teilweise in einer nicht zum EVG gehörigen Firmware implementiert sein und das Ergebnis der Prüfung von der Hardware des EVG ausgewertet werden. Eine exakte Beschreibung der Abhängigkeiten und des Verhaltens der Schnittstelle ist notwendig. 5. Aufteilung des EVG in sicherheitsspezifische und andere Komponenten (E2-E4) Die ab E2 geforderte Separierung von sicherheitsspezifischen Komponenten gegenüber anderen Komponenten des EVG oder Komponenten aus der Einsatzumgebung ist sorgfältig zu betrachten, da innerhalb des IC selbst starke Abhängigkeiten zwischen verschiedenen physischen Komponenten auf der Implementierungsebene existieren, die eine wirksame Separierung im Sinne der ITSEC erschweren. Somit ist es meist notwendig, alle Komponenten eines IC auf der Ebene des Architekturentwurfs als sicherheitsspezifisch einzustufen. Eine Begründung zur ab E4 geforderten größtmöglichen Unabhängigkeit der sicherheitsspezifischen Komponenten ist in der dargestellten Struktur des EVG auf Basis logischer und physischer Abhängigkeiten durchzuführen. Eine größtmögliche Unabhängigkeit von Komponenten innerhalb eines IC könnte vorliegen, wenn es keine oder nur minimale physische Überschneidungen und logische Abhängigkeiten zwischen einzelnen Komponenten gibt und die Schnittstellen klar definiert sind. 6. Semiformale Notation (E4) Die ab E4 geforderten semiformalen Beschreibungen der Architektur können in Form von Blockschaltbildern oder in Form von Dokumenten einer Hardware-Beschreibungssprache (HDL: Hardware Description Language) zur Verfügung gestellt werden. In vielen Fällen wird eine Hardware-Beschreibungssprache jedoch erst auf der Ebene des Feinentwurfes angewandt. Die semiformale Darstellung von technischen oder technologischen Eigenschaften, die ein Teil von sicherheitsspezifischen Funktionen des EVG sind, könnte in Form aussagefähiger graphischer Darstellungen zur Verfügung gestellt werden. Eine informelle Dokumentation, auch der technischen und technologischen Eigenschaften, deren Einbindung in die Struktur und die Realisierung der sicherheitsspezifischen Funktionen, ist in jedem Fall notwendig. 7. Nachweise, wie die sicherheitsspezifischen Funktionen der Sicherheitsvorgaben zur Verfügung gestellt werden (E1-E4) Die Zuordnung der sicherheitsspezifischen Funktionen zu Komponenten ist vielfach schwierig, da einzelne Komponenten nicht nur zur Realisierung einer einzigen sicherheitsspezifischen Funktionalität dienen und sehr starke Wechselwirkungen und Abhängigkeiten zwischen den Komponenten bestehen. Aus diesem Grunde ist eine Beschreibung des funktionalen Ablaufes der sicherheitsspezifischen Funktionen bezogen auf die definierten Komponenten von besonderer Bedeutung Feinentwurf Auf dieser Entwurfsebene des IC wird i.d.r. eine HW-Beschreibungssprache (HDL) verwendet. Die aus der Verwendung eines HDL-Tools und eines CAD-Tools resultierenden Kon- 8 Januar 1999

9 struktionspläne und funktionalen Beschreibungen können unmittelbar bei der Erstellung des Feinentwurfes nach ITSEC verwendet oder herangezogen werden, müssen selbst jedoch erst ab E3 vollständig vorgelegt werden. Falls erforderlich, muß der Evaluator dann die Möglichkeit haben, die vom Hersteller verwendeten Tools zur Evaluation einzusetzen. Parametereinstellungen für den Produktionsprozess werden unter Berücksichtigung der technologiespezifischen Besonderheiten durch die CAD-Tools festgelegt. Die zur Konstruktion des EVG notwendigen Design-Unterlagen sind: Logikpläne, z.b. mit Analogzellen, Standardzellen, Gattern, Transistoren und Dioden, die benötigt werden, um die einzelnen Funktionalitäten bzw. auch Sicherheitsfunktionalitäten zu realisieren, Layoutpläne, die die Plazierung der Komponenten im Hinblick auf die Prozessmasken beschreiben und die Metallisierungsmasken festlegen, Maskenpläne, die für den technologischen Prozess erforderlich sind. Die Maskenpläne müssen nur in bestimmten Fällen ab E3 vorgelegt werden, wenn sie der Schwachstellenanalyse dienen. Die technische und technologische Struktur des EVG ist verfeinert darzulegen, damit bei der Betrachtung physikalischer Angriffe auf den EVG eine Wirksamkeitsanalyse im Kontext der angenommenen Bedrohungen möglich ist. 1. Basiskomponenten (ITSEC, 4.21 für Stufen E2-E4) und deren Spezifikation im Feinentwurf (E3.8 und E4.8 für E3-E4), Schnittstellen Eine Basiskomponente ist eine Komponente, die auf der untersten hierarchischen Stufe der Spezifikation im Feinentwurf identifizierbar ist (ITSEC 6.10). Im Falle eines IC werden aus den Basiskomponenten die tatsächlichen Logik- und Layoutpläne entstehen, wobei die Abgrenzung der Basiskomponenten den Testbarkeitsanforderungen genügen muß, d.h. daß die Schnittstellen der Basiskomponenten (ab E3) und die Basiskomponenten selbst (ab E4) testbar sein müssen. Ergänzend ist zu bemerken, daß die Basiskomponenten bei E2 lediglich der Verfeinerung der Struktur des EVG dienen. Die Schnittstellen zwischen Komponenten müssen auf der Ebene der Basiskomponenten besonders sorgfältig beschrieben werden, da es i.d.r. starke Abhängigkeiten zwischen den Basiskomponenten in einem IC gibt (E3-E4). Zeitlich parallel ablaufende Funktionen sind bei der Schnittstellenbeschreibung zu berücksichtigen. Das Timing an den Schnittstellen der Basiskomponenten ist zu beschreiben, wenn sie von außen (z.b. pads) für Tests zugänglich sind. 2. Semiformale Notation (E4) Die ab E4 geforderten semiformalen Beschreibungen können in Form verfeinerter Blockschaltbilder, Flowcharts, Zustands-Diagrammen, Wahrheitstabellen oder in Form von Dokumenten in einer Hardware-Beschreibungssprache (HDL) zur Verfügung gestellt werden. Die Basiskomponenten müssen darin gekennzeichnet und beschrieben werden. Die semiformale Darstellung von technischen oder technologischen Eigenschaften, die ein Teil von sicherheitsspezifischen Funktionen des EVG sind, könnte in Form aussagefähiger graphischer Darstellungen oder bereits in Form von Layoutplänen zur Verfügung gestellt werden. Januar

10 3. Realisierung der sicherheitsspezifischen Funktionen durch die Sicherheitsmechanismen (ITSEC, En.9, n >1) Werden zur Realisierung von sicherheitsspezifischen Funktionen Sicherheitseigenschaften verwendet, die aufgrund besonderer Design- oder Layoutvorgaben oder durch Anforderungen an die Technologie entstehen, so müssen diese Anforderungen in ausreichender Präzision in Zusammenhang mit den betroffenen Komponenten, Schnittstellen oder Mechanismen beschrieben werden. Dies ist insbesondere für die spätere Wirksamkeitsanalyse von Bedeutung. 4. Beschreibung der Mechanismen der Sicherheitsfunktionen Die Mechanismen logischer Funktionalitäten können in ähnlicher Weise beschrieben werden, wie es bei einem Software-EVG erforderlich ist. Sind technische und technologische Eigenschaften Bestandteil der spezifizierten sicherheitsspezifischen Funktionen eines EVG, so ist die Wirkungsweise der technischen und technologischen Eigenschaften im Betrieb des EVG im Sinne einer Mechanismenbeschreibung zur Verfügung zu stellen Implementierung Die nach den ITSEC vorzulegende Testdokumentation muß für die E-Stufen ab E3 die Logikpläne beinhalten. Layoutpläne werden zur Überprüfung der Korrektheit der Implementierung technischer und technologischer Eigenschaften gefordert. Für spätere Analysen kann die Vorlage von Maskenplänen in bestimmten Fällen zusätzlich von Bedeutung sein. Das Layout ist ein Hinweis dafür, ob physikalische Angriffe leicht möglich sind und wie leicht beispielsweise die Metallisierungsschicht zugänglich ist. Für die Durchführung der Tests sind die IC- Datenblätter von besonderer Bedeutung. Die Ausführungen in ITSEC-JIL, Kap. 7.2 sind entsprechend anzuwenden, d.h. daß zur Prüfung der Abbildbarkeit des Feinentwurfs auf die Implementierung, zur Durchführung zusätzlicher Tests, zur Überprüfung der Abwesenheit funktionaler Eigenschaften und zur Überprüfung der Testabdeckung die Hardware-Unterlagen sowie HDL-Unterlagen zu verwenden sind. Der Evaluator muß in der Lage sein, die Tests des Herstellers zu wiederholen und eigene Tests durchzuführen. Für die Durchführung der Tests benötigt der Evaluator i.d.r. Testvektoren, die den Testablauf bestimmen. Falls erforderlich, muß der Evaluator die Möglichkeit haben, die vom Hersteller verwendeten Tools zur Evaluation einzusetzen. In vielen Fällen wird dies aufgrund der erforderlichen Tools nur im Entwicklungslabor oder in der Produktion beim Hersteller möglich sein. In diesen Fällen ist es ausreichend, wenn der Evaluator die Tests beim Hersteller begleitet. Korrektheitstests können auf der Ebene des Entwurfs auch mit Hilfe der HDL-Tools durchgeführt werden. Außer funktionalen Tests unter Standardbedingungen sind auch Tests (ggf. Echtzeittests) unter definierten Streßbedingungen (Temperatur, Frequenz, Spannung, E 2 PROM-Zyklen Test usw.) vorzusehen, da solche Bedingungen im Betrieb des EVG auftreten können (vergleichbar mit Extremsituationen bei Software-EVGs, die dort zu Laufzeitfehlern führen können). Tests einzelner Komponenten des EVG oder die Kontrolle bestimmter technischer oder technologischer Eigenschaften können möglicherweise nur zu einem bestimmten Zeitpunkt im Produktionsprozess oder nur im sog. Testmodus durchgeführt werden, da auf die jeweiligen physischen Komponenten nach Abschluß der Produktion des EVG weder logisch noch physi- 10 Januar 1999

11 kalisch zugegriffen werden kann. Dies ist bei der Testplanung zu berücksichtigen und entsprechend zu dokumentieren. 1. Die Testdokumentation muß Testpläne, Testziele, Testverfahren und Testergebnisse enthalten(e1-e4) Testplan: Ein Testplan legt das Gerüst der Testfälle fest. Im Testplan ist die genaue Spezifikation und Abgrenzung der Testfälle sowie die Dokumentation aller Eingangs- und Umgebungsparameter für den Chip von großer Bedeutung. Diese Parameter sind in den Datenblättern teilweise angegeben. Daher muß das Datenblatt Bestandteil der Testdokumentation sein. Die Testfälle können für analoge und digitale Schaltkreise unterschiedlich sein. Testparameter müssen in der Testplanung berücksichtigt werden und können z.b. sein: Testfrequenzen mit Minimal- und Maximalgrenzen Versorgungsspannung entsprechend dem Datenblatt Testtemperaturen Testvektoren zur Selektion der Testbereiche im IC. Ebenso muß das für einen Testfall notwendige Equipment mit allen Einstellungen genau spezifiziert werden. Dazu zählen auch die genaue Identifikation der Testbibliotheken zur Simulation sowie die Treiberprogramme für das Testequipment. Testziel: Das Testziel ist, die Korrektheit der Logik durch Simulation mittels HDL-Tools nachzuweisen und die Korrektheit der Implementierung zu prüfen. Da ein Test zur Qualitätssicherung beiträgt, muß nach der Simulation nachgewiesen werden, ob die Implementierung gelungen ist. Einzeltests am fertigen Chip müssen zeigen, daß die Implementierung der Sicherheitsfunktionen und Mechanismen korrekt ist und die Timing-Anforderungen erfüllt werden. Bei den Tests der Mechanismen ist das Zusammenwirken der Komponenten besonders zu betrachten, insbesondere dann, wenn Funktionen parallel ablaufen. Wenn der Hersteller auf die Simulation mittels HDL-Werkzeuge verzichten möchte, müssen alle Tests in Echtzeit durchgeführt werden, um nachzuweisen, daß die Implementierung korrekt ist. Testverfahren: Testverfahren ist die Realisierung des Testplans mit den vorgesehenen Testvektoren. Falls einige Logikteile oder Speicherbereiche gesperrt werden sollen, muß dies auf jeden Fall dargelegt oder beschrieben werden. Ab E3 sollte beispielsweise auch die Methodik des Fusens, das u.a. zur Deaktivierung von Testhardware oder für den Übergang vom Test- bzw. Initialisierungsmodus in den Betriebsmodus erforderlich ist, detailliert beschrieben werden, damit im Rahmen der Wirksamkeitsprüfung der Widerstand gegen Angriffe beurteilt werden kann. Wenn Funktionalitäten in Form von technischen oder technologischen Eigenschaften implementiert sind, kann es sinnvoll sein, den Nachweis einer Eigenschaft nicht nur durch funktionale Tests zu erbringen, sondern das Vorhandensein einer speziellen technischen oder technologischen Design-Anforderung durch Analyse des Designs zu verifizieren (z.b. durch optische Überprüfung). Januar

12 Testergebnisse: Testergebnisse, die auf speziellem Testequipment erzielt werden, müssen in auswertbarer Form dargestellt werden (Analogtests, Timingtests). Bei Tests zu parallel ablaufenden Funktionen ist eine Zuordnung der Ergebnisse zu den einzelnen Basiskomponenten, sicherheitsspezifischen Funktionen und Mechanismen von Bedeutung. Abhängigkeiten der Ergebnisse der Tests von der Parallelverarbeitung der Funktionen sind zu erläutern. 2. Die Bibliothek von Testprogrammen muß Testprogramme und -werkzeuge enthalten, mit denen alle Tests, die in der Testdokumentation beschrieben sind, wiederholt werden können (E1-E4) Für das Testen der Chips wird i.d.r. eine Treibersoftware mit dem dazugehörigen Equipment (Tester) benötigt. Dies ist auch notwendig für die Wiederholung der Tests. Andere Werkzeuge, wie Logikanalysator, Oszilloskop, Debugger, Betriebssystem usw., die eingesetzt wurden, müssen ebenfalls angegeben werden. 3. Die Zuordnungsbeschreibung muß die Übereinstimmung zwischen Quellcode bzw. Hardware-Konstruktionszeichnungen und den Basiskomponenten des Feinentwurfs beschreiben (E3-E4) Hardware-Konstruktionszeichnungen bei einem IC sind Logikpläne und die Layouts (vergl. auch Feinentwurf). Die Zuordnung der Basiskomponenten des Feinentwurfs zu Logikplan und Layout muß beschrieben werden. Werden Maskenpläne vorgelegt, so müssen diese in die Zuordnungsbeschreibung einbezogen werden. 4. Die Testdokumentation muß eine Begründung enthalten, warum die gewählte Testabdeckung ausreicht (E4) Eine angemessene Testabdeckung (ITSEM, ) ist erreicht, wenn alle Anweisungen (E3/E4) und Verzweigungen (E4) des gesamten Logikplans ("Quellcodes"), die zu einer sicherheitsspezifischen und sicherheitsrelevanten Basiskomponente gehören, getestet wurden. Bei Simulationen auf Entwurfsebene mittels HDL muß mindestens jedes Statement des HDL-Codes sicherheitsspezifischer Anteile getestet worden sein. Die Korrektheit der Implementierung (Integration) und die Testabdeckung muß noch zusätzlich nach der Produktion nachgewiesen werden. Die Testvektoren müssen entsprechend gewählt werden, damit sie die o.g. Anforderung (E3 oder E4) vollständig abdecken. Es sind Analysen durchzuführen, um dies zu belegen. Die Begründung für die Testabdeckung, die ab E4 vom Hersteller gefordert wird, kann entsprechend einer der folgenden Punkte erfolgen: Der Hersteller kann, wenn möglich, zeigen, daß er jeden Knoten einer Basiskomponente beim Testen einmal getoggelt hat. Wenn entsprechend dem Logikplan die Basiskomponenten oder Teile der Basiskomponenten nur parallel getestet werden können, muß der Hersteller zeigen, daß alle Knoten durch die zugrundeliegenden Testvektoren mindestens einmal getoggelt wurden. 12 Januar 1999

13 Wenn der Designer die Testbarkeitsregeln (Auftrennen, Beeinflussen, Sichtbarmachen) nicht beachtet hat oder das Testen einiger Basiskomponenten nicht ohne weiteres möglich ist (Testen eines Timers über 24 Stunden), kann der Schaltkreis nicht 100 % getestet werden. In diesem Fall ist die Testabdeckung auch erreicht, wenn der Hersteller zeigen kann, daß alle Knoten durch die Testvektoren erreicht wurden und es keine Zustände gibt, die die Sicherheit kompromittieren. Bezüglich der Testabdeckung ist auf die Einbeziehung der durch Design oder Technologie erzielten Sicherheitsfunktionen zu achten. Werden im Betrieb des EVG externe HW- oder SW-Funktionalitäten dynamisch in den funktionalen Ablauf einbezogen, so ist das Verhalten der externen Komponenten auf der Ebene der externen Schnittstelle zu testen. 5. Zusätzlich sind Tests zur Fehlersuche durchzuführen (E2-E4) Die zusätzlichen Tests des Evaluators müssen auf der Ebene des Feinentwurfs und der Logikpläne (Quellcodes) und des Layouts durchgeführt werden (E3-E4). Die Evaluatoren müssen die zusätzlichen Tests auch an einem fertigen IC (final part) durchführen, weil ein Fehler technologiebedingt sein kann und man ihn mit einer logischen Prüfung nicht abdecken kann (z.b.: siehe Alterungsprozess in Kap ), die Streuung der sicherheitsspezifischen und -relevanten Parameter nicht durch eine Simulation getestet werden kann. Solche Streuungen können nur durch Tests mehrerer ICs durchgeführt werden. Dazu muß der Evaluator eine geeignete Stichprobe auswählen oder auf die Ergebnisse der Qualitätskontrolle des Herstellers zurückgreifen. Beispielsweise kann die Streuung eines Digitalisierungsfehlers nur detektiert werden, wenn mehrere ICs getestet werden, oder das Zusammenfügen der Basiskomponenten kann zu einem abweichenden Timing führen Konfigurationskontrolle Konfigurationskontrollsystem und Abnahmeverfahren sind im gesamten Entwicklungs- und Produktionsprozess des EVG zu berücksichtigen. Sie müssen in der Lage sein, neben allen relevanten Dateien aller Entwicklungsschritte auch Konstruktionspläne und Hardwareteile zu verwalten. Ggf. sind auch verschiedene Entwicklungs- und Produktionsorte einzubeziehen. Der EVG muß gemäß ITSEC En.15, n>1, eindeutig identifizierbar sein. In bestimmten Fällen kann es jedoch, um einen Angriff zu erschweren, erforderlich sein, daß die Kennzeichnung des ICs (oder des Chip innerhalb eines IC) mit Logos oder IDs nicht sichtbar erfolgt. In solchen Fällen muß der Hersteller jedoch eine geeignete verdeckte Möglichkeit der Kennzeichnung des EVG, wie zum Beispiel in einem nicht löschbaren zugriffsgeschützten Speicherbereich, finden. Entsprechend ITSEC-JIL, Kap sind in der Konfigurationsliste ab E2 auch alle Teile aufzuführen, die zu einer Änderung am EVG führen können. Ebenso sollen alle Teile aufgeführt werden, die für die Erzeugung und das Testen des EVG notwendig sind. Dies schließt alle bei Tests verwendeten Testeinrichtungen, Bibliotheken und die Liste der Testvektoren ein. Die Identifizierung und Auflistung von Basiskomponenten in der Konfigurationsliste ist i.d.r. bei ICs schwierig umsetzbar. Da im Rahmen des Designs Funktionsblöcke aus einer HDLoder CAD-Bibliothek des Entwicklers und aus einer Technologiebibliothek (Liste der Technologieparameter) des IC-Herstellers entnommen werden, müssen mindestens die verwende- Januar

14 ten Bibliotheken zusammen mit möglicherweise verwendeten Parametern eindeutig identifizierbar sein, wenn die einzelnen Komponenten der Bibliothek keinen eigenen Identifier besitzen. Wenn das Hardware-Design rechnerunterstützt durchgeführt wird, liegen die Designunterlagen in Form von Dateien vor. Eine werkzeugunterstützte Konfigurationskontrolle kann auf jeden Fall auf Dateiebene erfolgen, wie es i.d.r. auch in SW-Entwicklungsumgebungen durchgeführt wird. Alle relevanten Dateien aller Entwicklungsschritte müssen zwecks Reproduzierbarkeit einbezogen werden. Die E4-Anforderung an den Evaluator, ausgewählte Teile des EVG neu zu montieren, hat das Ziel, die Wirksamkeit des Konfigurationskontrollsystems im Hinblick auf verschiedene Versionsstände und Änderungen am EVG zu prüfen. Diese "Neumontage" des EVG ist unter Verwendung der entsprechenden Design-Tools (HDL-, CAD-Tools) unter der Kontrolle des Konfigurationskontrollsystems möglich. Es ist nicht möglich, diese Anforderung unmittelbar auf den technologischen Prozess eines kundenspezifischen ICs zu beziehen, da der Prozess nicht für den Evaluator neu durchlaufen werden kann. In diesem Fall muß der Evaluator jedoch die Konfigurationskontrolle im technologischen Prozess auditieren, um sicherzustellen, daß die korrekten Masken, die zu einer bestimmten Version des EVG gehören, verwendet werden und organisatorische Maßnahmen im Prozess greifen. Bei programmierbaren Standard-ICs (PLD, FPGA), in die die Hardware-Schaltung als Firmware einprogrammiert wird, kann die Anforderung der "Neumontage" jedoch durch Programmierung eines neuen IC umgesetzt werden und der Evaluator dann das neu programmierte IC funktional in einer Testschaltung mit dem Original EVG vergleicht (vergleichbar mit einem File-compare bei einem neu montierten Software-EVG) Programmiersprachen und Compiler Der Prüfaspekt Sprachen und Compiler ist entsprechend ITSEC 4.25 explizit auf Software und Firmware ausgerichtet. Dennoch ist es sinnvoll und auch möglich, diesen Aspekt in Analogie auf Hardware-EVGs und hier speziell auf ICs anzuwenden. Gemäß ITSEC En.18/19/20 (n>2) geht es bei Sprachen und Compilern für Software-EVGs um eine Prüfung, ob die eingesetzten Implementierungssprachen klar und eindeutig definiert und dokumentiert sind und ob alle Optionen der Sprache und ab E4 auch die verwendeten Optionen der Compiler dokumentiert sind. Ziel ist hier neben der höheren Vertrauenswürdigkeit in die korrekte Implementierung des EVG, auch die Reproduzierbarkeit der Konstruktion des EVG sicherzustellen. Um bei Hardware-EVGs das von den ITSEC beabsichtigte Ziel zu erreichen, ist es notwendig, die im Hardwarebereich verwendeten Beschreibungssprachen (HDL), Darstellungselemente (grafische Logikelemente) und Werkzeuge (HDL-Compiler, Simulations-Tools, CAD-Tools) im Hinblick auf die klare und eindeutige Definition und auf die verwendeten Optionen hin zu dokumentieren und zu prüfen. Bei Software können bei gleicher Funktionalität des EVG, d.h. bei gleichem logischen Design, unterschiedliche Compiler unterschiedlichen Objektcode erzeugen. Die Funktionalität ist durch die Prozessorbefehle und die verwendeten Compileroptionen bestimmt. Bei Mikrochip-ICs können bei gleicher Funktionalität, d.h. bei gleichem logischen Design auf Schaltplanebene, aufgrund unterschiedlicher Technologien unterschiedliche Masken und damit unterschiedliche physikalische Implementierungen entstehen. Die Funktionalität ist erst 14 Januar 1999

15 durch die im Silizium implementierte Zellstruktur bestimmt. Aus diesem Grunde müssen ab ITSEC-Stufe E3 die für die Implementierung des Chips verwendete Technologie und ab E4 auch die eingestellten Prozessparameter eindeutig angegeben werden. Zur Verdeutlichung werden in der folgenden Tabelle die Entwicklungsprozesse von Hardware und Software gegenüber gestellt: Software Programmtexteingabe per Editor zur Erstellung des Sourcefiles. Syntax und Semantik der Eingabesprache wird durch den Compiler bestimmt. Um einen funktionsfähigen Software-EVG zu erstellen, benötigt man mehrere Schritte: Festlegung der Compiler- und Linkereinstellungen, um z.b. bestimmte Optimierungsmöglichkeiten zu realisieren. Compilieren und Linken der Sourcefiles zu einem von einem Prozessor ausführbaren Programm während seiner Laufzeit (Objektfiles als Programmdatei, Laufzeitbibliothek, Programmiercode für einen Hardwarespeicher). Test und Debugging im Rahmen der Compilierung einzelner Sourcefiles sowie des gesamten EVG. Hardware Erstellung des Logikplans durch graphische Eingabe mittels eines CAD-Tools oder textuelle Eingabe mittels eines HDL-Editors. Syntax und Semantik der Graphiksymbole sind durch die CAD-Tools und die Technologie bestimmt. Zur Modellierung und Simulation des Schaltungsdesigns wird i.d.r. eine HDL verwendet. Um einen funktionsfähigen Mikrochip aus den Zeichnungen zu erstellen, benötigt man mehrere Schritte: Erstellung der Netzlisten aus den Logikplänen und Synthese der Gatterstruktur sowie der Teststrukturen. Simulation dieser Logik auf Gatterebene und auf Layoutebene unter Verwendung der Timingvorgaben. Erstellung des Layouts und der Masken. Produktion des Mikrochips aus diesen Masken nach mehreren Prozessschritten, die von der verwendeten Halbleitertechnologie abhängig sind (z.b. 0,8 µm CMOS-, BiCMOS- oder Bipolar-Technologie). Eine verwendete Programmiersprache basiert auf den Möglichkeiten, die ein Compiler, Interpreter oder Assembler bieten, während die durch HDL erstellte Logik erst nach Abschluß des technologischen Prozesses abschließend vorliegt. Daher muß der Titel dieses Prüfaspektes im Sinne von "Sprachen, Werkzeuge und Technologie" verstanden werden Sicherheit beim Entwickler Die geplanten Schutzmaßnahmen bzgl. der Integrität des EVG und der Vertraulichkeit der Dokumentation sind entsprechend der ITSEC-Anforderung En.21 (n>1) zu dokumentieren. Entsprechend ITSEC-JIL, Kap. 8 und Kap. 16 ist auch die Produktion des EVG in die Betrachtung einzubeziehen, so daß die ITSEC-Anforderung für alle Entwicklungsphasen bis zur Auslieferung des fertigen EVG gilt. Dies ist insbesondere deshalb von Bedeutung, weil Januar

16 ein IC vom Design bis zur Auslieferung sehr unterschiedliche Phasen und Orte durchläuft, weil die Anforderungen an die Technologie erst in der Produktion der ICs umgesetzt werden und Tests auch im Rahmen der Produktion zum Einsatz kommen (z.b. Wafertests). Weiterhin sind in die nach ITSEC En.23 (n>1) geforderte Überprüfung vor Ort gemäß ITSEC 4.23 und ITSEC-JIL, Kap Entwicklungs- und Produktionsstandorte des EVG einzubeziehen. Im Zuge der Entwicklung und Produktion eines Mikrochips gibt es mehrere solche sensible Bereiche: Entwicklung (Erstellung der Logikpläne, Layout, Masken und Zeichnungen) Maskenerstellung Prozesskontrolle (Integration der Schaltung auf Silizium in der Produktion) Produkt-Engineering (Fehleranalyse im Produktionsprozess) Produktion und Tests (Fertigung und Tests der Sicherheitsfunktionalität) Assembly und Tests (falls notwendig, z.b. Bonding auf eine Chipkarte) Qualitätskontrolle der Sicherheitsfunktionalität Lagerung / Auslieferung. Der EVG liegt in den verschiedenen Stadien der Entwicklung und Produktion in unterschiedlichen physischen Ausprägungen vor. Die Integrität der Layout-Masken ist hier von besonderer Bedeutung. Materielle, organisatorische, personelle und andere Maßnahmen, die zur Realisierung von in den Sicherheitsvorgaben genannten Sicherheitseigenschaften des EVG notwendig sind, in der Entwicklung und Produktion umgesetzt werden und sich auf die Sicherheit in der Betriebsphase des EVG auswirken, sind ebenso zu dokumentieren und zu überprüfen. Hier spielen insbesondere Maßnahmen in der Testphase / ggf. Assemblyphase und Maßnahmen zur Steuerung des Produktionsprozesses eine Rolle. Im Vergleich dazu findet bei einem Software-EVG die Compilierung mit festgelegten Optionen einmalig in der Entwicklungsumgebung statt (Prototyp und Masterkopie). Die Serienproduktion der Software ist i.d.r. lediglich ein Kopiervorgang, bei dem Integritätsaspekte der Kopie bezogen auf die Masterkopie eine Rolle spielen. Bei Mikrochips als EVG werden im Rahmen der Entwicklung Zeichnungen und zugehörige Dateien erstellt. Die Chip-Produktion sowohl des Prototypen als auch der Serie ist wesentlich komplexer als ein Kopiervorgang bei Software und ist durch eine Vielzahl von Prozessparametern variierbar und damit auch durch das Bedienpersonal manipulierbar. Die Testphase bei der Produktion ist von besonderer Bedeutung, da ein Mikrochip in dieser Phase zwar schon physisch vollständig vorliegt, Chip-interne Strukturen aber beispielsweise über einen zu diesem Zeitpunkt noch aktivierten Testmodus ausspähbar oder sogar beeinflußbar sind. Maßnahmen, die getroffen werden, um fehlerhafte Dice auf dem Wafer im Rahmen der Produktionstests kenntlich zu machen (inken) und fehlerhafte EVGs (final parts) auszusortieren, einschließlich der Angaben zu den Aussortierungskriterien, können von Bedeutung sein. Das Verfahren zur Vernichtung fehlerhafter Teile ist vom Hersteller zu beschreiben. 16 Januar 1999

17 3.2.8 Benutzerdokumentation Der Hardware-Designer als Benutzer des EVG, der den IC in einer Baugruppe implementiert oder in einer Applikation verwendet, benötigt Angaben über den Chip und seine Sicherheitseigenschaften im Sinne der Sicherheitsvorgaben, um die Sicherheitspolitik korrekt umsetzen zu können. Ein Endbenutzer hat keinen unmittelbaren Kontakt zur Chiphardware, sondern benutzt den Chip im Rahmen einer Applikation. Demzufolge ist keine Dokumentation der Sicherheitseigenschaften der Hardware für diesen Endbenutzer notwendig. Die Informationen für einen IC-Anwender sind gewöhnlich in einem technischen IC-Datenblatt zu finden (Beschreibung der Funktionalität, Pin-Konfiguration, Timing-Diagramme, ggf. Programmierrichtlinien...). Für eine sichere Anwendung des EVG ist es notwendig, entsprechend der ITSEC-Anforderung En.25, Angaben zu den Sicherheitseigenschaften, spezielle Applikationshinweise im Sinne der Sicherheitspolitik und Hinweise zum Einsatz der sicherheitsspezifischen Funktionen zu dokumentieren Systemverwalter-Dokumentation Ob eine entsprechende Dokumentation notwendig ist, entscheidet sich im Einzelfall. Zur Systemverwaltung gehört eine möglicherweise notwendige Personalisierung des IC. Dazu benötigt man eine geeignete Dokumentation, die es ermöglicht, alle kontrollierbaren Sicherheitsparameter und sicherheitsrelevanten Ereignisse zu administrieren. In den meisten Fällen verläßt der Mikrochip den Hersteller mit allen Einstellungen, die die Sicherheit betreffen, ohne daß eine Änderung dieser Einstellungen notwendig oder sogar möglich ist Auslieferung und Konfiguration Die Interpretationen in ITSEC-JIL, Kap. 10 und die Liste der Auslieferungsverfahren der nationalen Zertifizierungsstelle sind zu beachten. Die ab E2 bestehende Anforderung zur Dokumentation der Verfahren zur Generierung des EVG (gemäß ITSEC-JIL, Kap. 16 als Installation zu betrachten) ist für ICs i.d.r. nicht anwendbar, da EVGs dieser Art nicht installiert werden müssen. Entsprechend ITSEC En.32 muß, wenn unterschiedliche Konfigurationen möglich sind, die Auswirkung der einzelnen Konfigurationen auf die Sicherheit dargelegt werden. Konfigurationen des EVG könnten bestimmte Modi wie Test- und Betriebsmodus oder eine Auswahl einer bestimmten Option durch eine Programmierung des Chips sein. Die Funktionalitäten zur Deaktivierung von Testhardware oder zum Übergang vom Test- bzw. Initialisierungsmodus in den Betriebsmodus sind Aspekte, die die Sicherheit im Kontext der Schwachstellenanalysen und die Authentizität des ausgelieferten EVG betreffen und beschrieben werden müssen. Sofern im Rahmen der Auslieferung des EVG Tests sicherheitsrelevanter Funktionalitäten erforderlich sind, müssen die Ergebnisse dieser Tests dokumentiert werden. Dies muß Bestandteil des Auslieferungsverfahrens sein. Ebenfalls muß beachtet werden, daß alle Verfahren, die auf dem Weg vom Entwicklungs-/Designzentrum bis zum Endkunden einschließlich der Produktionsstätten Anwendung finden, zu beschreiben sind. Für die nach ITSEC En.34 (n>1) geforderte Überprüfung der korrekten Anwendung der Auslieferungsverfahren im Rahmen der Aufgaben des Evaluators ist eine Überprüfung der Prozeduren und Standards auf dem gesamten Weg vom Entwicklungs-/Designzentrum bis zum Endkunden notwendig. Januar

18 Anlauf und Betrieb Gemäß ITSEC En.35 müssen die Prozeduren für einen sicheren Anlauf und Betrieb dargelegt werden. Für einen sicheren Anlauf ist ein sicherer Anfangszustand des Chips zu gewährleisten. Dies muß ab E2 durch Diagnoseprozeduren für alle sicherheitsspezifischen Hardwarekomponenten erfolgen (z.b. Power-On-Reset Prozedur). Eine korrekte Einstellung aller Betriebsparameter ist notwendig. Zum Nachweis der Ergebnisse von Diagnoseprozeduren nach ITSEC En.36 (n>1) handelt es sich um die Beschreibung von Signalzuständen an den externen Schnittstellen des EVG oder um die Beschreibung von im Chip gespeicherten und an den externen Schnittstellen des EVG bereitgestellten Statusinformationen. Die ab E4 geforderten Verfahren, um den EVG nach Fehlern im Betrieb in einen sicheren Zustand zurückzuversetzen, werden bei Mikrochips meist durch definierte Reset-Bedingungen, z.b. nach der Erkennung von Spannungseinbrüchen, zur Verfügung gestellt. Wenn im Kontext der angenommenen Bedrohungen die Möglichkeit besteht, daß Angriffe auf einen EVG auch dann noch erfolgreich sein können, wenn dieser bereits außer Betrieb ist, so ist die Phase der Beendigung der Nutzung des EVG in die Evaluation einzubeziehen (z.b. der Einzug und die Vernichtung eines Chip oder das Wiederaufbereiten von Speicherbereichen im Chip). 3.3 Vertrauenswürdigkeit Wirksamkeit Eignung der Funktionalität Die Analyse der Eignung der Funktionalität muß neben den logischen Sicherheitsfunktionalitäten des EVG auch die technischen und technologischen Eigenschaften berücksichtigen, sofern sie in den Sicherheitsvorgaben des EVG definiert sind. Es muß gezeigt werden, welchen Bedrohungen (umsetzbar durch bestimmte Angriffsszenarien) durch die Sicherheitsfunktionen der unterschiedlichen Typen und durch die Mechanismen geeignet entgegengewirkt wird. Bei der Beschreibung von Angriffsszenarien sind technische Randbedingungen der Spezifikation, wie Temperatur, Spannung und Frequenz, zu berücksichtigen. Ebenso können Szenarien zu physikalischen Angriffen auf die Hardware von Bedeutung sein, wenn diesbezüglich Bedrohungen angenommen werden Zusammenwirken der Funktionalität In die Analyse des Zusammenwirkens fließen Architekturmerkmale des EVG mit ein. Hier sind insbesondere von Bedeutung: physikalische Verbindungen zwischen physischen Komponenten in Form von Signalwegen oder Leitungen physikalische Verbindungen zwischen physischen Komponenten aufgrund des Layouts, d.h. daß Informationen zur technischen und technologischen Implementierung in die Analyse mit einfließen müssen dynamische Verflechtungen im Zeitverhalten einzelner Sicherheitsfunktionen oder Mechanismen Beeinflussung des Zusammenwirkens durch Anlegen externer Signale an den Mikrochip. 18 Januar 1999