1 / 16

freshX

NewTec

Sichere Interaktion mit Geräten im Feld

Secure Cloud
Jede Aktion signiert.
Jede Freigabe ein Mensch.

Onboarding von Servicepersonal, Provisionierung von Geräten, Firmware-Verteilung und Fernsteuerkommandos — auf einer PKI-Plattform, in der es keine Passwörter gibt und jede kritische Aktion kryptografisch von einer benannten Person freigegeben wird.

FreshX GmbH · freshx.de Umsetzung mit NewTec · newtec.de PKI · mTLS · Signatur-Workflows · 100 % Rust

Ausgangslage

Kritische Geräte im Feld — aber wer darf was? Und wer hat es freigegeben?

Fernwartung und Software-Verteilung scheitern selten an der Technik — sondern an Vertrauen und Nachweisbarkeit.

🔑 Geteilte Zugänge

VPN-Zugang plus Sammel-Passwort: Niemand weiß, welche Person wirklich am Gerät war. Passwörter werden geteilt, notiert, gephisht — und beim Ausscheiden eines Mitarbeiters selten überall rotiert.

📋 Lückenhafte Nachweise

Logdateien lassen sich editieren und beweisen nichts. Im Audit bleibt die Frage offen: Wer genau hat dieses Kommando, dieses Update, diesen neuen Nutzer autorisiert — und kann er es abstreiten?

📦 Ungesicherte Updates

Firmware wandert per USB-Stick oder ungesichertem Download aufs Gerät. Zwischen „Release freigegeben" und „läuft auf der Maschine" existiert keine durchgehende Vertrauenskette.

Die Folge: langsames, riskantes Onboarding von Technikern und Geräten, keine Nicht-Abstreitbarkeit gegenüber Auditoren — und ein Sicherheitsmodell, das mit jedem geteilten Passwort weiter erodiert.

Die Lösung im Überblick

Eine Plattform: Identitäten, Freigaben, Kommandos, Firmware

BEDIENUNG Manager-Konsole Authenticator-App Secure-Cloud-Server (CA) Geräte & Maschinen Trust Store · isoliert Browser · Assets, Rollen, Nutzer, Zertifikate, QR-Tools iOS & Android · prüfen, freigeben, signieren · mTLS-API — nur mit Client-Zertifikat · Enrollment-API für neue Identitäten · Datenbank: jede Zeile signiert · Nachrichten-Queue, store-and-forward · Push-Dienst (APNs / FCM) · Sperrlisten (CRL), live verteilt · Berechtigungsprüfung aus dem Zertifikat SDKs: Rust · C · Node.js · Python empfangen signierte Kommandos und Hash-gepinnte Firmware melden Ergebnisse signiert zurück besitzt den Zertifikats-Schlüssel — verbindet sich nur ausgehend, kein offener Port mTLS mTLS · signieren Push-Benachrichtigung signierte Nachrichten stellt Zertifikate aus
Der internetzugewandte Server besitzt den signierenden CA-Schlüssel nie: Zertifikate stellt ein isolierter Trust Store aus, der sich ausschließlich ausgehend verbindet — Signierfähigkeit kann in einem eigenen Netzsegment ohne eingehende Ports leben.

USP · Identität statt Passwort

Keine Passwörter. Identität ist ein Zertifikat.

  • mTLS überall: Alle privilegierten Operationen laufen ausschließlich über beidseitiges TLS mit Client-Zertifikat. Ohne Zertifikat existiert die API praktisch nicht.
  • Doppelte Bindung: Das TLS-Zertifikat und die Signatur auf der Nutzlast müssen zur selben Identität gehören — ein gestohlenes Zertifikat allein ist wertlos, der private Schlüssel wird immer mitgeprüft.
  • Berechtigungen reisen im Zertifikat: Die Rechte einer Identität sind CA-signiert direkt ins X.509-Zertifikat eingebettet. Es gibt keine umgehbare Berechtigungs-Datenbank.
  • Widerruf wirkt sofort: Sperrlisten werden an der TLS-Schicht erzwungen und live an alle Clients verteilt — ein widerrufenes Zertifikat kommt nicht mehr durch den Handshake.
  • Vertrauensanker einkompiliert: Root- und CA-Zertifikat stecken zur Bauzeit in den Client-Bibliotheken — niemand kann einen Client auf eine fremde CA umbiegen.
  • Bereit für Hardware-Schlüssel: Das Schlüssel-Backend ist austauschbar — die Anbindung von TPM/HSM ist architektonisch vorgesehen und wird mit der ersten Kundenanforderung umgesetzt.
Root-Zertifikat Intermediate-CA Nutzer Dienste Geräte offline verwahrt nur im isolierten Trust Store Techniker, Manager Konsole, Backends Maschinen, Telefone
Berechtigungen im Zertifikat — Beispiel:
control.startup : train.4021 : ausführen msg.push.control.* : * : ausführen+delegieren ca.cert.create : * : ausführen

Onboarding & Provisionierung

Neuer Techniker, neues Gerät: ein QR-Code, vier Wörter, fertig

Menschen, Dienste und Maschinen sind dasselbe: Identitäten mit Zertifikat. Ein Verfahren deckt alle Fälle ab.

1 · Identität anlegenOperator wählt Namen & Rollen im Manager — die Anfrage signiert er selbst per Telefon-Freigabe
→
2 · QR + EinmalpasswortDer neue Nutzer erhält einen QR-Code und ein Einmalpasswort aus vier Wörtern — einmal gültig, danach verbrannt
→
3 · Schlüssel entsteht auf dem GerätTelefon/Gerät erzeugt das Schlüsselpaar lokal — der private Schlüssel verlässt das Gerät nie
→
4 · Zertifikat ausgestelltDie CA signiert den Antrag; die Berechtigungen stecken im Zertifikat. Status live im Manager sichtbar

Niemand vergibt mehr, als er hat

Beim Anlegen prüft die CA kryptografisch: Der Operator muss jedes einzelne Recht, das er vergibt, selbst mit Delegations-Stufe besitzen. Rechte-Eskalation ist konstruktiv ausgeschlossen.

Vorschau vor der Entscheidung

„Was gewähren diese Rollen?" — der Manager zeigt die zusammengeführten Rechte, bevor der Nutzer angelegt wird. Wildcard-Rechte werden farblich hervorgehoben.

Offboarding in einem Klick

Zertifikat suchen (Name, Fingerprint oder PEM), widerrufen — die Sperrliste verteilt sich automatisch, der Zugang ist sofort und überall tot.

Asset-Management

Nutzer, Geräte, Rollen, Rechte — ein Modell, alles signiert

🧩 Feingranulare Berechtigungsalgebra

Jedes Recht ist ein Tripel Aktion : Ziel : Stufe — etwa „darf das Kommando startup an Fahrzeug 4021 senden". Hierarchische Wildcards (control.*) und drei Stufen: Ausführen, Delegieren, beides.

🗂 Rollen & Privilegien

Ein Privileg bündelt Rechte, eine Rolle bündelt Privilegien, ein Nutzer trägt Rollen — verwaltet im Manager mit Berechtigungs-Matrix, Validierung in Echtzeit und Rechte-Vorschau über mehrere Rollen hinweg.

✍️ Jede Änderung trägt eine Unterschrift

Rollen, Privilegien, Assets und Zuordnungen werden einzeln signiert gespeichert — die Oberfläche zeigt zu jedem Eintrag, wer ihn signiert hat. Gelöscht wird weich: Historie bleibt erhalten.

📱 Zertifikate & Geräte im Blick

Zertifikats-Suche per Name, Fingerprint oder PEM-Upload; Sperrlisten-Browser mit Export; registrierte Authenticator-Geräte pro Nutzer mit Plattform und Zuletzt-gesehen — Verknüpfung per Klick lösbar.

Assets mit Versionierung hierarchische Namensräume Ablaufdaten Glob-Filter Wildcard-Rechte werden farblich markiert

USP · Vier-Augen-Prinzip eingebaut

Kritische Aktionen gibt ein Mensch frei — auf seinem eigenen Gerät

  • Umleitung an eine Person: Jeder Befehl kann „zur Signatur durch N.N." gestellt werden. Die CA führt nichts aus — sie schickt eine Push-Nachricht und wartet auf das von dieser Person signierte Kommando.
  • Sehen, was man signiert: Ziel, Kommando, Nutzlast, anfragender Nutzer samt Zertifikats-Fingerprint — alles sichtbar, bevor der Finger auf „accept" geht.
  • Biometrisch gesichert: Face ID, Fingerabdruck oder Geräte-PIN vor jeder Freigabe.
  • Ablehnen ist eine Antwort: Ein „reject" meldet dem Anfragenden sofort und explizit die Ablehnung — kein stilles Verpuffen.
  • Vier Augen ohne Passwort-Weitergabe: Wer ein Recht nicht besitzt, lässt die Aktion vom Kollegen signieren, der es hat — nachvollziehbar, wer angefragt und wer freigegeben hat.

Fernsteuerung

Kommandos mit Berechtigung pro Gerät — und Freigabe pro Kommando

1 · SendenOperator schickt control.startup an Fahrzeug 4021 — aus der Konsole, dem SDK oder der CLI
→
2 · PrüfenDie CA liest die Berechtigung direkt aus dem Zertifikat des Absenders: Darf er dieses Kommando an dieses Gerät senden?
→
3 · FreigebenOptional wird ein Freigeber per Push einbezogen — er prüft Ziel, Kommando und Nutzlast und signiert auf dem Telefon
→
4 · ZustellenDas Gerät holt das signierte Kommando aus seiner Queue und verifiziert Signatur und Zertifikatskette vor der Ausführung

Eigene Kommandotypen

Kommandos sind benannte, signierte Nachrichten mit freiem JSON-Inhalt. Neue Kommandoarten definieren Sie selbst — ohne Änderung an der Plattform. Die Berechtigung folgt dem Namen, hierarchisch mit Wildcards.

Zielgenau statt pauschal

Die Berechtigung nennt das Gerät: „startup an Fahrzeug 4021" ist ein anderes Recht als „startup an alle". Ein Wartungsdienstleister bekommt exakt seine Flotte, nicht das Netz.

Funkloch eingeplant

Nachrichten sind store-and-forward: Ein offline-Gerät bekommt seine Kommandos, sobald es wieder verbunden ist — signiert und in Reihenfolge. Auch die Freigabe darf warten, bis der Freigeber sein Telefon zur Hand hat.

USP · Offline-Fähigkeit

Kein Netz? Der Signatur-Workflow läuft trotzdem

Die Sicherheit steckt in der Signatur, nicht im Kanal — deshalb ist der Transportweg frei wählbar. Beispiel: Factory-Reset eines Geräts vor Ort.

1 · Anfrage als QR-CodeKonsole oder Servicetool rendert die Signatur-Anfrage als QR — z. B. „Factory-Reset für Gerät XY"
→
2 · Mit der App scannenDie Authenticator-App verifiziert die Signatur der Anfrage und zeigt Ziel, Kommando und Anfragenden
→
3 · FreigebenBiometrisch bestätigen — die App signiert mit dem persönlichen Schlüssel des Freigebers
→
4 · FertigDas Gerät prüft Signatur und Zertifikatskette und führt aus — ohne dass es je online war

📦 Kommandos offline transportieren

Signierte Kommandopakete lassen sich inklusive aktueller Sperrliste (CRL) offline transportieren — per QR-Code, Datei oder Service-Laptop. Das Zielgerät prüft Signatur, Zertifikatskette und Widerrufe vollständig ohne Verbindung.

🔁 Der Kanal ist egal — die Signatur zählt

Ende-zu-Ende-Signaturen statt Kanalvertrauen: Ob mTLS, QR-Code oder Datenträger — ein manipuliertes Kommando fällt bei der Prüfung durch, unabhängig davon, wie es zum Gerät gelangt ist.

Software-Lifecycle

Firmware: vom Release bis aufs Gerät in einer Vertrauenskette

Die Freigabe eines Updates ist die Signatur. Zwischen Release-Entscheidung und laufender Firmware gibt es keinen unsignierten Schritt.

1 · Release freigebenEine berechtigte Person signiert den Verteilauftrag: Download-URL plus SHA-256-Hash je Datei — Freigabe per Telefon
→
2 · EnrollmentDer signierte Auftrag wandert in die Queues der Zielgeräte — gezielt pro Gerät oder Gruppe, gesteuert über das Berechtigungsmodell
→
3 · Gerät verifiziertDas Gerät prüft die Signatur, lädt das Artefakt und hasht beim Schreiben mit — bei Abweichung wird die Datei gelöscht und Fehler gemeldet
→
4 · BestätigungErfolg wird mit Hash, Pfad und Größe zurückgemeldet — der Rollout-Status ist belegbar, nicht vermutet

🌐 Der Datei-Server braucht kein Vertrauen

Das Artefakt kann auf jedem CDN, Webserver oder Object Store liegen: Der Hash im signierten Auftrag pinnt den Inhalt. Ein manipuliertes oder vertauschtes Artefakt wird vom Gerät verworfen — egal, wie kompromittiert der Transportweg ist.

🎯 Rollout folgt dem Rechtemodell

Wer Updates an welche Geräte verteilen darf, ist ein Zertifikats-Recht wie jedes andere — inklusive Vier-Augen-Freigabe. Staffel-Rollouts (erst Testgeräte, dann Flotte) sind eine Frage der Zieladressen, nicht der Infrastruktur.

Sicherer Login

Anmeldung ohne Passwort: der Browser zeigt, das Telefon signiert

1 · Browser öffnet die KonsoleEs gibt kein Login-Formular — die Seite zeigt einen QR-Code für die neue Sitzung
2 · Telefon scannt und prüftDie App zeigt, wer hier wofür eine Anmeldung anfragt — und signiert die Sitzung nach biometrischer Bestätigung
3 · Sitzung wird aktivDie signierte Login-Nachricht läuft über die CA an die Konsole; der Browser ist angemeldet — als die Person, deren Schlüssel signiert hat
  • Nichts zu phishen: Es existiert kein Passwort, kein TOTP-Seed, kein Wiederherstellungscode. Die Anmeldung ist eine Gerätesignatur.
  • Kein Token im Browser: Nur ein HttpOnly-Sitzungscookie, strikt an die Seite gebunden — für JavaScript unsichtbar, nichts in localStorage.
  • Sitzung gehört einer Person: Jede Aktion in der Konsole wird anschließend über deren Telefon signiert — die Konsole selbst kann ohne den Menschen nichts.
  • Dasselbe Verfahren für Ihre Anwendungen: Der QR-Login ist Teil der Plattform — auch Ihre eigenen Portale können ihn nutzen.

USP · Manipulationssichere Datenhaltung

Ein Audit-Trail, den man nicht editieren kann

  • Jede Zeile einzeln signiert: Assets, Rollen, Privilegien, Zuordnungen und Nachrichten tragen die Signatur der Person oder des Dienstes, der sie erzeugt hat.
  • Integritätsprüfung beim Start: Der Server verifiziert beim Hochfahren jede Signatur samt vollständiger Zertifikatskette jedes Signierers — eine manipulierte Zeile stoppt den Start.
  • Prüfbar auf Kommando: Ein CLI-Befehl re-verifiziert die komplette Datenbank jederzeit — für Audits, forensische Fragen oder einfach zur Beruhigung.
  • Zukunftssichere Signaturen: Datenstrukturen sind feld-versioniert — eine Signatur von vor drei Jahren bleibt auch nach Software-Updates prüfbar.
  • Sichtbar im Alltag: Die Manager-Oberfläche zeigt zu jedem Eintrag „signiert von" — Nachvollziehbarkeit ist kein Report, sondern eine Tabellenspalte.

Nicht abstreitbar — im Wortsinn

Klassische Audit-Logs beweisen wenig: Wer die Datenbank administriert, kann sie ändern. Hier ist der Zustand selbst die Urkunde — jede Zeile gegen die PKI prüfbar, jede Freigabe mit dem persönlichen Schlüssel einer benannten Person signiert, deren Zertifikat auf Nicht-Abstreitbarkeit ausgestellt ist.

Im Code verankert: Ein automatisierter Test manipuliert eine Datenbankzeile und stellt sicher, dass die Integritätsprüfung genau dann fehlschlägt.

Die Authenticator-App

Der Schlüsselbund Ihrer Organisation — in der Hosentasche

🔐 Schlüssel bleibt auf dem Gerät

Das Schlüsselpaar entsteht auf dem Telefon und wird nie übertragen — kein Server-Backup, keine Kopie, kein Geheimnis im QR-Code. Jede Freigabe erfordert Face ID, Fingerabdruck oder Geräte-PIN.

📷 Verknüpfung offline verifiziert

Der Provisionierungs-QR einer Instanz ist von einer in die App einkompilierten CA signiert und wird ohne Netzwerk geprüft. Ein gefälschter QR-Code, der auf eine fremde Instanz zeigt, wird abgelehnt.

🏢 Mehrere Instanzen, eine App

Beliebig viele Secure-Cloud-Instanzen — Produktion, Test, zweiter Standort — jede mit eigener Identität, eigener Warteschlange und sichtbarem CA-Fingerprint. Wechsel in zwei Taps.

🤖 Auto-Freigabe mit Leitplanken

Wiederkehrende Kommandos einer Quelle lassen sich automatisch freigeben — biometrisch aktiviert, auf genau diese Quelle beschränkt, und der Modus erlischt, sobald der Bildschirm ausgeht. Jede Auto-Freigabe wird auf dem Gerät protokolliert.

📶 Funkloch-fest

Die Kommando-Warteschlange überlebt Neustarts und Verbindungsabbrüche; die App verbindet sich selbstständig neu und meldet Ausfall und Wiederherstellung genau einmal — nicht im Sekundentakt.

🌍 Für den Feldeinsatz gebaut

iOS und Android aus einem Rust-Kern — demselben, der auch auf dem Server läuft. Drei Sprachen (Deutsch, Englisch, Chinesisch), Push-Benachrichtigung bei jeder wartenden Freigabe.

Betrieb & Integration

Eine Instanz pro Kunde — isoliert, versioniert, in Minuten bereit

🏗 Strikte Mandantentrennung

Jeder Kunde erhält eine eigene Instanz mit eigener PKI, eigenem Geheimnis-Speicher und eigenen Domains. Die CA-Schlüssel entstehen direkt in der Zielumgebung — sie berühren nie den Rechner eines Administrators.

🚀 Ein Klick zur neuen Instanz

Instanzen werden aus einem vorbereiteten Pool per Knopfdruck erzeugt — jede Änderung ist ein Git-Commit mit Urheber und Zeitstempel, jede Instanz auf exakte Versionen gepinnt, Updates per Klick.

📦 Onboarding-Paket inklusive

Pro Instanz ein fertiges Kundenpaket: Zertifikate, signierter Provisionierungs-QR für die App, lauffähige Beispiele und offline installierbare Client-Bibliotheken — Endpunkte bereits eingetragen.

🧰 SDKs für Ihre Systeme

Rust, C (über FFI), Node.js und Python plus CLI — alle als dünne Schicht über demselben geprüften Rust-Kern, für Linux, macOS und Windows. Vom Embedded-Controller bis zum Backend-Skript spricht alles dieselbe Sprache.

🖥 Flexibles Deployment

Container für Kubernetes oder Compose, alternativ RPM-Pakete mit systemd-Units für den Betrieb im eigenen Rechenzentrum. Statisch gelinkt, ohne Laufzeit-Abhängigkeiten; Images enthalten weder Schlüssel noch Zertifikate.

🔔 Push eingebaut

Benachrichtigungen an iOS (APNs) und Android (FCM) sind Teil der Plattform — wartende Freigaben erreichen die richtige Person auf allen registrierten Geräten.

🏅 Zertifizierter Betrieb, zertifizierter Partner: Der Betrieb erfolgt in einem ISO-27001-zertifizierten Rechenzentrum. Umgesetzt wurde die Plattform gemeinsam mit NewTec (newtec.de) — dem zertifizierten Spezialisten für sicherheitskritische Systeme.

Warum Secure Cloud

Die Plattform in Zahlen

0Passwörter im gesamten System
0Zeilen unsicherer Code — 100 % Rust, unsafe verboten
3PKI-Ebenen · Root offline, CA-Schlüssel isoliert
100 %der Datenbank-Zeilen signiert & prüfbar
4+1SDKs: Rust, C, Node.js, Python + CLI
2Faktoren je Aktion: Zertifikat + Signatur

Nicht abstreitbare Freigaben

Jede Aktion trägt die persönliche Signatur einer benannten Person — prüfbar gegen die PKI. Kein „irgendein Admin war's", sondern Beweis statt Logfile.

Rechte reisen im Zertifikat

Autorisierung ist kryptografisch an die Identität gebunden, feingranular bis auf Kommando × Gerät — und per Sperrliste sofort widerrufbar.

Sicherheit, die bedienbar bleibt

QR-Code statt Formular, vier Wörter statt Zertifikats-Bürokratie, Freigabe per Fingertipp. Das sichere Verfahren ist hier auch das bequemste.

freshX

NewTec

„Softwareentwicklung ist in erster Linie
Vertrauenssache."

Lassen Sie uns darüber sprechen, wie Ihre Geräteflotte, Ihre Techniker und Ihre Firmware in eine durchgehende Vertrauenskette kommen.

FreshX GmbH freshx.de dominik@freshx.de Umsetzungspartner: NewTec · newtec.de