Breaking the Digital Chain: Out-of-Band Routing Through a Bus Shelter

Breaking the Digital Chain

Two ends, no connection between them. 24 relay nodes. A few bytes a minute, carried as light across a public street. This is the story of one of the more unusual links we have ever built, and why sometimes the strongest chain is the one that is deliberately broken.

We spend most of our time on high-encryption data links: IPSec at one layer, triple-layer tunnelling at the far end of the scale, and relay routing in between. For most needs that is more than enough. Occasionally a requirement comes along that none of it answers, and this was one of those.

Why Relay Routing Is Not Always Enough

The internet is a collection of separate networks joined so that traffic finds its own way from point A to point B. Encrypted traffic crossing it is easy to sample and, in its encrypted form, effectively impossible to read. What a sample does reveal is the two things at the ends: where the traffic came from and where it is going.

We make that far harder with relay nodes in different jurisdictions. Instead of A talking straight to B, the path becomes A, to node 1, to node 2, to node 3, to node 4, to B. Anyone sampling between node 1 and node 2 sees only those two nodes, not A and not B. To walk the chain back to either end you would have to compromise every node along it, in order: node 1 to find A, node 2 to find node 3, and so on. In practice we do not use four nodes but a minimum of ten, usually more, a mix of cloud hosts, paid and free virtual and physical servers, Tor nodes and public proxies, with a little smart routing to paper over the less reliable ones.

It is very strong, but it is not infinite, and the reason is worth being honest about. Diversity makes the route hard to follow, but it is still a route: every hop knows the next one. It remains a chain, and a chain can be walked. Given enough resources and physical access to the places the nodes live, there is in principle a path back to the ends. For one project, "hard to follow" was not good enough. The brief was very specific: one way, a low data rate, and no way to follow the route node by node. There had to be no connection between A and B at all, so that following it from either direction led not to the other end but to nothing.

Out-of-Band Routing

Breaking the chain like this is known as out-of-band routing: you carry part of the journey over something that is not the data network. The classic example used modems and analogue phone lines. That has become weaker over the years, because calls between countries are now far easier to discover and monitor. You can push back by placing a modem in a country with an antiquated telephone system, but then the already low bandwidth drops further and the data becomes awkward.

We considered point-to-point laser, microwave, hijacked local radio and piggybacking on satellite TV, and for about a week we were genuinely stuck: we knew exactly what we wanted, and not one practical way to do it. The data rate needed was tiny, a few bytes a minute, and it only had to travel one way. That turned out to be the clue.

The Idea, Over Lunch

One idle Tuesday, over lunch, one of the team was browsing live CCTV feeds on YouTube, and the idea arrived like a clap of lightning. If a camera somewhere was already streaming a public view to the internet, and we could put something in that view that we controlled, the camera itself became the out-of-band hop. No link from us to the camera, no link from the camera to the viewer: just light, and a public video stream anyone could watch.

What we needed next was a display we could write to that sat in a public camera's view. Browsing hundreds, then thousands, of live feeds, we found it: an unremarkable street, an equally unremarkable bus shelter, and a small digital advertising sign on the end of it. The sign carried its own adverts, and one of them, loosely translated, said "advertise here, call this number".

Buying a Billboard to Send a Byte

So we did. We called the number, found a translator, called again, and booked advertising space on that one sign for a period of time. The credentials that came back gave us the sign's web interface, over plain HTTP, and the ability to upload adverts, which were simply images played in a loop with transitions. A little PHP automated the upload.

The advert we settled on was not a picture of anything. It was a grid of white squares on a black background, dressed up with some invented company branding so it looked like an ordinary, slightly dull advert and nobody would stop to study it. Each square was either lit or dark. Read the brightness of each square and you have a grid of ones and zeros.

Reading Light Back Into Data

At the far end, the job was to turn the CCTV stream back into bytes. That meant pulling frames from the live feed, discarding the many duplicate frames so only the changes remained, and then, for each remaining frame, dividing the sign into areas, taking the average brightness of each area, and calling it a one or a zero. Error correction on top caught the mistakes.

We could have reached for QR codes or barcodes and carried far more data per frame. We deliberately did not. The data rate needed was tiny, and it mattered that the sign looked boring: a flickering QR code draws a crowd, and a crowd stands in front of your transmitter. Plain squares, changing slowly, drew nobody.

People did occasionally stand in the way, so the error correction was written to spot a blocked frame and throw it out rather than trust it. We lowered the brightness during darkness so the camera's night exposure did not wash the grid out. Over several days of testing, sending batches to the sign, recording them from the stream, decoding and comparing, we tuned the batching, the layout and the brightness until it was reliable.

The Finished Route

With the light hop working, we built the rest of the path around it: 14 relay nodes between the A end and the server that turned incoming bytes into an image and pushed it to the sign, and another 10 nodes from the server that captured the live stream, decoded it and forwarded the data on towards B. Follow the network inward from A and you reach a server uploading adverts. Follow it inward from B and you reach a server watching a video. Between the two there is only a bus shelter, a camera, and a public street.

The Point

The data rate was frankly tragic: a few bytes a minute, one way. At that speed it could never carry more than short text, and we suspected it was a proof of concept for something larger that we would never see. We took it on anyway, because it was genuinely interesting, and we like interesting.

It is also worth being clear about what makes it different, because it is not a better tunnel. Every standard technique, multipath fragments, nested encryption, genuine satellite-and-ground diversity, works by obscuring the route: making the chain so hard to follow that walking it is not worth anyone's while. They are the right answer almost every time. This was not about obscuring the route but severing it. Reach the sign and there is no next hop to compromise, because the next hop is a beam of light and a camera that has no idea either end exists. You sever the route rather than hide it only when hard to follow is not good enough, and you pay for it in bandwidth.

This is an extreme case with uncommon prerequisites, and we are not suggesting anyone needs it. For almost everyone, a handful of relay nodes and two layers of encryption are more than enough to keep traffic from being traced or read. What the project shows is the principle we keep coming back to: security is strongest when it does not depend on trusting the network, or any single part of it. Sometimes the most robust link of all is the one you break on purpose.

If you can think of a better way to achieve out-of-band communication, we would genuinely like to hear it.