Daten passend verschlüsseln und ihre Echtheit prüfen

Was du in dieser Lektion absicherst

Der IT-Dienstleister Serva Nord wartet Steuerungsrechner in mehreren Werkstätten. Nach einem Einsatz erzeugt das Diagnoseprogramm ein Paket mit Protokollen, Konfigurationsdateien und Kontaktdaten. Eine Servicetechnikerin speichert das Paket kurz auf ihrem Notebook und lädt es später über ein Kundenportal hoch.

Das Team formuliert vier Anforderungen:

• Wer das Notebook findet oder stiehlt, soll das Diagnosepaket nicht lesen können.
• Während der Übertragung zum Portal sollen Dritte die Daten weder mitlesen noch unbemerkt verändern können.
• Die Technikerin soll erkennen können, ob sie wirklich mit dem Kundenportal verbunden ist.
• Vor der Installation eines Diagnoseprogramms soll sie prüfen können, ob das Paket unverändert und vom erwarteten Anbieter freigegeben wurde.

Ein Kollege schlägt vor: “Wir bilden einfach überall einen Hashwert. Dann sind die Daten verschlüsselt.” Genau an dieser Stelle beginnt die fachliche Arbeit. Verschlüsselung, Hashing, digitale Signaturen und Zertifikate erfüllen unterschiedliche Aufgaben. Erst wenn du die gewünschte Wirkung benennst, kannst du ein passendes Verfahren auswählen.

Nach der Lektion kannst du:

• symmetrische, asymmetrische und hybride Verschlüsselung unterscheiden,
• Hashwert, digitale Signatur und Zertifikat ihren Aufgaben zuordnen,
• Schutzmaßnahmen für gespeicherte und übertragene Daten begründen,
• Grenzen und offene Fragen zur Schlüsselverwaltung dokumentieren.

Du brauchst dafür keine Mathematik hinter den Algorithmen. Es reicht, wenn du die Schutzziele Vertraulichkeit, Integrität und Authentizität kennst. Vertraulichkeit bedeutet, dass nur Berechtigte die Daten lesen können. Integrität bedeutet, dass Veränderungen erkennbar sind. Authentizität beantwortet die Frage, ob Daten oder ein Kommunikationspartner tatsächlich von der behaupteten Quelle stammen.

Ein Schlüssel macht Daten unlesbar und wieder lesbar

Bei einer Verschlüsselung wird lesbarer Klartext mit einem Verfahren und einem Schlüssel in Chiffretext umgewandelt. Der Chiffretext soll ohne den passenden Schlüssel nicht sinnvoll lesbar sein. Die Entschlüsselung stellt den Klartext wieder her.

Der Algorithmus darf bekannt sein. Die Sicherheit soll nicht davon abhängen, dass niemand das Verfahren kennt, sondern davon, dass der Schlüssel geheim oder auf andere Weise geschützt bleibt. Deshalb ist “unser eigenes, geheimes Verfahren” kein belastbares Sicherheitsargument. In einem realen Auftrag verwendest du geprüfte Protokolle und Bibliotheken nach der aktuellen Sicherheitsrichtlinie deines Betriebs.

Symmetrische Verschlüsselung verwendet denselben geheimen Schlüssel

Bei der symmetrischen Verschlüsselung besitzen Sender und Empfänger denselben geheimen Schlüssel. Was mit diesem Schlüssel verschlüsselt wurde, lässt sich mit demselben Schlüssel wieder entschlüsseln.

Das ist praktisch, wenn viele Daten verarbeitet werden sollen. Die eigentliche Datenverschlüsselung einer Festplatte oder einer laufenden Netzwerkverbindung arbeitet typischerweise symmetrisch. Der Advanced Encryption Standard, kurz AES, ist ein standardisiertes Beispiel für eine symmetrische Blockchiffre. FIPS 197 beschreibt AES mit Schlüssellängen von 128, 192 und 256 Bit. Die Zahl allein entscheidet aber noch nicht, ob eine konkrete Lösung sicher ist. Betriebsart, Implementierung, Schlüsselverwaltung und Einsatzdauer gehören ebenfalls zur Bewertung.

Die zentrale Schwierigkeit lautet: Wie gelangt der geheime Schlüssel sicher zu allen berechtigten Beteiligten? Wer den Schlüssel kopiert, kann die damit geschützten Daten entschlüsseln. Wird ein gemeinsamer Schlüssel von vielen Personen genutzt, lässt sich außerdem schwerer nachvollziehen, wer ihn verwendet hat.

Für das Serva-Nord-Notebook passt eine etablierte Laufwerksverschlüsselung grundsätzlich zum Schutzziel Vertraulichkeit. Sie muss so eingerichtet sein, dass Schlüsselmaterial und Wiederherstellungsweg geschützt sind. Ein Wiederherstellungsschlüssel direkt in derselben Notebooktasche würde die Maßnahme deutlich schwächen.

Asymmetrische Kryptografie arbeitet mit einem Schlüsselpaar

Bei der asymmetrischen Kryptografie gehören zwei unterschiedliche Schlüssel zusammen:

• Der öffentliche Schlüssel darf verteilt werden.
• Der private Schlüssel bleibt bei seiner Besitzerin oder seinem Besitzer geschützt.

Was der eine Schlüssel ermöglicht, hängt vom konkreten Verfahren ab. Ein verbreitetes Grundmodell zur Vertraulichkeit lautet: Eine Person verschlüsselt für den Empfänger mit dessen öffentlichem Schlüssel. Nur der passende private Schlüssel kann die Daten entschlüsseln.

Asymmetrische Verfahren helfen damit beim sicheren Aufbau einer Kommunikation, sind für große Datenmengen aber nicht einfach ein vollständiger Ersatz für symmetrische Verfahren. Moderne Protokolle kombinieren beide Welten. Außerdem wird asymmetrische Kryptografie für digitale Signaturen eingesetzt. Dabei ist die Wirkung eine andere: Es geht nicht darum, eine Nachricht geheim zu halten, sondern ihre Herkunft und Unverändertheit prüfbar zu machen.

Hybride Verfahren verbinden Schlüsselaustausch und Datenverschlüsselung

Ein hybrides Verfahren kombiniert verschiedene kryptografische Bausteine. Bei einer TLS-Verbindung wird nicht die gesamte Kommunikation einfach mit dem öffentlichen Schlüssel des Servers verschlüsselt. Vereinfacht passiert Folgendes:

1. Client und Server handeln im TLS-Handshake gemeinsame Parameter und frisches Schlüsselmaterial aus.
2. Der Server weist seine Identität typischerweise mit einem Zertifikat und einem Nachweis zum zugehörigen privaten Schlüssel nach.
3. Beide Seiten leiten Sitzungsschlüssel ab.
4. Die Anwendungsdaten werden anschließend symmetrisch und authentifiziert verschlüsselt.

Transport Layer Security, kurz TLS, soll einen geschützten Kanal zwischen Kommunikationspartnern herstellen. RFC 8446 beschreibt für TLS 1.3 Vertraulichkeit, Integrität und die Authentisierung des Servers als zentrale Eigenschaften. Die Nutzdaten werden mit Authenticated Encryption with Associated Data, kurz AEAD, geschützt. Dabei werden Vertraulichkeit und eine Integritätsprüfung in einer abgestimmten Operation verbunden.

Die konkrete Sicherheit entsteht nicht allein durch das Wort “TLS” oder ein Schlosssymbol. Client und Server müssen sichere Versionen und Parameter einsetzen. Der Client muss die Identität prüfen, Zertifikatsfehler dürfen nicht einfach übergangen werden, und die Endgeräte selbst müssen geschützt sein. TLS schützt außerdem nur den Transportweg zwischen den jeweiligen Endpunkten. Auf dem entsperrten Notebook und im entschlüsselten Kundenportal liegen die Daten für berechtigte Prozesse wieder lesbar vor.

Ein Hashwert ist ein Prüfwert, keine Verschlüsselung

Eine kryptografische Hashfunktion verarbeitet eine Eingabe beliebiger Länge und erzeugt einen Ausgabewert fester Länge. Dieser Ausgabewert heißt Hashwert oder Message Digest. Schon eine kleine Änderung an der Eingabe soll mit sehr hoher Wahrscheinlichkeit einen anderen Hashwert erzeugen.

Im Unterschied zur Verschlüsselung ist keine reguläre Rückrechnung zum Klartext vorgesehen. Es gibt auch keinen geheimen Entschlüsselungsschlüssel. Ein Hashwert schützt deshalb keine vertrauliche Datei vor dem Lesen.

Hashwerte helfen unter anderem dabei:

• Veränderungen an einer Datei zu erkennen, wenn ein vertrauenswürdiger Vergleichswert vorliegt,
• digitale Signaturen effizient auf einen kompakten Prüfwert zu beziehen,
• Datenstrukturen oder Übertragungen auf Integrität zu prüfen.

Ein veröffentlichter Hashwert neben einer Download-Datei reicht nicht immer für einen Herkunftsnachweis. Wenn Angreifende sowohl die Datei als auch den Hashwert auf derselben ungeschützten Seite austauschen können, passen beide wieder zusammen. Für einen belastbaren Herkunftsnachweis brauchst du zusätzlich einen vertrauenswürdigen Bezug, zum Beispiel eine gültig geprüfte digitale Signatur.

Passwörter sind ein besonderer Anwendungsfall. Sie sollten nicht mit einer schnellen allgemeinen Hashfunktion allein gespeichert werden. Dafür gibt es Passwort-Hashverfahren mit Salt und bewusstem Rechenaufwand. Diese Lektion grenzt das Thema nur ab; die passende Konfiguration hängt von Plattform, Bedrohungsmodell und aktueller Richtlinie ab.

Digitale Signaturen verbinden Integrität und Herkunftsnachweis

Eine digitale Signatur wird mit einem privaten Schlüssel erzeugt und mit dem zugehörigen öffentlichen Schlüssel geprüft. In der Praxis wird dabei nicht einfach die gesamte Datei als ein großer Schlüsselvorgang behandelt. Ein geeignetes Signaturverfahren bezieht einen kryptografischen Hashwert der Daten ein.

Eine erfolgreiche Prüfung zeigt im technischen Modell zwei Dinge:

• Die geprüften Daten wurden seit der Signatur nicht verändert.
• Die Signatur passt zu dem privaten Schlüssel, der zum verwendeten öffentlichen Schlüssel gehört.

Damit daraus ein sinnvoller Herkunftsnachweis wird, musst du zusätzlich wissen, wem der öffentliche Schlüssel verlässlich zugeordnet ist. Genau hier kommen Zertifikate und Vertrauensketten ins Spiel. Eine Signatur verschlüsselt die Datei nicht. Eine signierte Datei kann weiterhin für alle lesbar sein.

Für das Diagnoseprogramm von Serva Nord könnte der Anbieter das Installationspaket digital signieren. Das Betriebssystem oder ein Prüfwerkzeug kontrolliert dann die Signatur und die Vertrauenskette. Scheitert die Prüfung, wird das Paket nicht einfach trotzdem installiert. Das Team klärt zuerst, ob die Datei beschädigt, ausgetauscht, abgelaufen signiert oder aus einer nicht vertrauenswürdigen Quelle geladen wurde.

Ein Zertifikat bindet eine Identität an einen öffentlichen Schlüssel

Ein digitales Zertifikat enthält unter anderem einen öffentlichen Schlüssel, Angaben zum Inhaber oder zum geprüften Namen, einen Gültigkeitszeitraum und Informationen zum Aussteller. Der Aussteller signiert diese Angaben. Bei Webverbindungen prüft der Client eine Kette bis zu einer vertrauenswürdigen Zertifizierungsstelle, die bereits in seinem Vertrauensspeicher liegt.

Das Zertifikat des Kundenportals löst damit nicht die komplette Verschlüsselung. Es hilft dem Client, den öffentlichen Schlüssel mit dem erwarteten Portalnamen zu verbinden und den Servernachweis zu prüfen. Erst das Zusammenspiel aus Zertifikatsprüfung, Handshake, abgeleiteten Sitzungsschlüsseln und authentifizierter Verschlüsselung schützt die Verbindung.

Die Prüfung braucht mehrere Punkte:

• Passt der aufgerufene Name zum Zertifikat?
• Liegt der aktuelle Zeitpunkt im Gültigkeitszeitraum?
• Führt die Signaturkette zu einer vertrauten Stelle?
• Ist das Zertifikat für den vorgesehenen Zweck geeignet?
• Gibt es einen relevanten Sperr- oder Statushinweis?

Ein selbst signiertes Zertifikat ist nicht automatisch technisch wertlos. Ohne vorher sicher eingerichteten Vertrauensanker kann ein Client seine Zuordnung aber nicht allein aus dem Zertifikat ableiten. In einem Unternehmen kann eine interne Zertifizierungsstelle sinnvoll sein, wenn deren Vertrauensanker kontrolliert verteilt und Schlüssel, Ausstellung, Erneuerung sowie Sperrung sauber betrieben werden.

Die Maßnahme muss zur Bedrohung passen

Serva Nord plant nun die vollständige Lösung. Für jede Stelle wird nicht nur eine Technik, sondern auch ihre Grenze dokumentiert.

Daten auf dem Notebook

Eine Laufwerksverschlüsselung schützt Daten besonders dann, wenn das ausgeschaltete Notebook oder das ausgebaute Laufwerk in fremde Hände gelangt. Ist das Gerät bereits entsperrt und eine Schadsoftware läuft mit ausreichenden Rechten, kann sie auf lesbare Daten zugreifen. Deshalb gehören Gerätesperre, Rechtekonzept, Aktualisierungen und Schutz vor Schadsoftware weiterhin zum Sicherheitskonzept.

Der Wiederherstellungsschlüssel wird getrennt, zugriffsgeschützt und nachvollziehbar verwaltet. Sonst führt ein verlorenes Passwort entweder zum Datenverlust oder ein offen erreichbarer Wiederherstellungsschlüssel umgeht die gewünschte Hürde.

Daten auf dem Übertragungsweg

Das Kundenportal verwendet eine korrekt konfigurierte TLS-Verbindung. Der Client prüft den erwarteten Namen und die Vertrauenskette. Das schützt nicht gegen jede Gefahr: Ein kompromittierter Client kann Daten vor der Verschlüsselung auslesen, und ein kompromittierter Server kann sie nach der Entschlüsselung verarbeiten. Die Endpunkte und ihre Berechtigungen bleiben Teil des Schutzkonzepts.

Installationspaket des Diagnoseprogramms

Serva Nord lädt das Paket nur aus dem vorgesehenen Kanal. Eine gültige digitale Signatur verbindet Integritätsprüfung mit dem geprüften Anbieterschlüssel. Ein zusätzlicher Hashvergleich kann Übertragungsfehler oder Abweichungen sichtbar machen, wenn der Vergleichswert aus einem vertrauenswürdigen Kanal stammt. Weder Signatur noch Hashwert garantieren, dass die Software fachlich fehlerfrei ist.

So begründest du eine Auswahl

Eine fachliche Begründung verbindet vier Punkte:

1. Schutzobjekt: Welche Daten oder Verbindung wird betrachtet?
2. Bedrohung und Schutzziel: Was soll verhindert oder erkennbar werden?
3. Maßnahme: Welches Verfahren und welcher betriebliche Prozess tragen das Ziel?
4. Grenze: Welche Gefahr bleibt offen, und wie werden die Schlüssel verwaltet?

Für das Notebook könnte die Begründung so lauten:

Die Diagnosepakete enthalten schutzbedürftige Kundeninformationen. Eine etablierte Laufwerksverschlüsselung schützt ihre Vertraulichkeit, wenn das ausgeschaltete Notebook oder sein Datenträger entwendet wird. Der Wiederherstellungsschlüssel wird getrennt und nur für berechtigte Personen erreichbar verwaltet. Die Maßnahme schützt nicht vor Schadsoftware, die auf dem bereits entsperrten Gerät mitlesen kann. Deshalb bleiben Rechtevergabe, Gerätesperre, Aktualisierungen und Datensicherung erforderlich.

Diese Formulierung verspricht nicht mehr, als die Maßnahme leisten kann. Gleichzeitig nennt sie genug Informationen, damit eine andere Person die Entscheidung prüfen kann.

Was du aus der Schutzentscheidung mitnimmst

Du kannst die Verfahren jetzt über ihre Wirkung auseinanderhalten:

• Symmetrische Verschlüsselung nutzt einen gemeinsamen geheimen Schlüssel und schützt Daten effizient auf Speichern oder in laufenden Sitzungen.
• Asymmetrische Kryptografie nutzt ein zusammengehöriges Schlüsselpaar und unterstützt unter anderem Schlüsselaushandlung, Verschlüsselung für einen Empfänger und digitale Signaturen.
• Hybride Verfahren kombinieren mehrere Bausteine. TLS 1.3 handelt Schlüsselmaterial und Identität im Handshake aus und schützt Anwendungsdaten anschließend authentifiziert und symmetrisch.
• Hashfunktionen erzeugen nicht umkehrbare Prüfwerte. Sie verschlüsseln keine Daten und belegen allein keine vertrauenswürdige Herkunft.
• Digitale Signaturen machen Veränderungen prüfbar und binden die Prüfung an einen öffentlichen Schlüssel.
• Zertifikate helfen, einen öffentlichen Schlüssel einer geprüften Identität oder einem Namen zuzuordnen.

Die wichtigste Arbeitsregel bleibt: Nenne zuerst Schutzobjekt, Bedrohung und Schutzziel. Wähle danach die Maßnahme und dokumentiere, was sie nicht abdeckt.

Quellenbasis und Abgrenzung

Die berufliche Handlung folgt Lernfeld 4 des KMK-Rahmenlehrplans. Dort analysieren Lernende Schutzbedarf und wählen passende Maßnahmen. Berufsbildposition A6 der Fachinformatikerausbildungsverordnung trägt das Umsetzen, Integrieren und Prüfen von Maßnahmen zur IT-Sicherheit und zum Datenschutz. Der AP1-Prüfungskatalog nennt symmetrische, asymmetrische und hybride Verschlüsselung sowie Hashwerte, Zertifikate und digitale Signaturen als Themenbreite. Das ist keine Aussage darüber, welche Aufgabe in einem konkreten Prüfungstermin vorkommt.

Die Prüfung aus Herbst 2023 wurde nur auf wiederkehrende Aufgabenformen untersucht. Dazu gehören das Beurteilen von Datenträgerverschlüsselung, die Aufbewahrung eines Wiederherstellungsschlüssels und die Einordnung eines Zertifikats. Szenario, Unternehmen, Daten, Entscheidungen und Lösungen dieser Lektion sind neu erstellt. Sie bilden keine echte IHK-Aufgabe ab.

Die BSI TR-02102-1 dient als aktuelle deutsche Orientierung für kryptografische Verfahren und Schlüssellängen. FIPS 197 stützt die Einordnung von AES. FIPS 180-4 stützt das Grundmodell kryptografischer Hashfunktionen; NIST hat 2023 eine Überarbeitung und die Entfernung von SHA-1 aus der nächsten Fassung angekündigt. Diese Lektion leitet deshalb keine pauschale Empfehlung allein aus einem Algorithmusnamen ab.

RFC 8446 trägt die vereinfachte Erklärung von TLS 1.3. Das Diagramm ist kein vollständiger Paketmitschnitt. Reale Konfigurationen hängen von Bedrohungsmodell, Plattform, Protokollversion, Betriebsrichtlinie, Implementierung und geplantem Schutzzeitraum ab. Aktuelle Herstellerdokumentation und die im Betrieb geltende Sicherheitsrichtlinie haben bei einer Umsetzung Vorrang.

Belegmatrix

Symmetrische, asymmetrische und hybride Verschlüsselung unterscheiden

• Ordnungsmittel: LF4, A6 und T1
• Quellen: Rahmenlehrplan, Ausbildungsordnung, AP1-Katalog, BSI TR-02102-1, FIPS 197 und RFC 8446
• Lernaktivität: Serva-Nord-Szenario, Grundlagenerklärung, Zuordnung und TLS-Diagramm

Hashwert, digitale Signatur und Zertifikat ihrer Aufgabe zuordnen

• Ordnungsmittel: LF4, A6 und T1
• Quellen: AP1-Katalog, FIPS 180-4 und RFC 8446
• Lernaktivität: Abgrenzung am Installationspaket und Entscheidungsquiz

Eine passende Schutztechnik für Speicherung oder Übertragung auswählen

• Ordnungsmittel: LF4, A6 und T1
• Quellen: Rahmenlehrplan, Ausbildungsordnung, AP1-Katalog und abstrahierte Aufgabenform Herbst 2023
• Lernaktivität: Bedrohungsanalyse, Mehrfachauswahl und Auswahlbegründung

Grenzen einer Maßnahme im Sicherheitskonzept benennen

• Ordnungsmittel: LF4 und A6
• Quellen: Rahmenlehrplan, BSI TR-02102-1 und RFC 8446
• Lernaktivität: Grenzen bei entsperrten Endgeräten, Schlüsselverwaltung und Transferaufgabe