Arm-Verschlüsselungsbibliotheken
Cybersicherheit in armbasierten eingebetteten Systemen
Cyber-Sicherheit: Jedes vernetzte Gerät ist ein potenzielles Angriffsziel
Jedes Gerät, das mit einem Netzwerk verbunden ist, ist ein potenzielles Ziel eines Cyber-Angriffs. Dies gilt auch für Geräte, die nicht mit öffentlichen Netzwerken verbunden sind - ein privates Netzwerk könnte gehackt und alle damit verbundenen Geräte könnten kompromittiert werden. Aus diesem Grund ist die Industrie sehr sicherheitsorientiert. Mit speziellen Schwachstellentests können Sie Ihre Geräte während der gesamten Entwicklungsphase validieren.
Industrie setzt auf Sicherheit: Schwachstellentests und Stresstests
Die Achilles-Testplattform von GE Digital bietet einen Stresstest, der Cyber-Angriffe über eine TCP/IP-Netzwerkverbindung simuliert. GE Digital bietet auch einen Zertifizierungsdienst für Endgeräte an.
Die Arm Middleware Netzwerkkomponente wird mit der Achilles Test Software (ATS) verifiziert und besteht die Level 1 Tests, daher sollten Arm Cortex-M-basierte Mikrocontroller, die die Netzwerkkomponente verwenden, die Achilles Level 1 Zertifizierung bestehen. Empfehlungen für die Verwendung der Arm Middleware Network Component.
Netzwerksicherheit: Abwehrmechanismen gegen bekannte Angriffsarten
Heutzutage gibt es viele bekannte Arten von Netzwerkangriffen, eine Liste wäre ziemlich lang. Einige Netzwerksicherheitsmechanismen wurden bereits implementiert, z.B. gegen Spank-Angriffe und gefälschte RST-Pakete in TCP-Sockets. Einige Angriffsarten werden implizit durch das Implementierungskonzept des Stacks blockiert, z.B. werden Jumbo-Pakete (Ethernet-Pakete größer als 1514 Byte) abgelehnt. Fragmentierte Pakete werden ebenfalls nicht unterstützt, wodurch der Middleware-Netzwerkstack immun gegen Ping-of-Death-Angriffe usw. ist.
Der private SSL-Schlüssel wird häufig einfach auf dem Server gespeichert. In einer eingebetteten Umgebung mit mehreren Servern bringt dieser Standard Probleme mit sich. Eine sichere, aber kostspielige Lösung besteht darin, jedem Server einen eigenen privaten Schlüssel zuzuweisen. Bei eindeutigen, selbstsignierten Zertifikaten für jeden Server kann es zu Verzögerungen kommen, wenn der Client-Browser dem Server vertrauen muss (es kann sogar eine zusätzliche Browserkonfiguration erforderlich sein, und selbst dann ist die Client-Kommunikation anfällig für zusätzliche Schwachstellen). Da sich mehrere Server einen privaten Schlüssel teilen, muss nur ein Server kompromittiert werden, um Zugriff auf den privaten SSL-Schlüssel zu erhalten. Wenn es dann möglich ist, ein- und ausgehende Pakete zu lesen, kann derselbe Schlüssel verwendet werden, um den Datenverkehr von jedem Server zu entschlüsseln.
SSL-Schlüsselverwaltung in eingebetteten Umgebungen
Für ARMv8-M-Architekturen (einschließlich Cortex-M23- und Cortex-M33-Cores) empfehlen wir, einen privaten SSL-Schlüssel in einem sicheren Speicherbereich des Geräts zu speichern. Benutzer sollten versuchen, diesen Schlüssel unabhängig von der Architektur zu sichern; wenn Sie eine frühere Architektur verwenden, fragen Sie einen Halbleiterhersteller nach alternativen sicheren Speicherlösungen. Der Schutz des privaten Schlüssels des Servers schützt die Verschlüsselung der Kommunikation zwischen Server und Client. Besprechen Sie alle vorgeschlagenen SSL-Konfigurationen mit einem Zertifikatsherausgeber, um sicherzustellen, dass sein Produkt die vorgeschlagene Konfiguration der Anwendung unterstützt.