Drei Produkte auf einem Fundament – und keines davon verlangt, dass Sie uns glauben. Was hier steht, rechnen Sie mit Standard-Werkzeugen selbst nach; den Einstiegspunkt dafür übergeben wir im Gespräch.
Sicherheit wird heute fast überall organisatorisch abgesichert: durch Verträge, Zertifikate, Signaturen und die Selbstauskunft des Betreibers. Beim jüngsten Angriff auf eine der größten Paket-Registries der Welt funktionierte jede dieser Maßnahmen wie vorgesehen – der Angriff lief trotzdem durch, weil er den vertrauenswürdigen Pfad selbst benutzte. Vier Bruchstellen, und sie sind überall dieselben:
Die Signatur„Das Paket ist signiert.“
Eine Signatur belegt den Absender – nicht den Inhalt. Wer die Publikations-Automatik kapert, publiziert „vertrauenswürdig“.
Der Vertrauensanker„Der Name ist bekannt.“
Vertrauensanker sind überschreibbar. Ein vertrauter Paketname kann heimlich neuen Inhalt tragen, und Historie lässt sich umschreiben.
Die Selbstauskunft„Wir haben Zugriffe dokumentiert.“
Der Betreiber beglaubigt sich selbst. Code, Auslieferung und Echtheitsnachweis liegen in einer Hand – mit Vollzugriff auf alles.
Die Erkennung„Wir haben es bemerkt.“
Erkennung kommt nach der Verteilung. Was in den Stunden davor geschah, bleibt Forensik statt Abfrage – genau dann, wenn Meldefristen laufen.
SEFETOVertrauen per Mathematik
Eine Signatur belegt den Absender. Herkunft belegt den Inhalt. Genau diesen Unterschied bauen die drei Produkte ein – Souveränität wird vom Versprechen zur Eigenschaft des Systems.
Architektur
Vom Baustein zur souveränen Plattform
Anwendungen werden auf ein versiegeltes Fundament gesetzt – vom Messenger über Code- und Paketplattform bis zur eigenen Anwendung. Was unten gebaut ist, erben oben alle.
Anwendungen & Dienste
Souveräne KommunikationSEFETO ChatMessenger, Dateien und Videotelefonie
Souveräne LieferketteSEFETO Registrynpm-Registry und apt-Archiv in einem Dienst
Souveränes Git-HostingSEFETO ForgeGit-Hosting mit Issues und Pull Requests
Re-PlatformingIhre AnwendungOffene Position – Kunden-Anwendungen ziehen auf dasselbe Fundament.
Jeder Baustein erbt automatisch die Souveränität des Fundaments.
Fundament
Souveränes Zero-Access-Fundament
Protokollebene · live
Ein versiegelter Schlüsselraum – garantiert durch Mathematik statt durch Zusicherung.
BFT-Konsens
Ein Verbund unabhängiger Rechner hält denselben Zustand. Finalisiert wird erst, wenn mindestens zwei Drittel der Knoten zum exakt gleichen Ergebnis kommen – darunter stoppt das System, statt zu fälschen.
Protokollebene · live
Threshold-Schlüssel
Der private Schlüssel entsteht ohne zentrale Stelle und wird in Anteile zerlegt – er existiert nie als Ganzes. Signieren oder entschlüsseln kann nur eine qualifizierte Mehrheit gemeinsam.
Protokollebene · live
Confidential Computing
Der Arbeitsspeicher der laufenden Anwendung soll zusätzlich gegen den privilegiertesten denkbaren Angreifer verschlüsselt werden – den Administrator des Host-Systems. Etablierte, beschaffbare Technik, heute aber nicht Teil des Betriebs.
Hardware-Ebene · Produktausbau
Die beiden tragenden Pfeiler sind gebaut und laufen: Die einzige Schicht, die man nicht kaufen kann, ist die Protokollebene. Confidential Computing ist der gestrichelte Pfeiler – etablierte, beschaffbare Hardware-Technik, die als Produktausbau im Pilotbetrieb hinzukommt und heute nichts trägt.
Zum EU-Betrieb: Der EU-Betrieb ist Eigenschaft des angebotenen Produkts; die öffentlich erreichbare Installation läuft auf global verteilten Knoten und speichert dort ausschließlich Chiffretext. Zugriff ist ausgeschlossen, weil der Betreiber – und damit auch dessen Rechtsraum – keinen Zugriff auf den Execution Layer hat.
Die Produkte
Kein Konzept, kein Prototyp.
Alle drei Bausteine laufen – sie unterscheiden sich darin, wie weit die Vermarktung gediehen ist. Der Reifegrad steht deshalb an jedem Block, damit niemand raten muss.
Fertiges Produkt · heute einsetzbar
SEFETO Chat
Ein Messenger wie gewohnt – nur für Sie sichtbar: Einzel- und Gruppenchat, Ende-zu-Ende verschlüsselte Anhänge und Videotelefonie in einer Lösung. Betrieben on-premise oder in einer Private Cloud, auf Wunsch unter Ihrer eigenen Marke.
Alle drei Ebenen zugleich: Geschützt sind Inhalt, Metadaten und Gerichtsbarkeit – klassische Messenger verschlüsseln nur den Inhalt.
Dateien gehören dazu: Große Dateien, geteilte Team-Räume, Versionen und Aufbewahrungsfristen liegen in derselben verschlüsselten Ablage – selbst die Dateinamen bleiben Chiffretext.
Auf Post-Quantum vorbereitet: Angreifer schneiden heute Verkehr mit, um ihn später zu öffnen. Die eingesetzten Verfahren sind auf die kommenden Post-Quantum-Standards migrierbar – die Architektur ist auf diesen Wechsel vorbereitet.
Live · öffentlich nachrechenbar
SEFETO Registry
npm-Registry und apt-Archiv in einem Dienst – nur fälschungssicher. Jede Auslieferung trägt ein Echtheitszertifikat mit Inhalts-Prüfsumme, das Kunden, Auditoren und Behörden selbst prüfen können, ohne dem Betreiber glauben zu müssen.
Einführung ist ein Konfigurationseintrag:npm install und apt-get funktionieren unverändert weiter; Compliance-Evidenz entsteht als Nebenprodukt des normalen Arbeitens, nicht als Sonderprojekt vor dem Audit.
Manipulation hinterlässt Spuren: Die Historie ist nur erweiterbar – ein vertrauter Paketname kann keinen heimlich neuen Inhalt tragen; stiller Austausch bricht die öffentlich prüfbare Kette.
Was noch fehlt, steht dabei: Vertraulichkeit vor dem Betreiber ist für private Pakete vorgeführt; die Ausgabe der Nachweise in die gängigen Standardformate ist der verbleibende Schritt. Eine dedizierte Registry lässt sich heute noch nicht vollständig übergeben.
Live · Teil derselben Installation
SEFETO Forge
Das zugehörige Git-Hosting: Objektspeicher, Refs, Packfiles, Issues, Pull Requests und echtes Smart-HTTP – als versiegelter Dienst auf derselben Installation wie die Registry. Damit liegen Code, Freigabe und Auslieferung in einer durchgehend prüfbaren Kette. Eine Git-Instanz lässt sich vollständig an den Kunden übergeben.
Kompatibilität gemessen, nicht behauptet: Ein unverändertes git clone und git push arbeitet direkt dagegen. Die Objekt-IDs sind gegen die git-Binärdatei geprüft, Packfiles muss git index-pack akzeptieren.
Zertifizierte Auslieferung: Jede Antwort trägt ein Zertifikat gegen den Wurzelschlüssel des Netzes; jeder Push-Stand eine portable Threshold-Signatur, offline prüfbar mit Standardwerkzeugen.
Betreiber-Blindheit: Private Repositories liegen als Chiffrat unter geblindeten Adressen; Schlüssel gehen ausschließlich an berechtigte Identitäten. Der Betreiber kann nicht mitlesen – auch nicht auf richterliche Anordnung.
Der Nachweis
Glauben Sie uns nicht. Prüfen Sie nach.
Der Nachweis hängt nicht an unserem Wort: Für die Lieferkette sind fünf Prüfwege dokumentiert, die ein Prüfer eigenständig ausführt – ohne unser Zutun, sobald er den Einstiegspunkt hat. In den Apps ist die Beweisführung fest eingebaut: echte Abfragen gegen die laufende Infrastruktur, keine Folien.
Beweis 01
„Der Betreiber kann nicht lesen.“
Der gespeicherte Zustand der Anwendung enthält ausschließlich Chiffretext; ein Zugriffsversuch von außen wird vom System selbst abgewiesen – vorgeführt in der laufenden Anwendung, nicht auf einer Folie.
Beweis 02
„Es läuft genau das, was wir sagen.“
Der laufende Programmcode wird per Prüfsumme mit dem freigegebenen Quellstand verglichen, bit-identisch; Quellcode-Einsicht und der geführte reproduzierbare Build erfolgen unter NDA. Und wer die versiegelten Container überhaupt ändern darf, beantwortet das Netzwerk kryptografisch zertifiziert.
Beweis 03
„Diese Bytes, aus dieser Quelle, unverändert.“
Ein Paket mit unverändertem npm laden, die mitgelieferte Prüfsumme lokal nachrechnen und gegen das Echtheitszertifikat halten. Zwei Minuten vom eigenen Terminal aus, ohne uns zu fragen.
Der nächste Schritt
Fünf Minuten Live-Beweis
Der Beweis läuft – aber er liegt hier bewusst nicht als Link. Welcher Einstiegspunkt der richtige ist, hängt davon ab, was Sie prüfen wollen; deshalb führen wir ihn im Gespräch vor. Keine Testkonten mit vorbereiteten Inhalten, keine geführte Reihenfolge, keine Attrappen – Sie klicken frei.
