.png){kind=logo}
Schützen Sie das Herzstück Ihres 5G-Netzes
Im 5G Core werden Identitäten authentifiziert, Sessions gesteuert und Policies durchgesetzt. Dabei sind sensible Daten und Schlüsselmaterial während der Verarbeitung exponiert. enclaive schützt Core Network Functions deshalb in hardwareisolierten Confidential-Computing-Umgebungen und gibt Schlüssel nur an attestierte Workloads frei.
KUBERNETES-NATIV · KEINE ÄNDERUNGEN AM CODE DER NETWORK FUNCTIONS · AUSGEWÄHLT FÜR DIE NATO DIANA COHORT 2026
Der Core muss auf alles zugreifen – und das ist das Problem
Der 5G Core ist die softwarebasierte Schaltzentrale des Netzes. AMF, SMF, UDM/AUSF und weitere Network Functions steuern Authentifizierung, Mobilität, Sessions und Policies, während die UPF den User Plane Traffic verarbeitet. In modernen Deployments laufen diese Funktionen häufig containerisiert auf Kubernetes.
Damit Core Network Functions ihre Aufgaben erfüllen können, müssen sie sensible Identitäten, Zustände und kryptografisches Material während der Verarbeitung im Arbeitsspeicher verfügbar halten. In klassischen Architekturen gehört die Host- und Virtualisierungsschicht zur Vertrauensgrenze. Weitreichende Infrastrukturrechte können dadurch auch zum Zugriffs- und damit Angriffspfad auf sensible Laufzeitdaten werden.
Festplattenverschlüsselung schützt Data at Rest, TLS schützt Data in Transit. Während der Verarbeitung im Core liegen sensible Daten jedoch im Arbeitsspeicher vor. Genau diese Data-in-Use-Lücke adressiert Confidential Computing.
Bei einem 5G Core reicht es nicht, Sicherheit nur organisatorisch oder vertraglich abzusichern. Entscheidend ist, ob sich die Integrität laufender Core Functions technisch überprüfen lässt – ohne darauf vertrauen zu müssen, dass Infrastruktur- und Softwareanbieter ihre privilegierten Zugriffswege nicht missbrauchen oder kompromittiert werden.
Zwei Schutzebenen greifen ineinander: Confidential Computing isoliert die Core Workloads von der darunterliegenden Infrastruktur. CDas vHSM gibt Schlüssel nur an Network Functions frei, die ihren vertrauenswürdigen Zustand per Attestation nachweisen.
AMF, SMF, UPF, UDM, AUSF und weitere containerisierte Network Functions laufen in hardwareisolierten Confidential-Computing-Umgebungen. Der Arbeitsspeicher wird während der Ausführung geschützt, sodass Host-Betriebssystem und Hypervisor keinen regulären Klartextzugriff erhalten. Änderungen am Code der Core Network Functions sind nicht erforderlich.
Langfristige Teilnehmerschlüssel, sessionbezogenes Schlüsselmaterial und Zertifikate lassen sich in einem cloud-nativen, skalierbaren HSM schützen, das selbst in einer abgeschotteten Umgebung läuft. Eine Network Function erhält benötigtes Schlüsselmaterial erst, wenn ihre Identität und ihr attestierter Zustand den festgelegten Policies entsprechen.
Remote Attestation macht kryptografisch überprüfbar, ob eine Core Function in der erwarteten Hardware- und Softwareumgebung läuft. Betreiber, Prüfer oder Partner können den gemessenen Zustand gegen definierte Referenzwerte und Policies verifizieren. Heißt: Technische Nachweise statt bloßer Zusicherungen.
Die Architektur fügt sich in gängige Kubernetes-Distributionen wie SUSE Rancher Prime RKE2 oder Red Hat OpenShift ein. Das bestehende Orchestrierungsmodell bleibt erhalten. Eine Referenzimplementierung mit Open5GS zeigt das Schutzmodell Ende zu Ende – einschließlich geschützter Subscriber-Datenbanken.
Das Whitepaper zeigt das vollständige Open5GS-Referenzdeployment auf SUSE Rancher RKE2 und Red Hat OpenShift: geschützte Network Functions, Key Management im vHSM, den Attestation-Flow und die Architektur bis hin zur geschützten Teilnehmerdatenbank.
Dasselbe Confidential-Computing-Modell lässt sich vom zentralen Telco Core bis zum portablen 5G-System einsetzen. Das Grundprinzip bleibt gleich: Core Functions und sensibles Schlüsselmaterial werden von der zugrunde liegenden Infrastruktur abgeschottet.
Core Functions laufen auf Hyperscalern oder europäischen Cloud-Plattformen, während Cloud-Betreiber, Host-System und Hypervisor außerhalb der Vertrauensgrenze bleiben.
Fabriken, Häfen, Krankenhäuser oder Energieversorger betreiben Private 5G unter Anforderungen wie NIS2 und DSGVO. Confidential Computing ermöglicht dabei eine unabhängig überprüfbare Vertrauensbasis und schützt sensible Teilnehmerdaten.
Offshore-Plattformen, abgelegene Industriestandorte oder portable „5G-in-a-box“-Systeme laufen auf Hardware, die verloren gehen, gestohlen oder beschlagnahmt werden kann. Geschützte Workloads und attestationsgebundene Schlüssel erschweren den Zugriff auf sensible Daten auch bei physischem Zugriff.
Für Einsätze in umkämpften Umgebungen, Coalition Attestation und Anforderungen an klassifizierte Informationen gelten besondere Schutzanforderungen. Diese Szenarien erläutern wir in vertraulichen Briefings.
Request a briefing →
Entwickelt für höchste Schutzanforderungen
enclaive wurde als eines von 150 Unternehmen für das NATO DIANA Challenge Programme 2026 ausgewählt – im Bereich Advanced Communication Technologies mit einer resilienten Post-Quantum-5G-Infrastruktur für umkämpfte Gebiete und Katastrophenszenarien.
Erkenntnisse aus der Arbeit von enclaive im EC2-Forschungsprogramm der Cyberagentur fließen direkt in die Confidential-5G-Architektur ein. Im EC2-Programm forscht enclaive gemeinsam mit der Universität Aarhus an TEE-basierten Ansätzen für Secure Multi-Party Computation.
Im Rahmen des NATO-DIANA-Programms arbeitet enclaive mit dem VTT Dual-Use LaunchPad in Finnland zusammen und entwickelt Lösungen mittels angewandter Forschung und dem finnischen Technologie- und Telekommunikationsökosystem.
Verschlüsselte Kommunikation kann bereits heute zum Ziel von „Harvest now, decrypt later“ werden. Ein optionales PQC-Modul ergänzt Core und vHSM-Stack um NIST-standardisierte Post-Quantum-Verfahren für Schlüsselaustausch und kryptografische Authentisierung. Die Verfügbarkeit unterliegt den jeweils geltenden Exportkontrollvorschriften.
Ein geschützter Core entsteht aus dem Zusammenspiel dieser Komponenten – für abgeschottete Workloads, geschütztes Schlüsselmaterial und überprüfbare Integrität.
Containerisierte Core Functions laufen in hardwareisolierten Environments auf gängigen Kubernetes-Distributionen.
Langfristige Schlüssel, Session-Schlüsselmaterial und Zertifikate liegen im softwarebasierten vHSM und werden nur nach erfolgreicher Attestation freigegeben.
Geschützte VMs bilden die Confidential-Computing-Schicht für portable und Remote-Deployments – optional mit Post-Quantum-fähiger Kryptografie.
Core-Deployments über Cloud, On-Premises und portable Umgebungen hinweg steuern – mit Attestation pro Network Function.
Was Netzwerkarchitekten wissen wollen
Funktioniert das mit unserem 5G-Core-Anbieter?
Der Schutz greift auf der Runtime-Ebene. Containerisierte Network Functions laufen ohne Änderungen am Core-Code in geschützten Umgebungen – das Modell ist damit grundsätzlich herstellerunabhängig. Das Referenzdeployment zeigt den Ansatz Ende zu Ende mit Open5GS; kommerzielle Core-Stacks lassen sich nach demselben Prinzip integrieren, sofern die technischen Voraussetzungen erfüllt sind.
Was bedeutet das für die Latenz – besonders bei der UPF?
Die Speicherisolierung erfolgt hardwarebasiert in der CPU. Bei Control-Plane-Funktionen ist der zusätzliche Overhead in der Regel gering. Für die UPF hängt die Performance dagegen stark von Traffic-Profil, Hardwaregeneration und Deployment ab.
Welche Hardware brauchen On-Premises- oder portable Deployments?
Erforderlich sind Server mit unterstützter Confidential-Computing-Hardware. Das gilt für private und portable Deployments ebenso wie für integrierte 5G-Systeme. In Public Clouds stehen entsprechende Instanztypen bereits bei großen Anbietern zur Verfügung.
Welche Kubernetes-Distributionen werden unterstützt?
Die Lösung integriert sich als Erweiterung in bestehende Kubernetes-Umgebungen, darunter SUSE Rancher Prime RKE2 und Red Hat OpenShift sowie weitere Standard-Distributionen. Die vorhandene Orchestrierung bleibt dabei bestehen.
Können Prüfer oder Partner den Core unabhängig verifizieren?
Ja. Remote Attestation erzeugt kryptografisch überprüfbare Informationen über den gemessenen Zustand der Ausführungsumgebung. Autorisierte Betreiber, Prüfer oder Partner können diese gegen definierte Referenzwerte und Policies prüfen – statt sich allein auf vertragliche Zusicherungen zu verlassen.
Wir haben Defense- oder Classified-Anforderungen. Wie gehen wir vor?
Solche Szenarien besprechen wir in einem vertraulichen Briefing. Taktische Deployments, Coalition Attestation und Anforderungen an klassifizierte Informationen behandeln wir bewusst nicht im Detail auf der Website.
Schützen Sie Ihren 5G-Core
Sagen Sie uns, wie Ihr Deployment aussieht – Cloud Core, Private 5G oder portabel – und welchen Core-Stack Sie einsetzen. Wir zeigen Ihnen, wie ein geschützter Core auf Ihrer Infrastruktur umgesetzt werden kann.
