Safety & Security
Kontextbasierter Schutz per MCU
Fortsetzung des Artikels von Teil 2
Anwendungsbeispiel
Die beschriebenen Schutzmaßnahmen können nun dazu verwendet werden, um ein HSM zu implementieren (Bild 3). Ein HSM ist eine Security-Komponente, mit der zum Beispiel sensible Daten aufbewahrt oder Nachrichten authentifiziert und verschlüsselt werden können. Eine entscheidende Voraussetzung dafür ist der Secure-Boot-Mechanismus, der die Echtheit und Unverfälschtheit der ausgeführten Software garantiert. Dabei werden Teile der Software nur dann ausgeführt, wenn zuvor ihre Authentizität mittels geeigneter kryptografischer Funktionen (Digitale Signaturen) überprüft worden ist. Beginnend mit einem Reset, beispielsweise nach dem Einschalten, wird zunächst der ROM-Code ausgeführt. Dieser ist unveränderlich und bildet somit die Wurzel der Vertrauenskette. Der ROM-Code stellt zuerst Integrität der durch Hersteller und gegebenenfalls durch Kunden vorgenommenen Device-Konfiguration fest. Anschließend wird der nächste, durch Kunden programmierbare HSM-Bootloader authentifiziert und ausgeführt. Dieser wiederum kann den HSM-Code authentifizieren.
Ein erster Schritt des HSM ist nun, Schutzkontexte zu definieren und die Schutzeinheiten zu konfigurieren, um die für korrekte Funktion benötigten Hardware-Komponenten zu allokieren und diesen vertrauenswürdigen Bereich von anderen Ressourcen im System zu trennen. Bild 4 zeigt das Blockschaltbild einer typischen MCU samt einer beispielhaften Allokation der Hardware-Module durch HSM. »Allokation« in diesem Fall bedeutet eine entsprechende Konfiguration der Speicher- und Peripherieschutzstrukturen, die einen exklusiven Zugriff für HSM garantiert und gleichzeitig Zugriffe von außerhalb blockiert. Dies wird erreicht, indem das HSM einen (oder mehrere) Schutzkontext(e) erhält, dessen Verwendung durch andere Master im System ausgeschlossen ist.
Es gibt im Allgemeinen drei Kategorien der durch HSM verwendeten Hardware-Ressourcen: vollständig allokierte, partiell allokierte und optional allokierte. Bei der ersten Kategorie handelt es sich um Hardware-Module, die exklusiv durch HSM verwendet werden, zum Beispiel der Beschleuniger für kryptografische Operationen und eine der CPUs (hier Arm Cortex M0+), die als Secure CPU agiert. Zu der zweiten Kategorie gehören Hardware-Module, die nur zu einem bestimmten Anteil vom HSM genutzt werden. Das sind primär Speicher (RAM, Code- und Data-Flash). Dabei sind von der MCU-Architektur keine Einschränkungen bezüglich der Aufteilung vorgegeben. Das heißt, dass die Größe des dem HSM zur Verfügung stehenden Speichers beliebig gewählt werden kann.
Die dritte Kategorie umfasst Hardware-Module, die je nach Anwendung vom HSM allokiert werden können. So ist es unter anderem möglich, ein oder mehrere Kommunikationsinterfaces (SPI, Ethernet etc.) zu verwenden, um sichere Kommunikation zu ermöglichen. Des Weiteren ist es möglich, die Kontrolle über Clock- und Power-Konfiguration für die gesamte MCU in die HSM-Domäne zu verschieben, um entsprechende Manipulationen zu verhindern oder mittels Clock Supervision und High/Low Voltage Detection Modulen zu detektieren (Tamper Protection/Detection).
Nachdem die vertrauenswürdige Laufzeitumgebung (Secure Domain) installiert ist, kann die eigentliche Benutzerapplikation durch HSM authentifiziert und gestartet werden. Die Applikation kann sich selbst nur Rechte zuweisen, die ihr durch das HSM zugestanden werden. Eine Änderung der Konfiguration der allokierten Schutzstrukturen ist nicht möglich. Die Benutzerapplikation kann sich jedoch in mehrere Partitionen mit eingeschränkten Rechten aufteilen, um Interferenzfreiheit für Safety-Funktionen sicherzustellen und den Schutz von Geheimnissen zu gewährleisten.
| Zuerst gesehen |
|---|
| Dieser Beitrag stammt aus der Medizin+elektronik Nr. 1 vom 04.02.2019. Hier geht’s zur vollständigen Ausgabe. |
- Kontextbasierter Schutz per MCU
- Schutzeinheiten
- Anwendungsbeispiel
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
