Payload-Signierung

Jede Payload, die FortressFlag an eine deiner Apps schickt, trägt eine Signatur, und jedes SDK prüft sie, bevor sich auch nur ein Flag-Wert ändert. Du musst dafür nichts tun — die SDKs kommen mit dem eingebauten öffentlichen Produktionsschlüssel und verifizieren standardmäßig. Diese Seite erklärt, was dir das bringt, was die zwei Policy-Einstellungen bedeuten und welchen Schlüsseln deine Apps heute vertrauen.

Was signiert wird, und warum

Wenn deine App abfragt, antwortet FortressFlag mit zwei Dingen: der Payload (die Flag-Werte deines Geräts auf der Client-Plane, das vollständige Ruleset auf der Server-Plane) und einer Signatur über die exakten Bytes dieser Payload. Die Signatur entsteht mit einem privaten Schlüssel, den nur FortressFlag hält; dein SDK prüft sie mit dem passenden öffentlichen Schlüssel, der mitgeliefert wurde.

Wurden die Bytes irgendwo zwischen unseren Servern und deiner App verändert — ein Proxy, ein CDN, eine Cache-Datei, die jemand auf dem Gerät bearbeitet hat — schlägt die Prüfung fehl und das SDK ignoriert die Antwort. Es liefert weiter die zuletzt verifizierten Werte (siehe das Fallback-Versprechen), statt Bytes zu vertrauen, für die es nicht bürgen kann.

Zwei Dinge, die die Signatur nicht tut, damit sich niemand zu sehr auf sie verlässt:

Sie verbirgt nichts. Die Payload ist nicht verschlüsselt — ein Client-Schlüssel ist by design öffentlich, und alles, was gegen ihn ausgeliefert wird, ebenso. Leg keine Geheimnisse oder personenbezogenen Daten deiner Nutzer in Regeln.
Sie ersetzt TLS nicht. Die SDKs sprechen außerdem über HTTPS mit FortressFlag; die Signatur ist das zweite Schloss, für die Teile des Wegs, die TLS nicht abdeckt (Caches, Speicher auf dem Gerät).

Die zwei Policies

Jedes SDK hat eine Signatur-Policy mit zwei Einstellungen:

required — der Standard. Das SDK verifiziert jede Payload gegen seine vertrauenswürdigen Schlüssel und weist alles ab, was unsigniert ist, mit einem ihm unbekannten Schlüssel signiert wurde oder über andere Bytes signiert ist. Das willst du in jedem Build, der mit FortressFlag spricht.
disabled — unsignierte Payloads akzeptieren. Es gibt sie für genau eine Situation: den Betrieb gegen ein lokales FortressFlag-Backend, in dem kein Signierschlüssel konfiguriert ist. Sie ist eine benannte, greppbare Einstellung statt eines stillen Fallbacks, damit „warum verifiziert das nicht?“ immer eine Antwort in deinem eigenen Quellcode hat. Liefere niemals einen Produktions-Build damit aus.

Dazwischen gibt es keinen „Warn“-Modus. Eine Payload verifiziert, oder sie wird ignoriert.

Die Schlüssel, denen deine Apps vertrauen

FortressFlag signiert mit einem Schlüssel pro Umgebung, und die SDKs vertrauen ab Werk nur dem Produktionsschlüssel. Wenn du gegen Staging (fortressflag.net) testest, füge den Staging-Schlüssel explizit zu den vertrauenswürdigen Schlüsseln deines SDKs hinzu.

Umgebung	Schlüssel-ID	Öffentlicher Schlüssel (base64url)
Produktion (`fortressflag.com`)	`prod-2026-09-k1`	`EaEF8MHNu3onHxemTg3-OcrKrq7ODsZIVEp-IVV2ojg`
Staging (`fortressflag.net`)	`staging-2026-09-k1`	`RHFhzt8i3hQ4NKv_IrB92YuXmyNfDXx8eWN8cOrEBc8`

Dieselben Schlüssel als rohe Bytes, in Hex, falls deine Konfiguration das erwartet:

prod-2026-09-k1     11a105f0c1cdbb7a271f17a64e0dfe39cacaaeaece0ec648544a7e215576a238
staging-2026-09-k1  447161cedf22de143834abff22b07dd98b979b235f0d7c7c79637c70eac405cf

Jeder Schlüssel ist ein öffentlicher 32-Byte-Ed25519-Schlüssel. Die Schlüssel-ID ist der mittlere Teil jeder Signatur (ed25519:prod-2026-09-k1:…) — daran erkennt das SDK, mit welchem Schlüssel es prüfen muss. Diese Werte sind öffentlich — du kannst sie ohne Bedenken in eine Konfigurationsdatei oder ein Repository einfügen.

Rotation

Wenn FortressFlag einen Schlüssel rotiert, kommt der neue öffentliche Schlüssel zuerst in einem SDK-Release, und wir beginnen erst damit zu signieren, wenn die SDKs im Feld ihm vertrauen. Eine Rotation zwingt dich nie, eine App bis zu einem Stichtag zu veröffentlichen: Ein SDK, das dem alten und dem neuen Schlüssel vertraut, verifiziert die ganze Zeit weiter.

Wenn du im Web bist

Das Web-SDK verifiziert mit der eingebauten Web Crypto deines Browsers. Das braucht Ed25519-Unterstützung — Safari 17+, Chrome 137+, Firefox 130+ — und einen Secure Context: https://-Seiten und http://localhost. Auf einer reinen http://-Seite, die etwa von einer LAN-Adresse ausgeliefert wird, stellen Browser Web Crypto gar nicht erst bereit.

Wo der Browser nicht verifizieren kann, tut das SDK nicht so, als hätte es das, und wirft auch keinen guten Cache weg. Es meldet die Payload als nicht verifizierbar, liefert weiter seine zuletzt verifizierten Werte oder die Standards deines Codes und loggt den Grund einmal. Liefere deine App über HTTPS aus, und das Thema kommt nie auf.

Wie geht es weiter?

Wie Flags deine App erreichen — die zwei Planes und das Fallback-Versprechen unter beiden
Schlüssel — warum ffc_ öffentlich ist und ffs_ ein Geheimnis