Sichere Module: Schlüssel und Zertifikate in der Softwarearchitektur

Inhaltsverzeichnis

close notice

This article is also available in English. It was translated with technical assistance and editorially reviewed before publication.

Don’t show this again.

In Zeiten, in denen es für alles eine App gibt und sich alles aus dem Homeoffice fernsteuern lässt, ist es undenkbar, Systeme nur physisch abzusichern und die Kommunikation mit der Außenwelt zu verhindern. Unternehmen sammeln Daten zentral oder lagern gleich die gesamte Software in die Cloud aus. Das gilt sowohl in der klassischen IT als auch im OT- (Operational Technology) und IoT-Umfeld. Viele Geräte und sogar Gegenstände haben eine Verbindung ins Internet, Produktionsanlagen stellen Daten zentral beispielsweise als digitalen Zwilling zur Verfügung, und selbst die tot geglaubte Industrie 4.0 zur Vernetzung von Lieferanten, Produzenten und Kunden erfährt mit Manufacturing-X neue Aufmerksamkeit. Die Europäische Union hat mit dem EU Cyber Resilience Act eine Rechtsvorschrift geschaffen, die Sicherheit für Software innerhalb der Mitgliedsländer vorschreibt und Security by Design fordert.

Gerald Richter

ist CTO und Gründer der ECOS Technology GmbH, die sich seit 25 Jahren mit IT-Sicherheit im Bereich PKI und Remote Access beschäftigt. Dabei hat er reichhaltige Erfahrung in der Entwicklung von IT-Sicherheit-Software in verschiedensten Programmiersprachen gesammelt und liebt auch heute noch den direkten Kontakt mit dem Code.

Security muss am Anfang des Designprozesses von Software stehen. Angriffe, die Buffer Overflows, inkorrekte Parametervalidierung oder Schwachstellen in der Nebenläufigkeit ausnutzen, sind nach wie vor an der Tagesordnung. Teams müssen solche potenziellen Schwachstellen bereits beim Design der Software berücksichtigen, sowohl bei der Auswahl der Tools und Programmiersprachen als auch bei der Architektur.

Dieser Artikel beleuchtet vor allem einen Teilaspekt der Architektur, der für die Security wichtig ist: den richtigen Einsatz von Kryptografie. Sie verhindert keine Schwachstellen im Code, schützt aber sowohl die Daten, mit denen die Software arbeitet, als auch das Programm. Damit zielt sie auf die in der IT-Security üblichen Schutzziele ab: Vertraulichkeit, Integrität, Authentizität.

Zur Vertraulichkeit gehört, dass Daten nur der- oder diejenige zu Gesicht bekommt, der sie auch sehen soll. Vertraulichkeit entsteht klassisch durch Verschlüsselung. Das zweite Schutzziel Integrität stellt sicher, dass sich die Daten nicht manipulieren lassen: Wer die Daten empfängt, muss sicherstellen können, dass diese auf dem Weg vom Sender nicht verändert wurden. Hier helfen digitale Signaturen. Die Authentizität sorgt dafür, dass die Gegenstelle der Kommunikation diejenige ist, die sie zu sein vorgibt. Das verhindert, dass sich jemand mittels eines Man-in-the-Middle-Angriffs dazwischengeschaltet hat. Dieses Schutzziel lässt sich mit kryptografisch verifizierbaren Identitäten umsetzen.

Codesigning gegen Manipulation

Kryptografie hilft in vielen Bereichen der Softwareentwicklung, die genannten Schutzziele umzusetzen. Sie kann zunächst die Anwendung selbst schützen, damit Angreifer die Integrität nicht angreifen können, indem sie Funktionen umprogrammieren oder Schadcode einbringen und damit beispielsweise Daten direkt an der Quelle anzapfen oder manipulieren.

Digitale Signaturen sollen sicherstellen, dass niemand die Software manipuliert hat. Dazu erhält das Binary eine Signatur mit einem privaten Schlüssel, der mit dem öffentlichen Schlüssel als Pendant überprüfbar ist. Wesentlich ist dabei, dass auch die Integrität der Software geschützt ist, die die Signatur prüft. Dazu dient in der Regel eine Kette von Prüfungen. Dabei wird der erste Teil der Software, die Firmware, das BIOS beziehungsweise UEFI, durch die Hardware selbst auf Integrität geprüft.

Die Firmware kann dann die Signatur des Bootloaders prüfen, der die Signatur des Kernels untersucht, der wiederum sicherstellt, dass die Anwendung korrekt signiert ist. Die Prüfkette darf keine Lücke aufweisen, da diese ein Einfallstor für einen Angriff wäre. In Systemen, die man vollständig kontrollieren kann, wie bei Embedded-Systemen, kann und muss man auch selbst sicherstellen, dass die Kette vollständig implementiert ist. Die einzige Herausforderung dort besteht in den begrenzten Hardwareressourcen.

Auf Systemen, die man nicht komplett unter Kontrolle hat, kommen oft Zertifikate für das Codesigning zum Einsatz. Hierbei muss das Betriebssystem den öffentlichen Schlüssel als Gegenstück des zur Signatur verwendeten privaten Schlüssels nicht kennen. Es muss lediglich in der Lage sein, die Echtheit des Zertifikats zu verifizieren, da der öffentliche Schlüssel Teil des Zertifikats ist. Eine solche Verifikation erfolgt mittels einer Zertifizierungsstelle (Certificate Authority, CA). Diese fungiert als vertrauenswürdiger Dritter, der die Zertifikate signiert hat, sodass man wiederum mit dem öffentlichen Schlüssel der CA die Gültigkeit der Zertifikate prüfen kann.

Bei Windows, macOS, iOS und Android lassen sich unsignierte Binaries ohne explizite Bestätigung nicht ausführen. Auch stehen hier die entsprechenden Tools für Entwickler zur Verfügung, um Codesigning einfach in den Entwicklungsworkflow zu integrieren. An anderen Stellen, beispielsweise im Embedded-Bereich, aber auch unter Linux sieht es jedoch anders aus. Hier kommen oft noch unsignierte Binaries zur Ausführung, da unter Umständen das Ökosystem im Betriebssystem oder in der Entwicklungsumgebung fehlt. Oft hat die Hardware nicht die notwendige Rechenleistung oder keine Möglichkeit, die Firmware zu prüfen. Das bedeutet, dass bei der Softwarearchitektur auch die Architektur der Hardware entscheidend ist, um sichere Software zu entwickeln.

Sichere Updates

Wer beim Softwaredesign alle Punkte berücksichtigt, kann sich trotzdem nicht in Sicherheit wiegen. Bugs werden oft nachträglich entdeckt oder kryptografische Verfahren gebrochen. Auch kommt es vor, dass jemand zu einem späteren Zeitpunkt Schwächen in zuvor als sicher angesehenen Protokollen entdeckt. Für eine sichere Software ist es deswegen unumgänglich, Updates durchführen zu können. Der EU Cyber Resiliance Act (CRA) fordert für alle in der Europäischen Union in Handel gebrachten Produkte lebenslange Softwareupdates – mindestens für fünf Jahre, wenn die Lebenszeit des Produktes nicht nachgewiesen kürzer ist.

Pflichten der Hersteller im EU Cyber Resiliance Act
Schutzziele	Schutz der Vertraulichkeit von Daten durch Verschlüsselung mit modernsten Mechanismen,Schutz der Integrität von Daten, Befehlen, Programmen und Konfigurationen vor Manipulation, Schutz vor unbefugtem Zugriff durch Authentifizierungs-, Identitäts- oder Zugangsverwaltungssysteme, Verfügbarkeit wesentlicher Funktionen, einschließlich Abwehrfähigkeit und Eindämmung von Denial-of-Service-Angriffen.
Security by Default	Auslieferung mit einer sicheren Standardkonfiguration, mit Option zum Reset auf diese Konfiguration. Die Verarbeitung ist auf die für den Zweck angemessenen und relevanten Daten zu beschränken.
Security by Design	Minimierung der eigenen negativen Auswirkungen auf die Verfügbarkeit der Dienste anderer Geräte oder Netze, Minimierung der Angriffsflächen inklusive externer Schnittstellen, Implementierung geeigneter Mechanismen zur Minimierung der möglichen Auswirkungen eines Vorfalls.
Monitoring	Loggen sicherheitsbezogener Informationen sowie einschlägiger interner Vorgänge (beispielsweise Zugang zu Daten, Diensten oder Funktionen und Änderungen daran).
Sicherheitsupdates	Regelmäßige Sicherheitsupdates zur Behebung von Schwachstellen, gegebenenfalls auch durch automatische Aktualisierungen.

Während Mobile-Apps via App Store eine Updatemöglichkeit ebenso mitbringen wie Linux-Distributionen, müssen sich Softwarehersteller an anderen Stellen eigenhändig darum kümmern. Sie müssen einen Prozess bieten, um Softwareupdates (automatisch) zu verteilen, und dafür sorgen, dass dieser Prozess sicher ist. Ansonsten sind Aktualisierungen das perfekte Angriffsziel. Hier gilt es vor allem die Integrität sicherzustellen, indem der Hersteller die Updates signiert und diese Signatur beim Updateprozess überprüft wird.

In der Softwareentwicklung kommen zudem oft viele Bibliotheken zum Einsatz. Das Entwicklungsteam ist somit auch Konsument von Inhalten und muss für eine sichere Einbindung sorgen. Es darf nicht einfach einen Container von Docker Hub oder ein Modul aus einer beliebigen Registry einbinden, sondern muss sicherstellen, dass die Authentizität (Woher stammt die Library?) und die Integrität (Ist sie nicht manipuliert?) sichergestellt ist.

Jenseits der Kryptografie fordert der Cyber Resilience Act die für sicheres Design unumgänglichen Software Bills of Material (SBOM), die angeben, welche Komponenten in eine Software eingeflossen sind, um sie gegen bekannte Schwachstellen zu prüfen. Letztlich ist der Softwarehersteller dafür verantwortlich, einen sicheren Updateweg zur Verfügung zu stellen. Er kann sich nicht auf öffentliche Repositories verlassen, über die er keine Kontrolle hat.

Aufgabe der Softwarearchitektur ist es, Binaries, Container und Module, soweit sie nicht in signierter Form in öffentlichen vertrauenswürdigen Repositories zur Verfügung stehen, ausnahmslos auf Sicherheitslücken zu prüfen und zu signieren. Vor allem muss sichergestellt sein, dass das System nur Komponenten ausführt, deren Signatur vorher geprüft wurde.

Mehr Infos

Dieser Artikel ist auch im iX/Developer-Sonderheft zu finden, das sich an Softwarearchitektinnen und Softwarearchitekten richtet. Neben den klassischen Architekturinhalten zu Methoden und Pattern, gibt es Artikel zu Soziotechnischen Systemen, Qualitätssicherung oder zu Architektur und Gesellschaft. Domain Driven Design ist ebenso ein Thema wie Team Topologies und Green Scrum.

Als Autoren konnten wir bekannte Experten gewinnen, die ihr Wissen in vielen spannenden Artikeln – wie dem hier vorliegenden – sowohl für Architektureinsteiger als auch Spezialisten weitergeben.