Mikrocontroller mit SCE Zertifizierte Security-Subsysteme – eine Frage des Vertrauens

Anbieter zum Thema

ISH Ingenieursozietät GmbH

NetModule AG

Apacer Technology B.V.

Renesas Electronics Europe GmbH

Mikrocontroller mit integrierten Security-Funktionen sollen Entwickler beim Design sicherer Systeme und Applikationen unterstützen – doch wer stellt sicher, dass diese Funktionen korrekt implementiert sind?

Renesas Electronics entwickelt und fertigt Mikrocontroller-Bausteine wie die RA-Familie mit integrierten, hochentwickelten Security-Funktionen und unterstützt Anwendungsentwickler damit bei der Realisierung ihrer Security-Ziele.

Dabei bleibt eine grundsätzliche Frage: soll der Entwickler implizit darauf vertrauen, dass der Hersteller alles richtig implementiert hat, oder fordert er einen Nachweis?

Bildergalerie

Dieser Artikel befasst sich mit der Problematik der Security-Zertifizierung und damit, wie Renesas seinen Kunden hilft, ihre Ziele in kürzester Zeit zu erreichen, um ihre Produkte auf den Markt zu bringen.

Jedes vernetzte Gerät benötigt eine Kommunikationsschnittstelle zum Senden und Empfangen von Benutzerdaten, zur sicheren Speicherung dieser Daten auf dem Gerät sowie für eine abgesicherte Ausführung von Aktualisierungen der Anwendungsfirmware über einen potenziell unsicheren Kanal unter Wahrung der Vertraulichkeit und Integrität der Benutzerdaten. Das Mittel der Wahl dafür ist eine Secure Crypto Engine (SCE), die idealerweise direkt in den Mikrocontroller integriert ist – zum Beispiel das Modell RA6M4 aus einer neuen Generation von speziell auf Security ausgerichteten MCUs von Renesas.

Das durch die SCE definierte sichere Subsystem (Bild 1) bietet als integrierte Lösung eine vergleichbare Secure-Element-Funktionalität mit wesentlich höherer Leistung. Dies senkt die Stücklistenkosten und vereinfacht die Integration in Entwicklung und Produktion. Das Subsystem unterstützt AES, RSA, ECC, Hashing-Algorithmen und eine echte Zufallszahlengenerierung innerhalb einer isolierten On-Chip-Umgebung. Die SCE ermöglicht eine sichere, unbegrenzte Schlüsselspeicherung und nutzt dazu einen vom Hersteller programmierten 256-Bit Hardware Unique Key (HUK), der sich zur Ableitung der Kundenschlüssel verwenden lässt.

Das SCE9-Krypto-Subsystem ist komplett in der MCU integriert und durch einen Access Management Circuit geschützt. Dieses kann bei illegalen Zugriffsversuchen den Betrieb der Krypto-Engine abschalten. Die MCU führt alle kryptographischen Klartext-Operationen über einen eigenen, dedizierten internen Speicherbereich aus, auf den weder die CPU noch ein per DMA erreichbarer Bus Zugriff hat. Die Schlüsselspeicherung und Verwaltung der SCE9 stellt sicher, dass Klartextschlüssel niemals offengelegt oder in einem für die CPU zugänglichen RAM oder nichtflüchtigen externen Speicher abgelegt werden.

Wer garantiert die korrekte SCE-Implementierung?

Theoretisch klingt das gut. Aber soll sich der Entwickler blind darauf verlassen, dass ein Hersteller – in diesem Fall Renesas – alle Algorithmen ordnungsgemäß und normgerecht implementiert hat und der Funktionsumfang mit den Angaben der Spezifikation übereinstimmt? Wohl eher nicht. Wie also löst man dieses Dilemma? Ganz einfach: Mithilfe einer Security-Zertifizierung. Dabei werden die Anforderungen nach dem Vier-Augen-Prinzip anhand einer vereinbarten und standardisierten Testmethodik von einer unabhängigen Organisation nachgewiesen und überprüft.

Doch welche Zertifizierung ist angemessen? Normalerweise gibt es in stark regulierten Branchen Sicherheitsstandards wie PCI für Finanztransaktionen oder die DLMS Security Suite für Zähleranwendungen, IEC-62443 für industrielle Steuerungen und viele weitere. Für die meisten Consumer-Produkte existieren bisher keine spezifischen Sicherheitsvorschriften oder -Anforderungen. Angesichts fehlender Richtlinien haben staatliche Stellen mit der Veröffentlichung allgemeiner Anforderungsprofile begonnen.

In den USA hat das NIST einige Cybersecurity-Richtlinien für IoT-Bausteine und die britische Regierung einen Verhaltenskodex für die IoT-Security im Consumer-Bereich veröffentlicht. Das Konsortium „IoT Security Foundation“ hat ein IoT Security Compliance Framework erstellt. Weitere sollen folgen. Dieser Artikel greift drei dieser Programme beispielhaft heraus.

ARM-PSA: Sicherheits-Framework mit vier Stufen

Die Firma ARM, Anbieter von Embedded-CPU-Cores mit Sicherheitsfunktionen wie TrustZone, verfolgt einen immer beliebteren Ansatz. ARM hat eine PSA-Spezifikation (Platform Security Architecture) mit einem auf vier Stufen beruhenden Sicherheitsframework veröffentlicht: „Analyze, Architect, Implement und Certify“. Das mehrstufige PSA-Zertifizierungsprogramm soll Herstellern von Consumer-Geräten die Gewissheit geben, dass das jeweilige Produkt Sicherheitsrichtlinien einhält, die in der Spezifikation beschrieben sind. Dabei gibt es drei definierte Sicherheitsstufen, die jeweils aufeinander aufbauen und höhere Anforderungen umfassen.

Ergänzend zur PSA-Spezifikation gibt es eine offene und konforme Software-Referenzimplementierung, die sogenannte „Trusted Firmware“. Diese Software ist ein optimaler Startpunkt für Hersteller, die CPU-Technologie von ARM nutzen: Mit ihr können sie die in der PSA-Spezifikation definierten Funktionen integrieren und bereitstellen. Renesas weiß um die Bedeutung der PSA-Initiative und engagiert sich daher für die Zertifizierung seiner Produkte einschließlich der Trusted-Firmware-Plattform gemäß den Anforderungen der PSA-Spezifikation, um diese weiterzuentwickeln. Aktuell ist die erfolgreiche Zertifizierung der ersten Stufe bereits erreicht, die der nachfolgenden Stufen ist in Arbeit und wird in Kürze abgeschlossen sein. Die Ergebnisse aller Zertifizierungen sind auf der Website psacertified.org einsehbar.

NIST definiert Technologien, Messungen und Normen

Eine weitere bekannte Zertifizierung stammt vom National Institute of Standards and Technology. Das NIST definiert Technologien, Messungen und Normen. Diese veröffentlicht das Information Technology Laboratory des NIST in entsprechenden Dokumenten, die in den Federal Information Processing Standards (FIPS) gesammelt werden. Diese Spezifikationen beschreiben Aspekte verschiedener kryptographischer Algorithmen, Protokolle und Funktionen, die man in den USA für Geschäftszwecke als notwendig erachtet. Nach diesen Standards sieht das “Cryptographic Algorithm Verification Program“ Validierungstests für zugelassene (d. h. von FIPS genehmigte und von NIST empfohlene) kryptografische Algorithmen und ihre einzelnen Komponenten vor. Alle erfolgreich getesteten Algorithmen finden Eingang in eine veröffentlichte Validierungsliste.

Diese Zertifizierung garantiert funktionale Richtigkeit und Interoperabilität. Sie beschränkt sich nicht auf den US-amerikanischen Markt, sondern ist weltweit anerkannt und wird von verschiedenen Industriebereichen gefordert oder gewünscht. Muss das fertige Endprodukt eine Zertifizierung durchlaufen, so kann der Nachweis eines CAVP-Zertifikats für die kryptografische Implementierung den Prozess erheblich beschleunigen.

Kryptografischen Blöcke sind oft bereits CAVP-zertifiziert

Renesas hat sich daher verpflichtet, die in seinen SCEs enthaltene Kryptografie-Funktionalität nach Maßgabe des CAVP-Programms zu validieren. Viele der implementierten kryptografischen Blöcke sind bereits CAVP-zertifiziert. Hierzu zählen AES, SHA und der DRBG-Teil des True Random Number Generators. Für die asymmetrische Verschlüsselung stehen sowohl RSA als auch ECC zur Verfügung, die sich derzeit im Prozess der CAVP-Zertifizierung befinden. Das NIST veröffentlicht eine Liste der zertifizierten Module auf seiner Website.

Werfen wir abschließend noch einen Blick auf den Security Evaluation Standard for IoT Platforms (SESIP). Dieser wurde von der GlobalPlatform Alliance veröffentlicht und derzeit beworben. SESIP ist ein Standard für die vertrauenswürdige Security-Bewertung von IoT-Plattformen. Ziel dieser Bewertung ist eine Wiederverwendung, um auch die Anforderungen anderer Produktbereiche zu erfüllen. Dabei werden die gemeinsamen funktionalen Anforderungen für den Chip in SESIP-„Profilen“ wie Arm PSA L1 zusammengefasst. Weitere Mappings für IEC 62443 und andere Standards sind in Arbeit.

Fünf Assurance Level mit verschiedenen Sicherheitsniveaus

SESIP definiert fünf Assurance Levels mit jeweils erhöhtem Sicherheitsniveau. Es beginnt mit einer auf Selbsteinschätzung basierenden Stufe, geht über Black-Box-Penetrationstests (für eine Closed-Source-Plattform), zu einer White-Box-Schwachstellenanalyse (mit einer zeitlich begrenzten Quellcode-Analyse in Kombination mit einem zeitlich begrenzten Penetrationstest), bis hin zu höheren Stufen. Letztere lassen sich als Ergänzung zu einer SOG-IS-Zertifizierung einsetzen, die einige standardisierte Common-Criteria-Assurance-Komponenten und spezifische Mappings umfasst. SESIP basiert passenderweise auf dem Common-Criteria-Zertifizierungsprogramm, das ähnlich aufgebaut ist.

Viele Zertifizierungen teilen die Anforderung, einen Nachweis über den Entwicklungsablauf für sicherheitsbezogene Funktionen zu liefern. In der Entwurfsphase muss also meist ein Sicherheitsplan formuliert werden, der den Rahmen für nachfolgende Phasen setzt. Dazu werden in enger Rückkopplung mit der erforderlichen Bedrohungsanalyse und der Spezifikation der Vorgaben die Sicherheitsfunktionen (in Soft- oder Hardware) definiert, das Design durchgeführt, eine Implementierung vorgenommen, dann überprüft und als Einheit getestet. Anschließend bewertet man die Kenndaten der Implementierung, bevor die sicherheitsrelevante Dokumentation freigegeben und eine abschließende Sicherheitsprüfung durchgeführt wird.

Hersteller muss sich langfristig um das Fehlermanagement kümmern

Alle diese Schritte sind ordnungsgemäß zu dokumentieren und zu protokollieren. Der Hersteller hat folglich einen erheblichen Aufwand für interne Prüfungen und dessen Protokollierung und muss zugleich entsprechend den Anforderungen der Spezifikation interne Richtlinien und Standards anwenden. Die Zertifizierungsstelle bewertet diese Nachweise entsprechend der angestrebten Sicherheitsstufe der Zertifizierung.

Nach der Entwicklung eines bestimmten Produkts und dessen Verfügbarkeit in Serienproduktion muss sich der Hersteller um dessen Lebenszyklus und damit auch um das Fehlermanagement kümmern. Wie bei jedem eventuell auftretenden allgemeinen Funktionsfehler sind auch alle Sicherheitsaspekte als Teil des Produktlebenszyklus zu überwachen und zu verwalten. Eine Schwachstelle lässt sich als eine Sicherheitslücke oder ein Defekt in einem Produkt oder System definieren, die ausgenutzt beziehungsweise böswillig missbraucht werden kann, um die Vertraulichkeit, Integrität und/oder Verfügbarkeit des Produkts oder Systems zu gefährden.

Gefundene Schwachstellen müssen behoben werden

Der Anbieter ist verpflichtet, alle in den Produkten gefundenen Schwachstellen zu beheben. Dazu muss er sie analysieren, verantwortungsvoll offenlegen und notwendige und angemessene Korrekturmaßnahmen durchführen. Externe Parteien stoßen oft erst bei der Evaluierung eines Produktes auf sicherheitsbezogene Probleme. Daher ist eine Kontaktstelle erforderlich, die eine einfache und vertrauliche Meldung dieser Probleme zur weiteren Analyse ermöglicht. Renesas hat zu diesem Zweck ein Product Security Incident Response Team (PSIRT) eingerichtet. Aufgabe dieses Teams ist es, alle Störfälle oder sicherheitsrelevanten Probleme zeitnah zu lösen. Das Team ist unter der Webadresse www.renesas.com/psirt zu erreichen. Über dieses Portal können Kunden und Dritte Renesas kontaktieren, ihre Erfahrungen austauschen und dazu beitragen, bessere Produkte für alle bereitzustellen.

Unter dem Strich gibt es viele verschiedene Security-bezogene Standards, Frameworks und Richtlinien, die für Entwickler auf den ersten Blick sehr herausfordernd erscheinen. Renesas arbeitet kontinuierlich daran, diese Industriestandards und „Best Practices“ zu befolgen, um seinen Anwendern ein exzellentes Qualitätsniveau seiner Produkte, einschließlich der sicherheitsrelevanten Aspekte, zu gewährleisten.

* Giancarlo Parodi … ist Principal Engineer bei Renesas Electronics.

(ID:47576426)