Startseite > Embedded > Software > Keine Safety ohne Security

Software-Entwicklung

Keine Safety ohne Security

18. April 2017, 10:42 Uhr | Von Dan Smith und Andrew Girson

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

Safety- und Security-gerechtes Design

Wie das Beispiel Therac-25 zeigt, gilt es beim Safety-gerechten Design vieles zu beachten. Allerdings können Designer immer nur ihren eigenen Aspekt des Designs kontrollieren. Der Fokus dieses Beitrags liegt auf der Firmware.

Kraftfahrzeuge sind ein gutes Beispiel für missionskritische Anwendungen. Sie können mehr als 100 Millionen Codezeilen enthalten, werden aber von häufig ungeschulten oder unkonzentrierten Anwendern (eben den Autofahrern) bedient. Um die Defizite solcher Benutzer zu kompensieren, werden immer mehr Safety-Funktionen und Code eingeführt, sei es als Kameras oder Sensoren oder in Form von V2I- oder V2V-Kommunikation (Vehicle to Infrastructure bzw. Vehicle to Vehicle). Der Codeumfang nimmt dabei exponentiell zu.

Schon allein der Umfang des Codes macht das Codieren und Debuggen eines Systems schwieriger, jedoch kann ein Großteil des Zeitaufwands für das Debugging durch Beachtung einiger weniger Grundregeln eliminiert werden:

Untergliederung der Hard- und Software unter Berücksichtigung von Echtzeit-Performance, Kosten, Upgrade-Fähigkeit, Security, Zuverlässigkeit und Safety
Implementierung von Fehlereingrenzungs-Bereichen
Vermeidung von ‚Single Points of Failure’ (Bild 2) [4]
Behandlung von Exceptions, die von Codefehlern, dem Programm selbst, dem Memory Management oder falschen Interrupts ausgelöst werden
Einbindung von Überlaufprüfungen (siehe Therac-25 und Ariane)
Bereinigen verfälschter Daten aus der Außenwelt (Bereichsprüfung und CRC)
Testen auf allen Ebenen (Modultest, Integrationstest, Systemtest, Fuzzing, Verifikation, Validierung usw.).

Für die Security müssen sich Entwickler mit den Feinheiten von Benutzer- und Geräte-Authentisierung, Public-Key-Infrastruktur (PKI) und Datenverschlüsselung auseinandersetzen.

Jobangebote+ passend zum Thema

MACNICA ATD EUROPE - Ihre berufliche Zukunft

MACNICA ATD Europe GmbH, Ingolstadt

Alle Jobangebote im Elektroniknet Karrierebereich anzeigen

Abgesehen davon, dass der Zugriff auf Funktionen für autorisierte Nutzer freigegeben und für nicht autorisierte Nutzer gesperrt wird, bedeutet Security auch, dass ein System im Fall eines Angriffs oder einer Fehlfunktion keine unerwarteten oder unsicheren Dinge tut.

Attacken können in unterschiedlicher Form erfolgen, so zum Beispiel als normale Denial-of-Service-Angriffe (DoS) oder als Distributed-DoS-Angriffe (DDoS). Entwickler können naturgemäß nicht kontrollieren, wie ein System angegriffen wird. Sie haben aber Einfluss darauf, wie das System auf den Angriff reagiert. Dieses Reaktionsbewusstsein muss das gesamte System einbeziehen, denn jedes System ist nur so sicher wie sein schwächstes Glied – und man muss davon ausgehen, dass Angreifer dieses schwächste Glied finden. Ein Beispiel für ein solches schwächstes Glied sind Firmware Updates, wenn das RFU Feature (Remote Firmware Update) des Systems aktiviert ist. Dieses ist leicht angreifbar, sodass es ratsam ist, entweder den Anwender das RFU Feature deaktivieren zu lassen und ein Update zu laden, das bei nachfolgenden Images stets eine digitale Signatur verlangt.

Auch wenn es der Intuition widerspricht, ist die Kryptografie selten das schwächste Glied. Angreifer suchen vielmehr anderswo nach Angriffsoberflächen, die über die Implementierung, Protokollsicherheit, APIs, Nutzungsweise oder Seitenkanal-Attacken angreifbar sind. Wie viel Mühe, Zeit und Ressourcen in diese Bereiche investiert werden, hängt von der Bedrohungsart ab. Mit den folgenden Maßnahmen lässt sich die Anfälligkeit eines Produkts reduzieren:

Verwenden Sie einen Mikrocontroller ohne externe Speicher.
Deaktivieren Sie das JTAG Interface.
Implementieren Sie einen Secure-Boot-Prozess.
Verwenden Sie einen Master-Schlüssel zum Generieren der gerätespezifischen Schlüssel.
Machen Sie von der Objektcode-Verschleierung Gebrauch.
Implementieren Sie Power-On Self Test (POST) und Built-In Self Test (BIST).

Im Zusammenhang mit dem Begriff Verschleierung ist anzumerken, dass es eine Lehrmeinung gibt, die Sicherheit durch Unsichtbarkeit erreichen will. Diese Denkweise kann jedoch fatal sein, wenn man ausschließlich auf sie setzt. Jedes Geheimnis erzeugt schließlich eine potenzielle Problemstelle [5]. Früher oder später kommen Geheimnisse ans Licht – ob durch Social Engineering, verärgerte Mitarbeiter oder Techniken wie Dumping und Reverse Engineering. Dennoch hat Unsichtbarkeit natürlich ihre Bedeutung, beispielsweise bei der Geheimhaltung von Chiffrierschlüsseln.

Gewährleistung von Safety und Security

Viele Techniken und Technologien können Entwicklern beim Erreichen eines hohen Safety- und Security-Niveaus helfen. Zusätzlich aber lässt sich mit einigen grundlegenden Maßnahmen sicherstellen, dass ein System so weit wie vernünftigerweise möglich optimiert ist. Zunächst sind beim Design etablierte, branchen- und anwendungsspezifische Standards für Codierung und funktionale Sicherheit anzuwenden. Beispiele sind MISRA und MISRA-C, ISO 26262, die Automotive Open System Architecture (AUTOSAR), IEC 60335 und IEC 60730. Die Anwendung von Codierstandards wie MISRA vermeidet nicht nur das Entstehen von Bugs, sondern verbessert auch die Lesbarkeit, Konsistenz und Portierbarkeit des Codes (Tabelle).

Wenden Sie darüber hinaus die statische Analyse an (Bild 3). Es handelt sich dabei um die Analyse der Software ohne Ausführung des Programms – um eine symbolische Ausführung, also im Prinzip um eine Simulation. Im Gegensatz dazu deckt die dynamische Analyse etwaige Defekte während der Verarbeitung des echten Codes auf einem Zielsystem auf.

Auch wenn die statische Analyse keine Wunderwaffe ist, sie bildet eine zusätzliche Sicherheitsebene und eignet sich sehr gut zum Aufdecken von potenziellen Fehlern wie etwa nicht initialisierten Variablen, möglichen Über- oder Unterläufen von Integer-Werten und der Vermengung vorzeichenbehafteter und vorzeichenloser Datentypen. In der Regel bedingt die statische Analyse die Verwendung eines speziellen Tools wie PC-Lint oder Coverity. Entwickler sollten aber auch die erneute Analyse ihres eigenen Codes erwägen.

Als dritte Maßnahme sollten Codeprüfungen erfolgen. Diese verbessern die Korrektheit des Codes und sorgen dafür, dass er einfacher zu pflegen und zu erweitern ist. Hilfreich sind Codeprüfungen auch bei Rückrufen und Produkthaftungsklagen.

Als vierte Maßnahme sollten die Bedrohungen modelliert werden. Beginnen Sie mit einem Angriffsbaum. Der Entwickler muss sich dazu in die Lage eines Angreifers versetzen und

Angriffsziele identifizieren – jede Attacke hat ihren eigenen Baum
für jeden Baum (jedes Ziel): Die verschiedenen Angriffe bestimmen. Die Schritte und Optionen jedes Angriffs identifizieren.

Diese Art der Analyse profitiert erheblich von mehreren Perspektiven.

Wer hat die Zeit, es richtig zu machen?

Anscheinend ist es also ganz einfach, mit den gerade beschriebenen vier Maßnahmen die Fehlerhäufigkeit zu minimieren und für mehr Safety und Security zu sorgen. Das alles kostet aber Zeit, sodass Entwickler ihr Budget sorgfältig einteilen müssen. Hier ist größtmöglicher Realismus gefordert. Zum Beispiel ist für die Codeprüfung ein Zeitaufschlag von 15 bis 50 Prozent anzusetzen. Einige Systeme erfordern komplette Codeprüfungen – andere nicht. Statische-Analyse-Tools können für die Ersteinrichtung zwischen zehn und mehreren hundert Stunden erfordern. Sind sie aber erst einmal in den Entwicklungsprozess integriert, entsteht kein zusätzlicher Zeitaufwand mehr und sie machen sich durch die höhere Qualität der Systeme von selbst bezahlt.

Die Vernetzung stellt für Embedded-Systeme ein gravierendes neues Pro¬blem dar, das die Bedeutung von Safety und Security weiter erhöht. Ein gutes Verständnis beider Konzepte verbunden mit der richtigen Anwendung erprobter Methoden verbessert die Safety- und Security-Eigenschaften eines Produkts entscheidend. Zu den erprobten Methoden gehören die Anwendung von Codierstandards und Statische-Analyse-Tools, Codeprüfungen und die Bedrohungs-Modellierung.

Die Barr Group, ein unabhängiger Anbieter von hochwertigem Produktdesign, Schulungen und technischen Beratungsleistungen, veranstaltet im Frühjahr und Herbst öffentliche Schulungen in Deutschland und Nordamerika. Info:
http://info.barrgroup.com/elektronik.

Referenzen

[1] Backdoor-Accounts in 80 Sony-Überwachungskameras gefunden.
www.pcworld.com/article/3147311/security/backdoor-accounts-found-in-80-sony-ip-security-camera-models.html
[2] Chrysler ruft nach Jeep-Hack 1,4 Mio. Fahrzeuge zurück.
www.wired.com/2015/07/jeep-hack-chrysler-recalls-1-4m-vehicles-bug-fix/
[3] Von einer Maschine getötet: Therac-25.
hackaday.com/2015/10/26/killed-by-a-machine-the-therac-25/
[4] Fallstudie: Ungewollte Beschleunigung und Softwaresicherheit bei Toyota.
users.ece.cmu.edu/~koopman/pubs/koopman14_toyota_ua_slides.pdf
[5] Zitat von Charles Mann, Bruce Schneier paraphrasierend (Atlantic Monthly, Sept. 2002).

Die Autoren

Andrew Girson
Als Mitgründer der Barr Group besitzt Andrew Girson mehr als 20 Jahre Erfahrung in der Embedded-Systems-Branche – zunächst als Senior Embedded Software Engineer und anschließend in Führungspositionen wie der des CTO, des Vice President of Sales and Marketing und des CEO. Er verhalf mehreren Unternehmen über viele Jahre hinweg zu zweistelligen Umsatz- und Gewinnsteigerungen unter Wahrung einer klaren technischen Fokussierung auf Embedded-, Wireless- und Handheld-Systeme hoher Qualität. Girson hat an der University of Virginia ein BS- und ein MS-Diplom in Elektrotechnik erworben.

Andrew Girson

Als Mitgründer der Barr Group besitzt Andrew Girson mehr als 20 Jahre Erfahrung in der Embedded-Systems-Branche – zunächst als Senior Embedded Software Engineer und anschließend in Führungspositionen wie der des CTO, des Vice President of Sales and Marketing und des CEO. Er verhalf mehreren Unternehmen über viele Jahre hinweg zu zweistelligen Umsatz- und Gewinnsteigerungen unter Wahrung einer klaren technischen Fokussierung auf Embedded-, Wireless- und Handheld-Systeme hoher Qualität. Girson hat an der University of Virginia ein BS- und ein MS-Diplom in Elektrotechnik erworben.

agirson@barrgroup.com

Dan Smith
arbeitet als Prinicipal Engineer bei der Barr Group. Er verfügt über mehr als 20 Jahre Praxiserfahrung in der Embedded-Software-Entwicklung mit C und C++. Seine Firmware findet sich in Konsumelektronik, Kommunikationssystemen, industriellen Steuerungen und Medizingeräten. Herr Smith erwarb sein BSEE-Dipolm in Princeton und ist ein Experte in der Sicherheit von Embedded-Systemen.