Die meisten BLE-Tag Produkte werden als reine Advertising-Beacons ausgeliefert: das Telefon scannt sie, liest die Nutzlast und entfernt sich. Dieses Modell bricht sofort, sobald du das Tag konfigurieren, klingeln lassen, Firmware übertragen oder gepufferte Sensordaten lesen willst. Dann brauchst du eine echte GATT-Verbindung, und das Verbindungsmanagement wird zum Kernproblem. Dieser Artikel geht am Marketing vorbei: Pairing, Bonding, LE Secure Connections, GATT-Layout, Verbindungsparameter und die iOS/Android-Eigenheiten, die echte Auslieferungen scheitern lassen.

Pairing vs Bonding

Pairing ist der live Schlüsselaustausch, der den LTK erzeugt. Bonding ist Pairing plus das Persistieren dieses LTK (samt IRK/CSRK) im Flash, sodass die nächste Sitzung verschlüsselt ohne erneutes Pairing fortsetzt. Ein Tag, das nur pairt, aber nicht bonded, zwingt bei jedem App-Neustart zum erneuten Pairing, was für einen Consumer-Finder inakzeptabel ist.

Legacy Pairing vs LE Secure Connections

Legacy Pairing (4.0 bis 4.1) leitet den LTK aus einem Temporary Key ab und ist anfällig für passives Abhören: einmal die Übertragung mitschneiden, und du gewinnst den LTK. LE Secure Connections (4.2+) führt erst einen ECDH P-256-Handshake durch, sodass der LTK nie über die Luft geht. Für jedes Tag, das Position oder Identität trägt, ist Secure Connections die einzig akzeptable Basis.

Merkmal Legacy Pairing LE Secure Connections
Schlüsselvereinbarung Temporary Key ECDH P-256
Passives Abhören LTK rekonstruierbar Sicher
MITM (Numeric Comparison) Nein Ja
Mindestversion 4.0 4.2

Assoziationsmodelle

Das Assoziationsmodell entscheidet, wie der Nutzer den Link bestätigt. Just Works ist lautlos, bietet aber keinen MITM-Schutz, okay für Finder, riskant für Schlösser. Numeric Comparison (nur Secure Connections) zeigt einen 6-stelligen Code auf beiden Seiten.

Modell Nutzeraktion MITM Typischer Einsatz
Just Works Keine Nein Finder, geringer Wert
Passkey Entry 6 Ziffern Ja Industriekonfig
Numeric Comparison Code bestätigen Ja Sichere Tags
OOB Tap/NFC Ja Provisionierung

Schlüsselhierarchie

Nach dem Pairing speichert der Stack: LTK (128-Bit Link-Verschlüsselung), IRK (auflösbare Private Adresse), CSRK (signierte Schreibvorgänge) sowie ER/DHK-Wurzeln. Die IRK ist es, die einem gebundenen Telefon erlaubt, das Tag nach Adressrotation wiederzuerkennen.

GATT-Service-Layout

Ein pragmatisches GATT für Finder/Tracker:

UUID Service / Char Eigenschaft
0x180F Battery Service Read
0x180A Device Information Read
0x2A06 Alert Level (Find Me) Write
Fxxx Config (Intervall, TX-Power) Read/Write
Fxxx Button / letzter Druck Notify
Fxxx Firmware-Revision Read

Halte die Config-Characteristic hinter Bonding schreibgeschützt; sonst schreibt jeder in Reichweite den TX-Power um und macht die Reichweitenbegrenzung zunichte.

Verbindungsparameter

Drei Werte beherrschen jede Verbindung:

  • Connection Interval: 7.5 ms bis 4000 ms. iOS begrenzt das ausgehandelte Minimum praktisch auf ~20 ms.
  • Slave Latency: 0 bis 499 Events, die das Tag überspringen darf.
  • Supervision Timeout: 100 ms bis 32000 ms; muss (1 + latency) x interval x 2 übertreffen.

Niedrigleistungsprofil: interval 1000 ms, latency 9, timeout 11 s bedeutet, dass das Tag 9 von 10 Events überspringt und etwa einmal pro Sekunde aufwacht. Der mittlere Strom sinkt vom mA-Bereich (verbunden, 30 ms) auf Zehner uA.

Reconnect ohne Akku zu leeren

Reine Advertising-Tags senden eine statische oder zufällige Adresse; ein gebundenes Telefon findet sie nach Adressrotation nicht zuverlässig. Nutze eine Resolvable Private Address aus der IRK, bewirb dich mit aktivierter White List, und lass das gebundene Telefon die RPA auflösen. Die White-List-Größe auf gängigen SoCs liegt bei 8 bis 32 Einträgen, genug für ein Telefon und ein paar Gateways.

iOS / Android-Eigenheiten, die Auslieferungen scheitern lassen

  • iOS: CoreBluetooth-Hintergrundscan matcht nur Services, deren UUID im Advertisement steht. Versteckt das Tag die Service-UUID, wacht die App im Hintergrund nicht auf. Intervalle < ~20 ms werden abgelehnt. ANCS braucht eine gebundene Verbindung für Alerts.
  • Android 12+: BLUETOOTH_CONNECT und BLUETOOTH_SCAN sind Laufzeitberechtigungen; ohne sie liefert der Scan nichts. Der Systemhinweis «Nahe Geräte finden» muss behandelt werden, und der Hintergrundscan ist auf ~1/Stunde für Cache-Apps gedrosselt.
  • Beide: eine dauerhaft gehaltene Verbindung verbrennt den CR2032 in Tagen. Verbinde on-demand und trenne danach.

Leistungskompromiss

Modus Typischer Strom CR2032-Leben
Nur Advertising (200 ms) ~5 bis 15 uA 1 bis 3 Jahre
Verbunden, 30 ms 1 bis 3 mA Bursts Tage bis Wochen
On-demand verbunden Zehner uA 1 bis 2 Jahre

Regel: standardmäßig nur Advertising. Öffne eine Verbindung nur für Config, Alert oder OTA, dann schließe sie.

Fallstricke

  • Nur Pairing ohne Bonding führt zur Re-Pairing-Schleife bei jedem Start.
  • Legacy Pairing auf Positionstag lässt eine rekonstruierbare LTK zu.
  • Statische Zufallsadresse ohne IRK bedeutet, dass das gebundene Telefon das Tag nicht findet.
  • Verbindung «für alle Fälle» halten endet im Akkutod.
  • Service-UUID unter iOS verstecken blockiert den Hintergrund-Wake.

Verbindungsmanagement richtig zu machen ist der Unterschied zwischen einem Demo-Tag und einem Produkt, das du wirklich ausliefern kannst. Für Referenzdesigns, die bereits Secure Connections und ein sinnvolles GATT implementieren, siehe unsere Bluetooth-Modul-Linie und die breitere Familie BLE-Tag.