Explainer · Security
What the receiver password actually protects.
Airlive can require a password before a camera will stream to a receiver, and the way it does that is better than most. It is still worth being precise about what it defends against — because the honest answer changes how you set up the network around it.
How the check works
Authentication is optional and off by default. When it is on, the receiver challenges the camera before any video flows. The exchange is a standard HMAC challenge-response:
- The receiver sends a nonce — 32 random bytes, used once and never again.
- The camera computes HMAC-SHA256 over that nonce, keyed with the password, and returns the result.
- The receiver computes the same thing and compares. Match, and the stream starts.
Two properties are worth naming. The password itself never crosses the network — only a value derived from it and from a number that will never be reused. And because the nonce is single-use, capturing a valid response tells an attacker nothing they can replay later.
That is a considered design. Plenty of local-network gear still sends a shared secret in the clear.
What it therefore does defend
In practical terms: on a shared network — a venue, a campus, a conference floor — it stops a camera from connecting to a receiver that isn't yours, whether by accident or on purpose. In a building where several teams run Bonjour-discoverable software, "by accident" is the common case, and it is worth preventing on its own.
What it does not do
It is access control, not confidentiality. Once a connection is authorised, the video on the wire is not encrypted. Anyone positioned to capture traffic on that network can reconstruct the picture. The password decides who may connect; it does not hide what is sent.
This is stated plainly in the specification, and it is the right trade for the job: video encryption on a LAN costs latency and CPU on a device you are also asking to stay cool for hours, to protect a feed that in most productions is about to be broadcast to the public anyway.
But "in most productions" is not "in yours." If what the camera sees is sensitive before it is public — a closed board meeting, a medical or legal setting, anything under an NDA — the protocol is not what should be protecting it.
What to actually do
- Turn the password on for anything shared. It costs nothing and removes the whole class of accidental cross-connections.
- Give the production its own network or SSID. This is the real security control, and it is also the right answer for reliability. Guest Wi-Fi is neither private nor stable.
- Treat the production network as production infrastructure. Not the venue's open network, and not something a stranger can join by asking at reception.
- For genuinely sensitive material, encrypt at a layer that does that job — an isolated network, or a VPN if it has to cross anything you don't control.
- Going beyond the building? Republish. The protocol is a local-network design. Crossing the internet means a receiver that re-encodes into a transport built for it, such as SRT out of Bridge.
Why we spell this out
It would be easy to write "secure connection with HMAC authentication" and let people assume the rest. The reason not to is that someone would eventually make a decision — about a room, a client, a recording — on the strength of that assumption. A security property you have overstated is worse than one you never claimed.
So: strong authentication, no encryption, local network by design. Set up accordingly and it is a sound arrangement for live production.