Security

Every link between your device and your Mac is encrypted. Not only the audio — everything that crosses it, including control messages and firmware updates.

The link travels two ways, over Bluetooth or over USB, and both are protected the same way, by the same code. A link that cannot be secured is refused, never quietly weakened.

One link, two transports

Your device

Device key

Encrypted link

• Bluetoothwireless
• USBplugged in

Encrypted and checked for tampering, frame by frame. Audio, control and firmware updates all travel inside it.

The companion

Device key

Your Mac writes the device's key down the first time you connect, so a reconnect that presents a different key is refused.

No secure channel, no linkBefore the channel is up the device sends nothing and accepts nothing. There is no plaintext data path to fall back to.

What protects the link

Encryption is only half of it. Every frame is also checked for tampering: change one byte in flight and the device throws the whole frame away, rather than act on data it cannot trust.

The link is fail-closed — until the secure channel is up, the device sends nothing and accepts nothing, with no plaintext path to fall back to. The companion holds the same line: it wraps every connection, over Bluetooth or USB, in the secure channel before any of your data reaches it.

The protocol, for the curious

The channel is Noise_XX_25519_ChaChaPoly_SHA256: the companion opens the handshake, the device answers, and three messages establish the encrypted channel. From then on every frame carries a 16-byte authentication tag — the check that catches a flipped byte and drops the frame.

The device runs the crypto on the same core that runs the link, so the core that handles audio never holds a key. Fail-closed is enforced on the device in both directions: before the channel is up it drops any frame that is not part of the handshake, and the send path returns an error rather than fall back to plaintext.

Trust on first use

Each device makes its own key the first time it powers on, and keeps it. That key is the device's identity — the same one over Bluetooth and over USB.

The first time you connect, the key is written down. Every connection after that must present the same one.

The key check, on every connection

Device connects

1. 1Key seen before?

   • NoWrite it downConnected
   • Yes2Same key?

2. 2Same key?

   • YesConnected
   • NoRefused

• ConnectedYour Mac recognizes the key it pinned.2 answers land here
• RefusedA key that changed is a device that changed. Zeph says so, rather than trusting it quietly.
  1. Forget the old key to re-pin
  2. Back to the startDevice connects

A key that changed is a device that changed. Zeph refuses the connection and says so, instead of trusting it quietly. That is the right answer when hardware is swapped under you — and it is also what happens for an innocent reason, when you replace or re-flash a device of your own.

Either way, you decide. Forget the device — in the app, or from the command line — and Zeph drops the trusted key completely, so the next connection starts the check over and writes down the new one. Forgetting in the app and forgetting on the command line are the same act: trust one place, and it is trusted in both.

The app you install

The Zeph app you download is signed with an Apple Developer ID and notarized by Apple. macOS checks that signature before it will open the app, so you know it came from us and has not been tampered with since it was built.

Why not Bluetooth pairing

Zeph does not use Bluetooth pairing. On a Mac you could never truly un-pair a device once it was paired — there was no supported way to fully undo it. So "forget this one and start over," the move you actually need, was off the table.

Pinning lives in Zeph instead. One key, both transports, and a forget that runs.

Why pairing was the dead end

Bluetooth bonding lives in the operating system, not in the app. On the device and on macOS both, bonding was a proven dead end: macOS never exposed a way to un-bond a device, so a clean "forget and re-pin" could not be built on top of it. Pinning in Zeph keeps the key and the forget where Zeph can control both — which is why it can actually run.