6
$\begingroup$

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)?

Improve this question
$\endgroup$
3
  • 2
    $\begingroup$ Depending on who's doing it and why, it might be called a covert channel or (weak!) steganography. Neither of those seem applicable to your case, however. $\endgroup$ – K.G. Oct 12 '13 at 8:45
  • 1
    $\begingroup$ The relevant concepts are: "side channels", "covert channels", and "steganography". As K.G. said, covert channels or stego are probably the ones most relevant to you. $\endgroup$ – D.W. Oct 20 '13 at 5:19
  • 1
    $\begingroup$ Now that you have the terminology, it isn't difficult to find publications about packet size as a covert channel. If you're looking for prior art, what's your cut-off date? $\endgroup$ – Gilles 'SO- stop being evil' Oct 20 '13 at 11:19
2
+50
$\begingroup$

Specifically to answer your question of whether or no using the packet size in a wireless network is novel, the answer is no. See http://www.cs.washington.edu/research/projects/poirot3/Oakland/sp/PAPERS/2008/3168A311.PDF

Specifically in Section 4:

The exploit field chosen for the experiment is the 16- bit packet size field of a link layer protocol implementation for encrypted wireless data.

Improve this answer
$\endgroup$
2
  • 1
    $\begingroup$ This is exactly what I was looking for. The section in question references another paper "Covert channels in secure wireless networks" (see also the library record), also by authors from the Royal Military College of Canada. Section 4.4.2 ("UDP Packet Size vs MAC Frame Size Experiment") of this paper essentially describes exactly the process being used by Smart Config in the TI CC3000 device. $\endgroup$ – George Hawkins Oct 21 '13 at 15:49
  • 1
    $\begingroup$ As @Gilles points out - a Google search with the correct terms comes up with many hits. The paper "Covert channels in secure wireless networks" by P. Martin from 2007 seems to be one of the earliest references to this idea. $\endgroup$ – George Hawkins Oct 21 '13 at 15:59
5
$\begingroup$

This approach is likely not novel, but just an application of covert channel. This is example of paper about detecting UDP packet length steganography. Because there has been already packet length used for messaging so often that even its detection has been discussed in papers, this cannot be very novel. However, often the use of such side-channel is used for nefarious purposes, and it feels bit more novel to attempt to use the channel it because it is perceived easier than other alternative ways of configuring, not because of steganographic goals or by accident (in many cases covert channel was not intent of person encrypting the data).

Wikipedia has more information about covert channels.

Other covert channels which could be used include precise timing of the messages to send, using some of less used protocol fields, and so on. If an cryptographic algorithm contains random padding, that field can as well be used as a covert channel.

Usually this kind of approach is reserved for something nefarious: to vary length of the message means much more bits to send and/receive, thus a lot of energy is wasted to transport few more bits using this covert channel. However, the answer is yes: using mechanisms like this it is possible to communicate with devices which are not able to decrypt the data content of the packets.

Even the famous unbreakable encryption "OTP" leaks the length of plaintext, and thus even unbreakable encryption would allow use of such a covert channel.

Improve this answer
$\endgroup$
5
  • 2
    $\begingroup$ I think it is quite useful in a non-nefarious setup. A big issue with embedded devices is how to configure them to connect to a wifi network without adding extra hardware, e.g. a USB port, that increases the overall price but is only used once in the device's lifetime (to communicate an SSID and password to it). This approach allows small amounts of data (yes it is heavy in terms of cost per byte sent) to be communicated to the devices without any preconfiguration being required on either the sender or receiver side. $\endgroup$ – George Hawkins Oct 15 '13 at 11:55
  • $\begingroup$ My usual idea would be that the device would appear first as wifi connection point. This is of course trivial idea for anybody skilled in the art and therefore I thought that somebody likely has written article about it. Turns out I was right: wifi. Overall, your idea could work for some device. I think that the idea could be more appropriate to discuss on some IEEE's Internet of Things forums, than on this forum. They would likely have more know-how on the matter as well. $\endgroup$ – user4982 Oct 15 '13 at 14:33
  • 2
    $\begingroup$ The are many solutions to the problem of how to configure an embedded device with a network's SSID and password. Making the device an access point, and requiring users to switch to it as their AP in order to configure it, has been around for a while. However switching AP is something many non-technical end users aren't comfortable doing. There are many alternatives (see here for some). The process described in this question is one - it can be used to transmit an SSID and password. $\endgroup$ – George Hawkins Oct 18 '13 at 19:48
  • 2
    $\begingroup$ The TI CC3000 approach called Smart Config which under the covers transmits data as described here is one of the most user friendly approaches. However it has a number of serious issues (e.g. the MIMO and 802.11 protocol issues I mention). BlinkUp is also nice - you enter the network credentials into a mobile app that then transmits them by flashing the phone's screen such that a light sensor on the embedded device can pick them up (see also Timex Datalink from the mid-90s). $\endgroup$ – George Hawkins Oct 18 '13 at 19:59
  • $\begingroup$ It's a little unfair of me to accept the much briefer answer from mikeazo - however it does cover exactly the situation I was looking at. But this answer covers the core idea here - covert channels. $\endgroup$ – George Hawkins Oct 21 '13 at 16:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.