I think everyone knows that we specialise in high encryption data links, anything from single layer IPSec right through to triple layer tunnelling and disparate routing, but for some customers that's not enough.
The internet is a collection of many separate networks connected together in a way that traffic can move freely from point A to point B via the most efficient route (most of the time). This routing is automatic and can only be influenced slightly from the A or B end. Interception of data travelling across the internet in its encrypted form is easy but it's virtually impossible to decode. You can determine however, the point of origination and destination, to snoop on encrypted tunnels you would need to compromise one of these. We make this far harder by using relay nodes in disparate jurisdictions so that the packet journey instead of being from A -> B is now from A -> Node1 -> Node2 -> Node3 -> Node4 -> B. This means any sampling of traffic between Node1 and Node2 for example would reveal ONLY Node1 and Node2 but not A or B. In order to locate the traffic source or destination ALL the relay nodes would need to be compromised upstream or downstream. That is, from a sample between Node1 and Node2 you would need to physically compromise Node1 to find A and Node2 to find Node3, and Node3 to find Node4 and Node4 to find B. In reality we don't use 4 relay nodes but instead use a minimum of 10, usually more. The nodes themselves are a mixture of cloud hosting (free and paid), virtual and physical servers, Tor network nodes and public proxies. Some of the 'free' services are less reliable but a little smart routing solves this problem.
You can see however, that there IS a way, given enough resources and physical access to the locations holding nodes along the path to discovery the A and B ends and then compromise them. We needed a way to break this digital chain for one customer so there was no internet 'connection' between A and B. This method of breaking the chain is known as out-of-band routing and often utilises either private networks or non-data networks. A good example of out-of-band routing was to use Modem's and have part of the route travelling over analogue phone lines but in recent years this has become less secure because as technology evolves its easier to discover and monitor calls between countries and determine start and end physical addresses. We can make this harder by placing the originating or receiving modem in countries with antiquated telephone systems but then you run into data issues and a reduction in the already low bandwidth.
A new customer provided the impetus for finding a new way to break the chain in a new out-of-band transport and the solution was ingenious, even if I do say so myself. Whilst the job has now completed and the route is no longer in use, I will not be sharing the location, country or any media from the actual connection because that would be idiotic. The image above is a library shot of a Marvel digital display board and not the manufacturer used and is there for illustration only. What I will do is describe the adopted solution to the problem.
After much discussion and consideration of point to point laser, microwave, hijacking local radio and piggybacking satellite TV we were in the unusual position of being at a loss. We know what we wanted to do, just not how to achieve it and this continued for about a week. One idle Tuesday during lunch one of our tech's was browsing CCTV live feeds on Youtube and like a clap of lightning the idea was born. We would utilise a CCTV Live stream and some form of transmission to act as the out-of-band route, but how would we transmit the data? Luckily the data rate is very very low consisting of bytes per minute instead of the usual Mb/s and was unidirectional (one way) so it could be something very analogue but it took another full week to come up with the transmission medium.
Whilst browsing hundreds, if not thousands of live cctv feeds we noticed in one, an unremarkable street with an equally unremarkable bus stop with what looked like a digital sign on the end. We spent some considerable effort trying to identify the company name from the bottom of the sign by enhancing the imagery and applying various filters only to later notice that one fo the ad's loosely translated as 'advertise here' call this number.
Calling the number, finding a translator, calling the number again this time with the translator and after some some negotiation we purchased ad-space on this specific sign for a period of time, and no we didn't use a credit card. After receiving the credentials we were able to access the sign's http interface (yes http) and upload some sample ad's which were in fact just images that are played in a loop with various transitions. Some php code later and we had the auto-upload working.
Now we need to figure a way to transmit data from the sign and pick it up again in the CCTV live feed. After many attempts we settled on an ad which consisted of a number of white squares on a black background with some unimportant company branding which we totally made up. Streaming the CCTV image was simple, converting it from frames to separate images, removing all the duplicate images leaving only the changes was a fairly simple if not a laborious job. Parsing the images to determine the actual data took a little more time but again wasn't hard to do. From a technical point we broke the image into separate area's, calculated the intensity of the area as an average and then converted that into a simple 0 or 1. I know some of you may be thinking that we could have gone with barcodes, QR codes and others with much higher data density but this specific project required very low data rates.
We tested the solution over several days sending images to the display panel in batches of 1, recording them from the live stream, decoding them and comparing the data. A few changes were made to the layout and intensity was lowered during the dark hours to improve capture clarity. We did occasionally have people standing in the way but we wrote code to detect this by including a persistent layout of squares that we then verified before decoding the data and sending it on.
Now we need to setup the rest of the route, which we did in 14 nodes between the A end and the remote server that was taking bit data, converting it into an image and uploading to the sign, and another 10 nodes from the remote server capturing the live stream, decoding and forwarding on the data to the B end.
As we had no access to the A or B end we were unable to test further ourselves but our customer tested the connection themselves and were satisfied with both the performance and the security strategy.
Its important to state that we do not know the purpose of, the data transmitted, or indeed even the customer as we were dealing with an agent, sometimes called a proxy, but we do know the customer was happy with the solution. Remember that this is an extreme case with uncommon prerequisites and for most a string of relay nodes and two layer encryption is more than sufficient to prevent unauthorised interception. If you can think of a better way to achieve out-of-band communications then please leave us a commend, if you found this interesting then please rate it.