If you've only got an encrypted data channel can you actively sidestep the encryption and communicate with an outside party who can see the data but cannot decrypt it?
Yes - if you can find some leaky aspect in the process that's still visible after encryption.
Is there a name for this? And is scheme I came across recently that does this, by encoding data into the lengths of data packets already well known?
On a wifi network using e.g. WPA2 one can expose data not in the contents of individual UDP packets but in their lengths if one takes care to keep their length below the network MTU.
The encryption used affects the lengths of the wireless packets, but in a consistent way, i.e. all packets will be L bytes larger, where L is a constant, than they would have been without encryption
So even if one cannot decrypt the packets one can recover the original lengths easily.
If someone on the network encodes the information they want to communicate into the packet lengths then anyone who can monitor the network traffic can recover this information.
I came across this approach recently in an embedded wifi module - as well as packet length it takes advantage of other things that are still visible despite decryption, in particular that one can still group traffic by source and destination MAC address.
An application running on a machine on the secure network encodes the information that it wants to send into the lengths of UDP packets that it then sends to another party on the network - the wifi access point (AP). That the AP isn't interested in receiving the packets is irrelevant, what's important is that the packets are visible on the network.
The outside device can spot the packets (there are other tricks involved to allow it to zero in on the relevant packets, filtering them out from the masses of other traffic that is visible to such a device running in monitor mode) and it then decodes the information from the packet lengths.
There's nothing nefarious going on here - the approach is just used to communicate small amounts of information to the embedded devices and has the advantage that the devices (that have no screen or keyboard) do not need to be preconfigured with the SSID and password for the network and also means that the sending application does not need to know any information about the receiving devices, i.e. IP address and such like.
This approach sounds clever but to be honest I don't know why they don't just use wifi probes, encoding the data in the SSID specified in the probe, i.e. the probe wouldn't contain the SSID of any real network but rather the SSID specified would encode information that anyone monitoring the network could see.
In fact this is exactly what the manufacturer in question used to do (as described here) back when they felt all the relevant information they needed to send could be encoded into the 32 bytes available to specify an SSID in a single wifi probe.
They moved to the new scheme, involving UDP packets, in order to send arbitrarily large amounts of data. However I can't see why they didn't just move to sending a stream of wifi probes (with sequence information etc. encoded as part of the dummy SSID) - this would remove an issue with the current approach - that the receiving device must be able to handle, i.e. monitor, the 802.11 protocol that the sending device uses when talking to the AP. E.g. if the receiving device only really understands 802.11b and 802.11g but the sending device is talking to the AP (running in mixed mode) using a newer protocol then there will be problems that wouldn't exist with wifi probes (which on a mixed mode network are independent of the 802.11 protocol).
In particular even if both the sending and receiving device support 802.11n MIMO places an extra requirement on the receiving device - in order for it to be able to monitor the sending device's 802.11n traffic it must have at least as many MIMO capable antennas as that device, which is problematic if the receiving device is a small embedded systems module while the sending device is e.g. a desktop with high end wifi support.
Update Oct 13, 2013: they probably don't use wifi probes as Apple provides no public interface to send or receive them in iOS.
But back to my original question - is this approach of encoding information in packet lengths, in order to actively side step encryption, novel or is it a known approach (perhaps applied previously in a different environment to wifi)?