[Cryptography] encrypted *broadcasts* ?

[Jon Callas]

> On Aug 12, 2025, at 08:47, Henry Baker <hbaker1 at pipeline.com> wrote:
> 
> "Auracast" is a new *broadcast* service of Bluetooth LE which allows for low-latency audio to be broadcast to phones/earbuds/speakers/hearing aids in "public" places.
> https://www.bluetooth.com/auracast/

I watched a webinar about it via my audiologist and given the audience it was pitched as a replacement for the "audio loop" that's been around for many decades. I can certainly see that a venue might want to upgrade that tech to something more modern. My present hearing aids are "Auracast-ready," which means that it doesn't exist. My conversations with my audiologist are such that I said from long experience, I suspect it will roll out in the next five to ten years, and they muttered agreement-like sounds.

> Auracast supports encryption via passwords; I don't know anything about the details of how it works, but it doesn't matter, since I'm more interested in the general problem of encrypting broadcasts rather than the specific choices/recommendations of Auracast.

I don't think any of us do. I spent like five minutes researching it and then decided I could wait for real documents to show up.

> 
> A traditional method of controlling access has been the *physical ticket*: you get access to the performance if you have an authentic physical ticket.

Well, as someone who goes to about twenty concerts a year, let me reset that. There are essentially no physical tickets.

If you get a ticket via the TicketMaster/LiveNation cartel, your ticket is a QR code on an app on your phone that uses a TOTP-like rolling code that changes every minute-like epoch.

Other ticket sellers have "physical" tickets. The scare quotes mean that they give you a PDF file that has a QR code, and when you enter, they scan the QR code. Some of these tickets have both a QR code and a linear barcode and either can be scanned.

The *only* actual physical tickets I've gotten in the last few years are for the SF Symphony, and those had a linear barcode on them. You can probably make the same snarky jokes about the symphonic clientele and ability to deal with so-called apps, or even PDFs.

But -- yeah.

Here's one more anecdote about tickets. I was one of the organizers of the ShmooCon infosec conference. Our tickets were barcodes. The barcode was only a UUID-looking thing that had the number of the conference (for easy discarding that) a hyphen, and then a 128-bit number. 

Our ticket database had an entry for each ticket and we just scanned the barcode and flipped a "spent" bit in the database.

> Today's physical tickets each have unique ID's, so there has to be a non-broadcast 1-1 synchronization mechanism in order to mediate access to the broadcast, and receive some sort of access token.

Well, today's tickets are bar codes. A person with a literal phone, often in a ruggedized case that likely has its own camera/scanner scans your bar code.

> But how do you keep someone who's already gotten an access token from re-distributing his token ("replay attack"), or re-broadcasting the material on another channel ("man-in-the-middle" attack) ?

What if they don't care? What if Auracast, being a BTLE tech only goes twenty meters outside the actual concert hall? Or not even past the stadium parking lot?

> Re-broadcasting should be noticeable due to the longer latency, but if he/she re-encrypts it with another key, how will anyone know that there's an illegal copy of the first broadcast ?

I don't think they actually care. There are also commercial enterprises that have web-based concerts that you can get via subscription or one-time pay. In these situations, there's a browser-based analogue to the so-called "analog hole" problem of old. Meaning that if you're sending HTML5 video streams to screen/audio system, it's gotta be in plaintext. Go to NUGS.NET if you want. There's also stageit.com that does live concerts. And on Bandcamp, there can be paid web-based live concerts, too. 

I apologize if my comments sound snarky, but I really think that those concerns are ones of a bygone era -- actual broadcasting. Pay-per-view is just logging into a web site and getting a stream.

In this day and age, probably 5% of the concert audience is getting a video of a given song, and another 10% is taking pictures of the performers. It's more likely than not that at least one of those will end up on YouTube, or Facebook. I've seen people actually stream live video to someone else. 

If the radio technology is about what we expect from BT/Wifi today, it's not really going to go very far, so it's not the same issue as satellite TV where literally the whole continent can listen in, once authenticated. The set of people scamming are people physically close, but not ticket holders, and not willing to just listen to the concert from the sidewalk. I would not be surprised that they just don't worry about it.

Now personally, I think that they're going to do all the beta testing on hearing aids, and you'll have to connect via that app. (Protocol-wise, you could write an app. I just mean that no audio player is going to connect to the stream via an audio player, it's going to be an experience similar to connecting to a Wifi SSID.

> This problem is somewhat analogous to the music CD/video DVD problem, since the CD's/DVD's are all identical (aren't they?).

If I were doing this, what I would do is have a handshake over BTLE that hands the device a session key. Yes, there's an authentication step, but there's plenty of ways to do that. I think that you should think of this problem to be more like connecting to Wifi than anything else, especially traditional broadcast encryption.

Previous "broadcast encryption" schemes were more focused on cable or satellite TV, but yeah. It's the same problem and BluRay did it best, which is probably why many people prefer DVDs.

> I assume that this digital broadcast problem has already been worked on, so I'm asking for references/links.

Here are some links that I found quickly, there's more out there. This was a bigger thing back in the days of Pay-Per-View, as Seth notes:

https://en.wikipedia.org/wiki/Broadcast_encryption

https://crypto.stanford.edu/~dabo/pubs/papers/broadcast.pdf

https://eprint.iacr.org/2025/323

https://taylorandfrancis.com/knowledge/Engineering_and_technology/Computer_science/Broadcast_encryption/

https://www.wisdom.weizmann.ac.il/~naor/PAPERS/broad.pdf

	Jon