Der Blätterkatalog benötigt Javascript.
Bitte aktivieren Sie Javascript in Ihren Browser-Einstellungen.
The Blätterkatalog requires Javascript.
Please activate Javascript in your browser settings.
20 Elektronik 06 2020 Mikroprozessoren und Ip können und daher sollte kein einziger Funktionsblock in der Lage sein absichtlich oder unabsichtlich die Vertraulichkeit Integrität und Verfügbarkeit CIA Confidentiality Integrity Availability des gesamten Systems zu gefährden Das oben beschriebene Zero-Trust-Modell erfordert eine Hardwaregestützte Trennung zwischen jedem primären Bedrohungsvektor und dem Kern des Systems Wenn die grundlegenden Funktionsblöcke betrachtet werden die typischerweise in eingebetteten verbundenen Geräten vorhanden sind z Bsmarte Sensoren und IoT-Endknoten lassen sich typischerweise die folgenden Elemente identifizieren ➔ 1 Ein Echtzeit-Betriebssystem RTOS auf dem eine Reihe von SoftwareThreads Tasks laufen ➔ 2 Eine Reihe von Sensoren und Aktoren zur Steuerung externer physischer Systeme ➔ 3 Eine Netzwerkschnittstelle die einem Fernangriff ausgesetzt ist ➔ 4 Eine Reihe kryptographischer Algorithmen die zur Sicherung von Daten in Ruhe und in Bewegung und zur Bereitstellung von Aufmerksamkeitsdiensten für einen Host verwendet werden Jedes dieser Elemente enthält wahrscheinlich Code von Drittanbietern Er sollte als nicht vertrauenswürdig eingestuft werden und von den anderen Teilen des Systems isoliert sein Die Implementierung des oben genannten Null-Vertrauen-Modells erfordert mindestens vier verschiedene Blöcke funktionaler Trennung oder Zonen MMUs erlauben nur die Trennung zwischen Nutzerund Kernfunktionen Mehrere dieser Blöcke werden traditionell innerhalb einer monolithischen Infrastruktur zusammengefügt Sie sind daher sehr schwer zu trennen und mit virtuellem Speicher und MMU zu schützen Darüber hinaus basieren traditionelle TEEs auf Hardwareprimitiven TrustZone von Arm ist beispielsweise so konzipiert dass sie nur einen Funktionsblock isoliert Dies wird allgemein als sichere Welt bezeichnet und üblicherweise zur Kontrolle des Zugriffs auf kryptographische Schlüssel und sicherheitskritische Operationen wie z Bsicheres Booten verwendet Das Haupt-RTOS und alle seine Aufgaben laufen in der verbleibenden einzigen nicht sicheren Welt ohne dass ein Mechanismus für eine weitere Trennung übrig bleibt Die inhärente binäre Beschränkung dieser traditionellen Architektur bietet einfach nicht genügend Trennungsebenen für ein modernes Null-Vertrauen-Konzept Armv7-M HardwareSicherheitsprimitive Die Implementierung einer eingebetteten TEE erfordert in der Regel zusätzliche spezialisierte Hardware innerhalb oder außerhalb des Anwendungsprozessors In der Praxis macht dies die TEE-Implementierung sehr schwierig und anfällig für Fehler und Schwachstellen Die Armv7-M-Architektur spezifiziert eine Reihe von Hardware-Sicherheitsprimitiven die die TEEunterstützende Hardware in fast allen Cortex-M-SoCs verfügbar machen Eine erste Gruppe von Sicherheitsprimitiven die in Armv7-M-Kernen verfügbar sind wird durch die Privilegstufen dargestellt Ein Armv7-M-Mikrocontroller läuft jederzeit in einem bestimmten Modus und auf einer bestimmten Berechtigungsstufe Gemäß dem Armv7-M-Architektur-Referenzhandbuch können Cortex-M-Prozessoren in zwei Modi laufen Handlerund Thread-Modus Bild 1 Der HandlerModus ist immer privilegiert der ThreadModus dagegen kann privilegierte und unprivilegierte Zugriffsebenen haben Die Trennung von privilegierten und unprivilegierten Zugriffsebenen ermöglicht die Entwicklung robusterer Systeme Sie bietet einen grundlegenden Sicherheitsmechanismus indem die Speicherzugriffe auf bestimmte Regionen kontrolliert werden Ein zweites integriertes Sicherheitsmerkmal ist die Speicherschutzeinheit MPU Sie ist optional aber in vielen Cortex-M-Prozessoren weit verbreitet Die MPU ist ein programmierbarer Hardware-Block der zur Definition von Berechtigungen für bestimmte Speicherregionen entsprechend den Privilegstufen verwendet werden kann Dies ermöglicht die Partitionierung der Funktionen zwischen Ausführungsumgebungen und dem Missbrauch bestimmter Ressourcen d h die Definition des RAM-Speichers als nicht ausführbar eXecute Never XN um den Missbrauch des Pufferspeichers zu begrenzen und Code-Injection-Angriffe zu verhindern Herausforderungen bei der Implementierung TEEs zielen darauf ab die HardwareIsolation mehrerer Softwarekomponenten innerhalb des Systems durchzusetzen und gleichzeitig die Vertraulichkeit Integrität und Verfügbarkeit also die CIA-Triade zu wahren Eine moderne TEE muss dies gewährleisten ➔ 1 Isolierung von Code Daten Unterbrechungen und anderen Ressourcen ➔ 2 Präventive zeitliche Trennung ➔ 3 Funktionen für trapandemulate für privilegierte Befehle um eine transparente Ausführung von Legacy-Anwendungen zu ermöglichen die nicht so codiert sind dass sie im unprivilegierten Modus sicher laufen Der TEE-Entwickler muss einige besondere Merkmale der Armv7-M-Architektur berücksichtigen einschließlich der MPU-Konfiguration spezielle privilegierte und unpräziser Busfehler Die in den Armv7-Cortex-M-Mikrocontrollern implementierte MPU kann entweder acht oder sechzehn programmierbare Speicherbereiche mit ihren programmierbaren Startadressen MPU_RBAR sowie Größen und Attributen MPU_RASR unterstützen Für eine ordnungsgemäße TEE-Implementierung werden angepasst ➔ 1 Die Größe der MPU-Regionen durch einen Satz fester natürlich ausgerichteter Zweierpotenzen NAPOT Naturally Aligned Power of Two im Bereich von 32 Byte bis 4 GB kodiert ➔ 2 Die Basisadresse der Region an die Größe der Region Aus der Sicht eines Systementwicklers bringt dies harte Einschränkungen mit sich die entweder zur Verschwendung