xinionos/docs/decisions/ADR-0003-verschluesselung-und-loeschung.md

# ADR-0003 — Der Bestandsbereich ist verschlüsselt, gelöscht wird über den Schlüssel

**Stand:** Angenommen, 20.08.2026 · **Entscheidet:** CIO Thomas Reitz
**Bezug:** `ADR-0002` (Startverfahren), Bedienkonzept §4 · **Betrifft:** Ersteinrichtung,
Konsolenmenü, Fassungswechsel, Außerbetriebnahme

---

## Worum es geht

Ein Gerät steht beim Kunden im Serverraum. Wer bis dorthin kommt, ist freigegeben — der Raum ist
die Zugangskontrolle, und so arbeitet jedes Netzwerkgerät. Die Annahme trägt aber genau so lange,
wie das Gerät im Haus des Kunden bleibt.

**Sie trägt nicht mehr, wenn ein Laufwerk das Haus verlässt:** bei Reparatur, bei Austausch, bei
Rückgabe am Vertragsende, bei Entsorgung. Dann entscheidet nicht mehr das Türschloss, sondern
allein das, was auf dem Datenträger steht.

Die Frage lautet deshalb: **Was gibt ein Laufwerk her, das aus dem Gerät ausgebaut wird?**

## Die Entscheidung

**Der Bestandsbereich wird bei der Einrichtung verschlüsselt. Ohne Ausnahme und ohne Schalter.**

Er trägt alles, was dem Kunden gehört — Zustandsdatenbank, Wissensspeicher, Vektorindex, Tresor,
Protokolle. Genau deshalb ist er auch der richtige und einzige Ort dafür: Die Regel „alles
Dauerhafte gehört in den Bestand" macht die Verschlüsselung **eines** Bereichs ausreichend.

**Die Wurzeln werden nicht verschlüsselt, sondern auf Unversehrtheit geprüft.**

Das ist kein Sparen, sondern eine andere Frage. In den Wurzeln steht unsere ausgelieferte Software
— sie ist auf jedem Gerät dieselbe und damit kein Geheimnis. **Vertraulichkeit ist dort kein Thema,
Unversehrtheit sehr wohl:** Wer den Datenträger in der Hand hat, könnte die Wurzel verändern und
das Gerät startete sie. Dagegen hilft keine Verschlüsselung, sondern eine Prüfung beim Start.

Das passt zudem zum A/B-Verfahren: Eine nur lesbare, geprüfte Wurzel ist ohnehin das, was der
Fassungswechsel voraussetzt.

## Sichere Löschung heißt Schlüsselvernichtung

**Auf Flash-Speichern ist Überschreiben nicht verlässlich.** Die Verschleißverteilung des Laufwerks
schreibt an eine andere Stelle, als der Befehl meint; überschriebene Blöcke können physisch
erhalten bleiben. Ein Löschlauf, der stundenlang Nullen schreibt, erzeugt vor allem ein gutes
Gefühl.

**Ist der Bereich verschlüsselt, ist die Löschung die Vernichtung des Schlüssels.** Das dauert
Sekunden, ist vollständig und lässt sich belegen. Der Rest ist Rauschen.

> Deshalb hängen die beiden Festlegungen zusammen: **Ohne Verschlüsselung gibt es keine verlässliche
> Löschung.** Wer B will, muss A haben.

Drei Stufen, weil drei verschiedene Absichten dahinterstehen:

| Stufe | Was geschieht | Wofür |
|---|---|---|
| **Einstellungen zurücksetzen** | Netz, Kennwörter, Zertifikate, Einrichtungszustand. Der Bestand bleibt | Ausgesperrt, falsch eingerichtet |
| **Sichere Datenlöschung** | Der Schlüssel wird vernichtet. Der Bestand ist damit unwiederbringlich | Weitergabe, Rückgabe, Vertragsende |
| **Datenträger bereinigen** | Zusätzlich der Löschbefehl des Laufwerks selbst | Entsorgung, Reparatur außer Haus |

Die zweite und dritte Stufe erzeugen einen **Löschnachweis** auf USB: Gerätekennung, Seriennummer
des Laufwerks, angewandtes Verfahren, Zeitpunkt, Ergebnis. Das ist kein Beiwerk — bei einem
Produkt, dessen Verkaufsargument der Nachweis ist, wäre eine Löschung ohne Beleg ein Widerspruch in
sich. Und es ist genau das, was ein Kunde am Vertragsende verlangt.

## Der Schlüssel muss ohne Menschen verfügbar sein — und das ist die harte Stelle

Ein Gerät im Serverraum muss nach einem Stromausfall von allein hochkommen. Niemand tippt um drei
Uhr nachts eine Passphrase. Der Schlüssel bindet deshalb an den **Sicherheitsbaustein der
Hardware**, der ihn nur herausgibt, wenn die Messung des Startzustands stimmt.

**Damit wird aus einer Tresorfrage eine Gerätefrage.** Die offene Frage O-8 betraf bisher die
Zugangsdaten; sie betrifft jetzt den gesamten Datenbestand.

> **Und sie kollidiert mit dem Fassungswechsel.** Die Messung des Startzustands ändert sich mit
> Kern und Startlader — also bei **jedem** Update. Wird der Schlüssel nicht vorher auch für die neue
> Fassung hinterlegt, steht nach dem Umschalten ein Gerät da, das oben ist und an seine eigenen
> Daten nicht herankommt.
>
> Das ist der schlimmste denkbare Ausgang: **nicht ein misslungenes Update, sondern ein
> unerreichbarer Bestand.** Und der Rücksprung rettet es nur, solange die alte Messung noch gültig
> ist.

Daraus folgt eine Reihenfolge, die nicht verhandelbar ist:

**Der Fassungswechsel hinterlegt den Schlüssel für die neue Fassung, solange die alte noch läuft
und der Bereich offen ist — und erst danach schaltet er um.** Wird das vergessen, ist das kein
Schönheitsfehler, sondern ein Datenverlust.

## Was daraus für den Nachweis folgt

Zum ersten Nachweis des Erzeugnisses — der Rücksprung greift von selbst — kommt ein zweiter, und er
ist genauso wichtig:

> **Nach einem Fassungswechsel und nach einem Rücksprung ist der Bestandsbereich erreichbar.**

Er lässt sich nur auf echter Hardware mit echtem Sicherheitsbaustein erbringen, nicht in einer
virtuellen Maschine.

## Die Sicherung wird mit einem anderen Schlüssel verschlüsselt

*Ergänzt am 20.08.2026 auf Entscheidung des CIO.*

Eine Sicherung, die unverschlüsselt auf einem Netzlaufwerk des Kunden liegt, hebt die
Verschlüsselung des Geräts vollständig auf. Sie wird deshalb ebenfalls verschlüsselt.

**Dabei ist die Wahl des Schlüssels wichtiger als die Entscheidung selbst.**

Eine Sicherung existiert für den Fall, dass das Gerät nicht mehr da ist. Würde sie mit dem
Geräteschlüssel verschlüsselt — dem, der am Sicherheitsbaustein hängt —, wäre sie **genau dann
unlesbar, wenn man sie braucht**: Gerät zerstört, Baustein weg, Schlüssel weg, Sicherung wertlos.
Das wäre keine Sicherung, sondern eine aufwendige Art, Speicherplatz zu belegen.

> **Die Sicherung trägt einen eigenen Schlüssel, der nicht am Gerät hängt und den der Kunde
> verwahrt.** Er wird bei der Einrichtung erzeugt und einmalig ausgegeben.

Daraus folgt eine Pflicht, die ins Handbuch und in die Einrichtung gehört: **Wer den
Sicherungsschlüssel verliert, hat keine Sicherung.** Das muss bei der Ausgabe unmissverständlich
dastehen — und die Ausgabe gehört in die Prüfspur, damit später nachweisbar ist, dass sie
stattgefunden hat.

## Zum Sicherheitstoken als Schlüsselträger

*Geprüft am 20.08.2026 auf Anregung des CIO.*

Ein Hardware-Token kann an drei verschiedenen Stellen eingesetzt werden, und sie lösen **nicht
dasselbe Problem**. Sie werden leicht verwechselt.

| Einsatz | Was es leistet | Bewertung |
|---|---|---|
| **Als Wiederherstellung** — Token im Tresor des Kunden, entsperrt bei Ausfall des Sicherheitsbausteins | Löst den Totalverlust bei Defekt der Hauptplatine | **tragfähig** — aber eine ausgedruckte Wiederherstellungslosung leistet dasselbe ohne Lieferkette |
| **Als Startbedingung** — Token steckt dauerhaft im Gerät | Das Laufwerk allein ist wertlos | **kein Gewinn gegenüber dem Sicherheitsbaustein**, siehe unten |
| **Als zweiter Faktor** für die Verwaltung | Anmeldung an Konsole und Oberfläche | **eigenständig sinnvoll**, unabhängig von der Verschlüsselung |

**Warum ein dauerhaft steckender Token nichts hinzufügt:** Er schützt gegen ein entwendetes
Laufwerk — aber das tut der Sicherheitsbaustein auch, denn der ist auf der Hauptplatine verlötet.
Gegen ein entwendetes **Gerät** schützt keiner von beiden, weil beide mitgehen. Der Token bringt
also dieselbe Wirkung und zusätzlich ein Teil, das verloren gehen, herausgezogen oder vergessen
werden kann.

**Ein Fall ist trotzdem echt und verkaufbar:** Wenn der Token **bewusst entfernt** wird — beim
Verlassen des Geländes, über Nacht, bei Außerbetriebnahme —, ist das Gerät ohne ihn nicht
startfähig. Das ist eine Eigenschaft, die in Hochsicherheitsumgebungen verlangt wird, und sie hebt
den Schutz über das hinaus, was ein verlöteter Baustein leisten kann.

> **Festlegung: Der Sicherheitsbaustein bleibt der Regelweg. Ein Token ist eine Zusatzausstattung
> für Kunden, die „startet nicht ohne Token" ausdrücklich verlangen — und dann mit der
> ausgesprochenen Folge, dass das Gerät nach einem Stromausfall nicht von allein hochkommt.**

Dieser letzte Halbsatz ist der Preis und gehört ins Datenblatt: Ein Gerät, das ohne Token nicht
startet, kann nach einem nächtlichen Stromausfall nicht selbsttätig wiederkommen — es sei denn, der
Token steckt, und dann ist man wieder beim Regelfall.

**Was gegen Token in der Fläche spricht,** unabhängig von der Sicherheit: Je Gerät ein Stück
Bestandsführung, Ersatzteile, ein weiterer Einzellieferant — und die Firmware eines Tokens lässt
sich nicht aktualisieren, eine Schwachstelle wäre also ein Austausch über den ganzen Bestand
hinweg. Bei einem Erzeugnis mit fünf Jahren Versorgungspflicht ist das ein Posten, der bedacht sein
will.

## Die verworfenen Alternativen

**Verschlüsselung als Option anbieten.** Verlockend, weil es die Entsperrung beim Start zunächst
umgeht und die Ersteinrichtung vereinfacht. Dagegen steht, dass eine Sicherheitseigenschaft, die
abschaltbar ist, im Zweifel abgeschaltet ist — und dass ein Gerät ohne sie keine verlässliche
Löschung kennt. Ein Produkt, das in Banken und Verteidigungsbereiche verkauft werden soll, kann das
nicht als Wahlmöglichkeit führen.

**Löschen durch Überschreiben.** Der vertraute Weg, und auf drehenden Platten war er richtig. Auf
Flash-Speichern ist er langsam und gibt eine Sicherheit vor, die er nicht hat.

**Auch die Wurzeln verschlüsseln.** Kostet Vertraulichkeit, die es dort nicht zu schützen gibt, und
verlegt die Entsperrung in den Startvorgang **vor** den Selbstprüflauf — womit ein Fehler dort das
Gerät unrettbar macht, statt einen Rücksprung auszulösen. Der Rückweg ist mehr wert als die
Verschlüsselung von Dateien, die auf jedem Gerät gleich sind.

---

## Nachtrag 02.09.2026 — kein Auslagerungsspeicher, und das ist eine Anforderung

Beim Bau des Tresors als Pod ist eine Bedingung sichtbar geworden, die diese Entscheidung bisher
nicht kannte und die genau ihr Schutzziel betrifft.

**Der Tresor läuft mit abgeschaltetem Speicherfestnageln** (`disable_mlock`). In einem Behälter ist
das praktisch unvermeidlich — das Festnageln verlangt ein Recht, das ein Pod im Regelfall nicht
bekommt — und mit dem eingebauten Speicher auch vertretbar. **Es hat aber eine Bedingung:**

> Ohne Festnageln darf der Arbeitsspeicher des Tresors **auf die Platte ausgelagert** werden. Das
> ist genau der Speicher, in dem die **entschlüsselten** Zugangsdaten aller Zielsysteme des Kunden
> stehen.

**Damit entstünde eine zweite, unbewachte Kopie der Geheimnisse** — außerhalb des Tresors, außerhalb
seiner Richtlinien, außerhalb der Prüfspur. Sie überlebt das Herunterfahren, und ihre Vernichtung
wäre von keiner der Regeln oben erfasst.

### Die Festlegung

> **Ein Xinion-Gerät hat keinen Auslagerungsspeicher. Das Abbild legt keinen an, und die
> Installation bietet ihn nicht an.**

Das ist keine Empfehlung und kein Feinschliff, sondern die Bedingung, unter der der abgeschaltete
Speicherfestnagel überhaupt vertretbar ist.

### Warum es hierher gehört und nicht in die Nutzlast

**Die Nutzlast kann es nicht durchsetzen.** Ein Pod bestimmt nicht, ob sein Wirt auslagert — das
entscheidet die Geräteschicht, und zwar beim Bau des Abbilds. **Eine Anforderung, die nur die
Nutzlast kennt, aber nur der Wirt erfüllen kann, ist genau die Art Lücke, die niemandem auffällt.**

### Was es kostet, und warum der Preis gering ist

**Ohne Auslagerung ist ein Speicherüberlauf ein harter Abbruch** statt einer Verlangsamung. Das
klingt schlechter, als es ist: Ein Gerät, das wegen Auslagerung zäh wird, sieht wie ein
Leistungsproblem aus und wird tagelang gesucht. **Ein abgebrochener Pod startet neu und steht im
Protokoll.**

Die Auslegung nach Baugrößen macht die Rechnung ohnehin nicht auf Auslagerung auf — die
Speicherbudgets der Pods kommen aus der Konfiguration und sind zuzuteilen, nicht zu verdrängen.

### Zwei Punkte, die daran hängen

**Der Ruhezustand des Systems** (Suspend-to-Disk) schreibt denselben Speicher auf dieselbe Platte
und ist damit aus demselben Grund ausgeschlossen. Er ist auf einem Rack-Gerät ohnehin sinnlos.

**Ein Absturzabbild des Kerns** enthält ebenfalls Arbeitsspeicher. Ob und wohin eines geschrieben
wird, ist **offen** und gehört mit derselben Überlegung entschieden — es berührt zugleich den Inhalt
des Diagnosepakets aus `ADR-0007`.

---

*Nachgetragen 02.09.2026 · Anlass: `disable_mlock` im Tresor-Pod, aufgefallen bei der Durchsicht der
Aufbauten in `XinionONE/infra` · **Die Wirkung ist nicht gemessen** — dass ein Gerät ohne
Auslagerungsspeicher unter Last sauber abbricht statt zu verklemmen, gehört auf dem Prüfgerät
gezeigt.*