Bluetooth MultiPeer Protocol

①

BLE Discovery & Advertisement

Device A (initiator) advertises its availability and Device B discovers it via BLE scanning.

Device A

Initiator

🔊 Broadcasting advertisement
Waiting for joiner

→ 📡

Device B

Joiner

🔍 Scanning nearby devices
Sees Device A

BLE Advertisement Packet

UUID: 550e8400-e29b-41d4-a716-446655440000
Name: "CB-MPC-[Device-A-UUID]"
Flags: Connectable, LE General Discoverable
TX Power: -6 dBm (range ~20-30m)

BLE advertisement transmits every 20-100ms. Device B sees Device A within 1-2 seconds of scanning. No connection established yet—just discovery.

②

Pairing Handshake & Session ID Exchange

Device B initiates connection and both devices validate identity using a passphrase-protected QR code.

Device A

Generates session ID
Encodes as QR code
Shows on screen

↔ BLE GATT

Device B

Initiates connection
Requests session ID
Scans QR from A

T=0.5s

BLE GATT CONNECT Device B → Device A

T=0.8s

SESSION_ID_RESPONSE Device A → Device B
Session ID: 550e8400-e29b-41d4-a716-446655440000

🔐

QR Code Content: Session ID + Timestamp + Device A's BLE address
Protection: Optional passphrase (user enters on Device B to confirm)
Timeout: Session ID valid for 5 minutes

The QR code serves as a second verification channel. Even if BLE is compromised, the visual confirmation prevents man-in-the-middle attacks. Passphrase adds extra security layer.

③

TLS Certificate Exchange via QR Codes

Both devices generate ephemeral X.509 certificates and exchange them via short QR codes to establish mTLS tunnel.

T=1.2s

CERT_REQUEST_A Device A requests B's certificate

T=1.5s

CERT_RESPONSE_B Device B sends cert via 2 QR codes
QR 1/2: -----BEGIN CERTIFICATE-----
QR 2/2: ...MIIC...

T=2.1s

CERT_ACK_A Device A confirms receipt & sends its 2 QR codes

T=2.8s

CERT_ACK_B Device B confirms receipt

Certificate Details

Type: Ephemeral EC P-256 certificate
Valid for: Duration of key operation only (5 minutes)
Subject CN: Device UUID (e.g., "iPhone-550e8400")
Self-signed: Yes (trust established via QR verification)
Key Usage: TLS Server + TLS Client authentication

QR codes allow out-of-band certificate verification. Certificates are ephemeral (short-lived) and regenerated for each session. Combined with session ID validation, this prevents certificate pinning attacks.

④

mTLS Tunnel Setup

With exchanged certificates, both devices establish a mutually-authenticated TLS tunnel over BLE GATT.

Device A

Initiates TLS handshake
Verifies B's certificate
Tunnel ready

↔ TLS 1.3

Device B

Responds to handshake
Verifies A's certificate
Tunnel ready

T=3.0s

CLIENT_HELLO Device A → Device B (with A's cert)

T=3.3s

SERVER_HELLO Device B → Device A (with B's cert)

T=3.6s

FINISHED TLS handshake complete

T=3.8s

✓ TUNNEL ESTABLISHED Ready for DKG

Tunnel Properties

Protocol: TLS 1.3 over BLE GATT
Cipher Suite: TLS_AES_256_GCM_SHA384
Handshake Duration: ~800ms
Throughput: ~110 KB/s (BLE 5 with 2M PHY)
Latency: ~20-50ms per round-trip

mTLS (mutual TLS) ensures both devices authenticate each other before exchanging cryptographic material. The tunnel is now ready for sensitive protocol execution.

⑤

DKG Round 1: Commitment Generation

Both devices generate secret polynomials and commit to them without revealing the secrets.

Round 1: Generate Commitments

Each party generates a random polynomial of degree 1 (for 2-of-2 threshold). Share commitments (not the secrets) with the other party.

T=4.0s

ROUND1_COMMITMENT_A Device A → Device B
C_A[0] = Hash(P_A[0]) (commitment to secret)
C_A[1] = Hash(P_A[1]) (commitment to slope)

T=4.3s

ROUND1_COMMITMENT_B Device B → Device A
C_B[0] = Hash(P_B[0])
C_B[1] = Hash(P_B[1])

Device A's Polynomial:
P_A(x) = a₀ + a₁·x (mod p)
a₀ = [secret] (Share 0)
a₁ = [random slope]

Device B's Polynomial:
P_B(x) = b₀ + b₁·x (mod p)
b₀ = [secret] (Share 1)
b₁ = [random slope]

Commitments are binding: they prove knowledge of the polynomial without revealing coefficients. Devices exchange commitments first to enable verification in subsequent rounds.

⑥

DKG Round 2: Share Distribution

Each device evaluates its polynomial at the other device's index and sends the share over the encrypted tunnel.

Round 2: Evaluate and Share

Device A evaluates P_A at index 1 and sends share to Device B. Device B evaluates P_B at index 0 and sends share to Device A.

T=4.8s

ROUND2_SHARE_A Device A → Device B (encrypted)
s_{A→B} = P_A(1) = a₀ + a₁·1 (mod p)
Encrypted: AES-256-GCM(s_{A→B}, session_key)

T=5.1s

ROUND2_SHARE_B Device B → Device A (encrypted)
s_{B→A} = P_B(0) = b₀ + b₁·0 (mod p)
Encrypted: AES-256-GCM(s_{B→A}, session_key)

Share Security

Encryption: AES-256-GCM over TLS tunnel (double encryption)
Authentication: HMAC included in GCM tag
Size: 32 bytes (256-bit share) + 16-byte tag + 12-byte nonce = 60 bytes encrypted

Shares are sent encrypted over the already-secure TLS tunnel. Double encryption ensures that even if TLS is compromised, shares remain protected.

⑦

DKG Round 3: Verification & Completion

Both devices verify received shares against the commitments and finalize the shared public key.

Round 3: Verify Shares

Device A verifies that the share from B matches B's commitments. Device B does the same with A's share. Both compute the shared public key.

T=5.6s

ROUND3_ACK_A Device A → Device B
Verify: C_B[0] + C_B[1]·1 = commit_to(s_{B→A}) ✓
Status: Verification passed

T=5.9s

ROUND3_ACK_B Device B → Device A
Verify: C_A[0] + C_A[1]·0 = commit_to(s_{A→B}) ✓
Status: Verification passed

T=6.1s

✓ DKG COMPLETE Shared public key generated
PK = P_A(x) + P_B(x) = (a₀+b₀) + (a₁+b₁)·x

Device A Now Holds:
share_A = b₀ + b₁·0
share_A += a₀ (local)
pk = EC_Multiply(share_A, G)

Device B Now Holds:
share_B = a₀ + a₁·1
share_B += b₀ (local)
pk = EC_Multiply(share_B, G)

Both devices now hold different shares (one from each device's polynomial evaluation), and both can independently verify that they hold correct shares. The combined shares form a valid 2-of-2 threshold key. Neither device holds the full key.

⑧

Signing: Pre-Signing Commitment

To sign a message, Device A initiates signing by sending a commitment to a random nonce.

Signing Round 1: Commitment

Device A generates ephemeral keypair and commits to the nonce. Device B responds with its nonce commitment.

T+0.0s

SIGN_COMMIT_A Device A initiates signing
message = "Transfer 10 BTC to 0x..."
R_A_commitment = Hash(k_A · G) (ephemeral pubkey)

T+0.3s

SIGN_COMMIT_B Device B responds
R_B_commitment = Hash(k_B · G)

Both devices commit to random nonces before seeing the message hash. This prevents certain attacks where a compromised device could force a predetermined signing result.

⑨

Signing: Partial Signature Exchange

Both devices compute partial signatures using their shares and exchange them.

T+0.6s

SIGN_RESPONSE_A Device A sends its ephemeral pubkey
R_A = k_A · G
sig_A = k_A + H(msg) · share_A (mod n)

T+0.9s

SIGN_RESPONSE_B Device B sends its ephemeral pubkey
R_B = k_B · G
sig_B = k_B + H(msg) · share_B (mod n)

Partial Signature Security

Neither partial signature is valid alone. Each device only computes a partial using its own share. The combined signature requires both shares and both ephemeral nonces (R_A and R_B).

Partial signatures are computed in parallel. Both devices exchange their contributions and then combine them locally to produce the final signature.

⑩

Signing: Finalization

Both devices combine the partial signatures into a final signature ready for broadcast.

T+1.2s

SIGN_FINAL_A Device A combines and verifies
R = R_A + R_B
sig = (sig_A + sig_B) mod n
Verify: sig · G = R + H(msg) · PK ✓

T+1.5s

✓ SIGNATURE READY
(R, sig) now valid for broadcast

Final Signature Validation

sig · G = R + H(msg) · PK
This ECDSA equation holds only if both shares (share_A and share_B) contributed correctly to the signature. A faulty device would produce an invalid signature.

Signature finalization is local (Device B can also do it independently). Both devices verify the signature is valid before broadcasting it to the blockchain or network.

⑪

Disconnection & Retry Logic

If BLE connection drops during protocol execution, both devices handle recovery gracefully.

Scenario	Recovery Action	Time to Recover
Discovery phase disconnect	Device B rescans from scratch	1-2 seconds
Pairing QR pending	Devices retain session ID, B rescans QR or manually re-enter passphrase	3-5 seconds
During TLS handshake	Restart handshake, regenerate ephemeral certificates	~1 second
During DKG Round 1	Restart from Round 1 (commitments unchanged)	~2 seconds
During DKG Round 2 (share exchange)	Resend shares (encrypted again with new session key)	~1 second
During signing	Restart signing from commitment phase	~1.5 seconds
Session timeout (5+ minutes idle)	Restart entire protocol from discovery	Full protocol (6-8s)

Why Restart is Safe

Restarting at any phase is cryptographically safe because:

New random values (nonces, ephemeral keys) are generated each attempt
Commitments are already sent—restarting reveals nothing new
Final signatures require both devices' latest shares, preventing replay attacks

BLE is inherently unreliable (best-effort, no guaranteed delivery). Both devices implement timeouts and exponential backoff for retries. After 3 failed attempts, they reset to discovery phase.

⑫

Performance Characteristics

Real-world measurements for Bluetooth MultiPeer protocol execution on iOS devices.

Phase	Duration	Latency Breakdown	Bytes Transferred
Discovery & Advertisement	1-2s	BLE scan interval (1s) + first packet	~100 bytes
Pairing handshake (with QR verification)	3-5s	Session ID exchange (300ms) + user QR scan (2-4s)	~200 bytes
TLS certificate exchange	1-1.5s	QR 1 (500ms) + QR 2 (500ms) + TLS exchange (500ms)	~2KB
mTLS tunnel setup	~1s	TLS handshake with RTT latency	~500 bytes
DKG Round 1 (commitments)	~300ms	2 RTTs (~150ms each)	~256 bytes
DKG Round 2 (shares)	~400ms	Share transmission + crypto	~128 bytes
DKG Round 3 (verification)	~300ms	Commitment verification + crypto	~128 bytes
Total DKG	~6-8 seconds	Discovery + pairing + TLS + DKG	~4KB
Signing (single transaction)	~1.5s	3 RTTs (commitment, response, final)	~512 bytes
Signing (bulk, 10 txs)	~12s	Setup (6s) + 10 × signing (600ms)	~7KB

BLE Range & Performance
Range: 10-30m (clear line-of-sight)
Latency: 20-100ms per round-trip
Throughput: 110 KB/s (BLE 5)
Reliability: ~99% (with retry)

Comparison vs. QR Transfer
QR: 1-2 minutes (user scans)
BLE: 6-8 seconds (fully automatic)
QR: 100% air-gap safe
BLE: Requires devices in range

BLE multidevice operations are fast and reliable. The main overhead is initial discovery and TLS handshake. Once connected, subsequent signings reuse the tunnel for near-instant (1.5s) operations. QR transfer is slower but safer for offline/air-gapped scenarios.

⑬

Use Cases: BLE vs. QR Transfer

Use Case	BLE MultiPeer	QR Transfer	Recommendation
Initial key generation (2-of-2)	✓ Real-time, 6-8s	✓ Offline, 1-2 min	BLE (faster, live confirmation)
Key backup to second device	✓ Periodic syncing	✓ Air-gap capable	QR (one-time, secure)
Signing without internet	✓ Devices in range	✗ Not supported	BLE (only option)
Signing with confirmation from spouse	✓ Instant feedback	✗ Requires device in hand	BLE (better UX)
Emergency key recovery (offline, no devices)	✗ Requires devices	✓ From printed QR codes	QR (resilience)
Key share transfer to family member	✓ Requires physical presence	✓ Can be done remotely	QR (flexibility)
High-frequency signing (100+/day)	✓ 1.5s per signature	✗ 1-2 min per signature	BLE (practical)

Use BLE when: Both devices are present, speed matters, and you need real-time confirmation. Best for active signing workflows.

Use QR when: Air-gap security matters, devices are not both present, or you're doing one-time key backup. Best for recovery and long-term security.