Wie wir ein Offline-zu-Cloud-KI-Relay mit Bluetooth und GPT-4o gebaut haben

In hochsicheren Unternehmensumgebungen - wie Handelsräumen im Finanzsektor, sensiblen F&E-Labors und verteidigungsnahen Einrichtungen - ist es Workstations häufig untersagt, auf das öffentliche Internet zuzugreifen. Obwohl dieses „Air-Gapping“ (physische Trennung vom Internet) oder eine strikte Netzwerksegmentierung das Risiko von Datenabflüssen verringert, macht es moderne, in der Cloud gehostete Large Language Models (LLMs) völlig unzugänglich. Ingenieure und Analysten sind von Tools wie GPT-4o von OpenAI abgeschnitten, was die Produktivität einschränkt.

Seven Labs wurde beauftragt, genau diesen Engpass für einen Kunden zu lösen, der in einer stark eingeschränkten Netzwerkzone arbeitet. Die Anforderung war klar: Ermöglichen Sie es Workstations in einem internetfreien Segment, sicher Abfragen an Cloud-basierte LLMs zu senden, ohne die Firewall-Richtlinien der Workstations zu ändern oder nicht autorisierte Hardware wie Wi-Fi-Dongles einzuführen.

Unsere Lösung war das Bluetooth AI Relay - eine Edge-zu-Cloud-Brücke, die lokale PC-Anfragen über ein Android-basiertes RFCOMM-Relay unter Verwendung von Standard-Bluetooth-Protokollen an GPT-4o weiterleitet. Hier ist die technische Analyse, wie wir dieses System in der Praxis entworfen, implementiert und gehärtet haben.

1. Systemarchitektur: Die Edge-zu-Cloud-Brücke

Die Architektur besteht aus drei Kernkomponenten:

1. Der Client (Offline-PC): Ein lokaler Dienst, der auf der Workstation läuft und eine Loopback-API (z. B. http://localhost:8080/v1/chat/completions) bereitstellt, die der Standard-OpenAI-API-Spezifikation entspricht.
2. Das Relay (mobiles Android-Gerät): Eine React Native-Anwendung, die einen spezialisierten Kotlin-Vordergrunddienst (Foreground Service) ausführt. Das Android-Gerät hat Zugriff auf Mobilfunkdaten (LTE/5G) und Bluetooth und dient als Brücke.
3. Die Cloud (OpenAI GPT-4o): Das Ziel-LLM-Backend, das über HTTPS erreicht wird.

Warum RFCOMM?

Bei der Übertragung von rohen JSON-Nutzlasten für Prompt-Abfragen und -Antworten benötigten wir ein stromorientiertes, zuverlässiges Transportprotokoll. Während Bluetooth Low Energy (BLE) mit GATT-Attributen hervorragend für Telemetriedaten mit geringem Durchsatz geeignet ist, eignet es sich aufgrund seiner strengen MTU-Beschränkungen (Maximum Transmission Unit) und des Paket-Fragmentierungs-Overheads überhaupt nicht für größere Textblöcke.

Wir haben uns für RFCOMM (Radio Frequency Communication) entschieden, das eine serielle RS-232-Schnittstelle über das L2CAP-Protokoll emuliert. RFCOMM übernimmt die Paketreihenfolge, Flusssteuerung und Wiederholung nativ. Es bietet einen zuverlässigen, stromorientierten Socket (ähnlich einer java.net.Socket-Schnittstelle), der in der Lage ist, das für LLM-Prompts und -Antworten erforderliche Streaming mit hohem Durchsatz aufrechtzuerhalten.

2. Implementierung des Android-RFCOMM-Servers in Kotlin

Um sicherzustellen, dass die Android-Anwendung eingehende Bluetooth-Verbindungen zuverlässig verarbeiten kann, haben wir auf Standard-Wrapper-Bibliotheken von React Native verzichtet - da diese häufig unter Speicherlecks leiden und keine Persistenz im Hintergrund unterstützen - und den Bluetooth-Stack direkt in Kotlin implementiert.

Der Bluetooth-Server-Thread

Der Bluetooth-Server läuft in einem dedizierten Thread und lauscht auf eine bestimmte UUID (Universally Unique Identifier):

1package com.sevenlabs.airelay
2
3import android.bluetooth.BluetoothAdapter
4import android.bluetooth.BluetoothServerSocket
5import android.bluetooth.BluetoothSocket
6import android.util.Log
7import java.io.IOException
8import java.util.UUID
9
10class BluetoothServerThread(
11    private val adapter: BluetoothAdapter,
12    private val onConnectionEstablished: (BluetoothSocket) -> Unit
13) : Thread() {
14
15    private val serverSocket: BluetoothServerSocket? by lazy(LazyThreadSafetyMode.SYNCHRONIZED) {
16        adapter.listenUsingRfcommWithServiceRecord(
17            "SevenLabsAIRelay",
18            UUID.fromString("4a8b8c2d-9e0f-11ed-a8fc-0242ac120002")
19        )
20    } vintage
21
22    private var shouldKeepListening = true
23
24    override fun run() {
25        name = "SevenLabs-RFCOMM-Listener"
26        Log.i("AIRelay", "RFCOMM Server Socket listening...")
27
28        while (shouldKeepListening) {
29            val socket: BluetoothSocket = try {
30                serverSocket?.accept()
31            } catch (e: IOException) {
32                Log.e("AIRelay", "Server Socket accept failed", e)
33                break
34            }
35
36            socket?.let {
37                Log.i("AIRelay", "Incoming RFCOMM client connection accepted")
38                onConnectionEstablished(it)
39            }
40        }
41    }
42
43    fun cancel() {
44        try {
45            shouldKeepListening = false
46            serverSocket?.close()
47        } catch (e: IOException) {
48            Log.e("AIRelay", "Could not close server socket", e)
49        }
50    }
51}

3. Dauerhafter Betrieb: Kotlin Foreground Services & Wake-Lock-Management

Eine der größten Hürden auf modernen Android-Versionen (ab Android 12) sind die Akkuoptimierungen. Wenn sich der Bildschirm des Mobilgeräts ausschaltet oder die App minimiert wird, versetzt das Android-Betriebssystem die CPU in einen Tiefschlaf (Doze Mode) und beendet Hintergrund-Sockets.

Um einen unterbrechungsfreien Betrieb zu gewährleisten, hat Seven Labs zwei entscheidende Mechanismen implementiert:

1. Kotlin Foreground Service: Platzierung des RFCOMM-Servers und des API-Clients in einem Android Foreground Service. Dadurch wird die App als systemweit anerkannter, dauerhafter Prozess registriert, der eine permanente Statusbenachrichtigung anzeigt.
2. Wake-Locks und Wi-Fi-Locks: Explizite Anweisung an den Kernel-Scheduler, die CPU während einer aktiven Sitzung wach zu halten und die Mobilfunkschnittstellen aktiv zu lassen.

Die Implementierung des Foreground Services

Nachfolgend ist der Kern des Vordergrunddienstes dargestellt, der den Lebenszyklus des Threads und die Benachrichtigungen verwaltet:

1package com.sevenlabs.airelay
2
3import android.app.Notification
4import android.app.NotificationChannel
5import android.app.NotificationManager
6import android.app.PendingIntent
7import android.app.Service
8import android.content.Context
9import android.content.Intent
10import android.os.Build
11import android.os.IBinder
12import android.os.PowerManager
13import androidx.core.app.NotificationCompat
14
15class AIRelayService : Service() {
16
17    private var wakeLock: PowerManager.WakeLock? = null
18    private var serverThread: BluetoothServerThread? = null
19
20    override fun onCreate() {
21        super.onCreate()
22        acquireWakeLock()
23        startForegroundService()
24    }
25
26    private fun acquireWakeLock() {
27        val powerManager = getSystemService(Context.POWER_SERVICE) as PowerManager
28        wakeLock = powerManager.newWakeLock(
29            PowerManager.PARTIAL_WAKE_LOCK,
30            "SevenLabs::AIRelayWakeLock"
31        ).apply {
32            acquire(30 * 60 * 1000L) // 30 Minuten Sicherheitslimit
33        }
34    }
35
36    private fun startForegroundService() {
37        val channelId = "seven_labs_ai_relay"
38        val channelName = "AI Relay Foreground Service"
39
40        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
41            val channel = NotificationChannel(channelId, channelName, NotificationManager.IMPORTANCE_LOW)
42            val manager = getSystemService(Context.NOTIFICATION_SERVICE) as NotificationManager
43            manager.createNotificationChannel(channel)
44        }
45
46        val notificationIntent = Intent(this, MainActivity::class.java)
47        val pendingIntent = PendingIntent.getActivity(
48            this, 0, notificationIntent,
49            PendingIntent.FLAG_IMMUTABLE or PendingIntent.FLAG_UPDATE_CURRENT
50        )
51
52        val notification: Notification = NotificationCompat.Builder(this, channelId)
53            .setContentTitle("Seven Labs AI Relay Aktiv")
54            .setContentText("Leite Bluetooth RFCOMM-Daten an GPT-4o weiter...")
55            .setSmallIcon(R.drawable.ic_notification)
56            .setContentIntent(pendingIntent)
57            .build()
58
59        startForeground(1, notification)
60    }
61
62    override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
63        // Bluetooth-Listening starten
64        val adapter = BluetoothAdapter.getDefaultAdapter()
65        serverThread = BluetoothServerThread(adapter) { socket ->
66            // Stream-Daten weiterleiten
67            ConnectionHandler(socket).start()
68        }
69        serverThread?.start()
70        return START_STICKY
71    }
72
73    override fun onDestroy() {
74        serverThread?.cancel()
75        wakeLock?.let {
76            if (it.isHeld) it.release()
77        }
78        super.onDestroy()
79    }
80
81    override fun onBind(intent: Intent?): IBinder? = null
82}

4. Strukturierung der Nutzdaten und des Protokolls

Da RFCOMM als reiner Byte-Stream arbeitet, mussten wir ein Framing-Protokoll auf Anwendungsebene definieren, um die einzelnen Anfrage- und Antwortpakete zu segmentieren.

Wir haben ein leichtgewichtiges Format für Nachrichten-Frames entworfen:

• Magic Bytes (4 Bytes): SLAR (Seven Labs AI Relay) zur Validierung der Paketquelle.
• Nutzlastlänge (4 Bytes): Big-Endian-Integer zur Angabe der genauen Größe der Nutzdaten.
• Nutzlasttyp (1 Byte): Gibt an, ob das Paket roher Text, ein SSE-Chunk (Server-Sent Events), Metadaten oder ein Fehlercode ist.
• Verschlüsselte Nutzdaten (variabel): Mit AES-GCM verschlüsselte JSON-Daten.

Wenn der Client auf dem Offline-PC einen Prompt sendet, verpackt der lokale Daemon diesen in einen solchen Frame, überträgt ihn über den RFCOMM-Socket und wartet blockiert auf Antwort-Frames.

Auf der Seite des Android-Relays liest der Kotlin-Socket-Reader das Längenpräfix, liest die angegebene Anzahl an Bytes, entschlüsselt die Nutzdaten und leitet die HTTP-Anfrage an den OpenAI-Endpunkt weiter. Um das Token-Streaming zu unterstützen, parsen wir die von OpenAI zurückgegebenen SSE-Daten-Chunks (Server-Sent Events), verpacken sie als Typ SSE Chunk und schreiben sie sequenziell zurück in den Bluetooth-Socket-Stream.

5. Sicherheitsarchitektur: Zero-Trust über Bluetooth

Die Übertragung von Unternehmensdaten über Bluetooth wirft erhebliche Sicherheitsbedenken auf. Bluetooth-Verbindungen sind anfällig für Abhören und Man-in-the-Middle-Angriffe (MitM). Um dieses Relay für den Unternehmenseinsatz tauglich zu machen, hat Seven Labs eine zusätzliche Verschlüsselungsschicht auf Anwendungsebene implementiert.

Ende-zu-Ende-Verschlüsselung (E2EE)

Selbst wenn die Bluetooth-Kopplungsschicht kompromittiert wird, bleiben die Nutzdaten geschützt.

1. Schlüsselaustausch: Wenn der Offline-PC eine Verbindung initiiert, führt er einen Elliptic-Curve Diffie-Hellman-Schlüsselaustausch (ECDH) über den rohen Bluetooth-Socket mit dem Android-Gerät durch.
2. Temporärer Sitzungsschlüssel: Beide Endpunkte leiten einen gemeinsamen symmetrischen Schlüssel (AES-256-GCM) ab, der für diese spezifische Sitzung gilt.
3. Nutzdatenverschlüsselung: Jedes Datenframe-Paket wird mit dem Sitzungsschlüssel verschlüsselt, wobei für jeden Frame ein eigener Initialisierungsvektor (IV) erzeugt wird. Dies verhindert Replay-Angriffe und Schnüffeln.

6. Performance- und Latenz-Optimierung

Unsere Benchmarks in der Produktion zeigten die folgenden Performance-Metriken:

Optimierung des Durchsatzes

Da die Bandbreite von Bluetooth im Vergleich zu Wi-Fi begrenzt ist, ist das Streamen der Antworten Token für Token von entscheidender Bedeutung. Indem wir die SSE-Chunks direkt an den Client zurückgeben, sobald sie an der Edge von OpenAI eintreffen, konnten wir die gefühlte Latenz (TTFT) um über 50 % senken.

Darüber hinaus haben wir eine Gzip-Komprimierung für Prompts eingeführt, die größer als 20 KB sind. Dies verkürzt die Bluetooth-Übertragungszeit und umgeht Engpässe im RFCOMM-Puffer.

7. Enterprise Frequently Asked Questions

Verletzt dieses System das Air-Gap-Prinzip?

Das System fungiert als strikter Protokoll-Proxy. Die offline Workstation hat keine IP-Verbindung zum Mobilfunknetz. Dies verhindert allgemeinen Internetzugang, Port-Scans oder Schwachstellen durch Reverse-Tunnel-Shells. Es sind ausschließlich wohlgeformte SLAR-Frames auf Anwendungsebene über die Schnittstelle zulässig.

Wie verhält sich der Akkuverbrauch des Relay-Geräts?

Der gleichzeitige Betrieb von Bluetooth und LTE verbraucht etwa 8 % Akku pro Stunde bei kontinuierlicher Verarbeitung. Durch den gezielten Einsatz von Android-PowerManager Wake-Locks - die wir nur bei aktiven Socket-Sitzungen halten - konnten wir den Akkuverbrauch minimieren.

Wie wird das Token-Accounting verwaltet?

Alle Nutzungsdaten und Autorisierungsschlüssel sind in der Android-Relay-App gespeichert oder werden von einem Enterprise-Key-Server abgerufen. Einzelne Benutzeranmeldungen können lokal auf dem Gerät authentifiziert werden, bevor die Diffie-Hellman-Aushandlung stattfindet.

Technische SEO-Schemata & interne Links

• Keywords: AI Relay, Offline Bluetooth AI, React Native Android, Kotlin foreground service, GPT-4o RFCOMM, secure AI systems.
• Interne Links:
  • Erfahren Sie mehr über unsere Dienstleistungen im Bereich maßgeschneiderter KI-Entwicklung und wie wir maßgeschneiderte Systeme entwerfen.
  • Lesen Sie mehr über unsere Kompetenzen bei der Netzwerkhärtung durch VAPT-Audits und Penetrationstests.
  • Sehen Sie sich unser umfassendes Portfolio an Fallstudien zur Unternehmenssoftware-Entwicklung an.

Entwickeln Sie sichere Edge-zu-Cloud-Systeme mit Seven Labs

Die Verknüpfung von moderner KI mit strengen Sicherheitskontrollen in Unternehmen erfordert erfahrene Systemarchitekten. Ob air-gapped LLM-Deployments, hochperformantes Edge Computing oder sichere IoT-Relays - Seven Labs verfügt über die Engineering-Expertise, um konforme Lösungen zu entwerfen und zu implementieren.

Kontaktieren Sie das Engineering-Team von Seven Labs, um die maßgeschneiderten KI- und Infrastrukturanforderungen Ihres Unternehmens zu besprechen.