ulweb/Secure MQTT.md

There is **nothing fundamentally wrong** with the approach, provided the device’s **private key never leaves the device**. The main complication is that the phone—not the BLE device—is establishing the MQTT/TLS connection.

## The key distinction

The certificate itself is public. Authentication occurs because the client proves possession of the corresponding **private key** by signing part of the TLS handshake. In TLS 1.3, this happens in the `CertificateVerify` step. ([IETF Datatracker][1])

Therefore, simply reading the certificate over BLE and giving it to the phone is insufficient. You need one of these architectures.

### 1. Device acts as a remote TLS signer

The phone performs the MQTT/TLS connection but delegates private-key operations to the BLE device:

```text
MQTT broker
    ↕ TLS
Phone MQTT/TLS client
    ↕ BLE signing request
Embedded device/private key
```

During the TLS handshake:

1. Phone sends the device certificate.
2. TLS library generates the `CertificateVerify` data.
3. Phone sends the digest/signing request over BLE.
4. Device signs it using its private key.
5. Device returns only the signature.
6. Phone completes mutual TLS.

This is cryptographically valid and is similar to using a secure element, smart card, TPM, or hardware-backed keystore. Hardware-backed key systems are specifically designed so applications can use a key without extracting it. ([Android Open Source Project][2])

The difficulty is implementation: your Android/iOS MQTT and TLS libraries must support an **external or asynchronous private-key signer**. Many high-level MQTT libraries expect a conventional `PrivateKey` object and do not readily support a BLE-backed signing operation.

### 2. Device signs an application-level authentication challenge

This is usually easier and often cleaner:

```text
Phone → server: Request device-authentication challenge
Server → phone: Random nonce
Phone → BLE device: Sign nonce + context
Device → phone: Signature
Phone → server: Certificate + signature
Server → phone: Short-lived MQTT credential
Phone → MQTT broker: Connect using short-lived credential
```

The short-lived MQTT credential could be:

* A JWT or similar access token
* A temporary username/password
* A temporary MQTT client certificate
* A session credential issued by your backend

I would generally favor this architecture. It lets your backend authenticate the device certificate while the phone uses an ordinary MQTT client library.

Include at least this in the signed data:

```text
protocol_version
device_serial_number
server_nonce
intended_server/audience
timestamp or expiration
requested permissions
phone/app session identifier
```

That prevents the signature from being reused for another server, session, or purpose.

## Principal security concerns

### Do not export the private key

Sending both the certificate and private key to the phone eliminates much of the value of provisioning a unique device credential. A compromised or rooted phone could copy the identity permanently.

Only send signatures from the device.

### Secure the BLE connection

BLE should use authenticated LE Secure Connections, preferably Numeric Comparison, Passkey Entry, or an equivalent product-specific enrollment process. “Just Works” pairing encrypts traffic but does not provide meaningful protection against an active man-in-the-middle during pairing. ([Nordic Developer Academy][3])

For stronger protection, add application-layer security and mutual device/app authentication rather than relying solely on BLE pairing.

### Avoid creating an unrestricted signing oracle

Do not expose a generic BLE command such as:

```text
SIGN arbitrary_bytes
```

A malicious phone application could use the device to sign unrelated material.

Instead expose a narrowly scoped operation:

```text
AUTHENTICATE_MQTT(challenge, broker_id, expiration)
```

The firmware should:

* Validate the request format
* Require an approved broker or backend identifier
* Apply a domain-separation prefix such as `MYPRODUCT-MQTT-AUTH-V1`
* Reject stale challenges
* Rate-limit attempts
* Optionally require that the phone was previously provisioned or bonded

### Broker authorization remains necessary

A valid certificate should identify the device, but it should not automatically grant access to every MQTT topic. Use broker ACLs tied to the authenticated device identity, for example:

```text
devices/DEVICE123/telemetry      publish
devices/DEVICE123/commands       subscribe
```

MQTT itself recommends using authentication, authorization, and secure communication mechanisms for sensitive systems. ([OASIS Open][4])

## My recommendation

For a phone acting as a passive BLE-to-cloud data ferry, I would use:

```text
Permanent private key:      embedded device only
Device certificate:         embedded device, readable by phone
Device authentication:      signed server challenge over BLE
Phone MQTT credential:      short-lived token or temporary certificate
MQTT authorization:         device-specific topic ACL
BLE protection:             authenticated pairing plus app-level binding
```

That preserves the device’s permanent identity, works with normal phone MQTT libraries, supports credential expiration and revocation, and prevents the permanent private key from ever reaching the phone.

Direct BLE-backed TLS signing is also sound, but it is substantially harder to integrate and may tie you to a particular TLS/MQTT implementation.

[1]: https://datatracker.ietf.org/doc/html/rfc8446?utm_source=chatgpt.com "The Transport Layer Security (TLS) Protocol Version 1.3"
[2]: https://source.android.com/docs/security/features/keystore?utm_source=chatgpt.com "Hardware-backed Keystore"
[3]: https://academy.nordicsemi.com/courses/bluetooth-low-energy-fundamentals/lessons/lesson-5-bluetooth-le-security-fundamentals/topic/security-modes/?utm_source=chatgpt.com "Security modes - Nordic Developer Academy"
[4]: https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html?utm_source=chatgpt.com "MQTT Version 5.0 | OASIS Standard"