Hiding Secret Messages In Skype Silences

Orome1 writes "A group of researchers from the Institute of Telecommunications of the Warsaw University of Technology have devised a way to send and receive messages hidden in the data packets used to represent silences during a Skype call. After learning that Skype transmits voice data in 130-byte packets and the silences in 70-byte packets, the researchers came upon the idea of using the latter to conceal the sending and receiving of additional messages."

Comments

Go old school rather than packet level?

[Keruo]

If you talk long conversation, specific pauses might simply work as morse code.

Eloquent silence

[maxwell demon]

I wonder why Skype needs 70 bytes to transmit essentially nothing. Maybe they already do use it for secret data transmission, just to their own servers?

Re:Eloquent silence

[Anonymous Coward]

UDP overhead is 28 bytes for ipv4. Add in overhead for the audio codec to represent a timeframe for a sound and 70 bytes become reasonable.

Re:Eloquent silence

[hawguy]

Exactly what I was thinking.

You would think that a packet specifying X seconds of simulated silence could be packed into a few bits, so maybe two bytes should suffice.

Clearly there is something else going on, or they would not have designed such a large packet to "represent silence".
That one can distinguish the silence packets from the voice packets doesn't speak too well of the encryption that Skype has always claimed they use.

If the Skype client didn't send packets during 'silence', then the client on the receiving end of an extended silent session wouldn't know whether there was silence on the other end or a network problem. That's why the client keeps sending packets even during "silence" rather than just timing silent sections then sending out a packet at the end of the silence saying "It was silent for the past 10 seconds, so that's why you didn't receive any data from me".

Re:Eloquent silence

[Minwee]

Exactly what I was thinking.

You would think that a packet specifying X seconds of simulated silence could be packed into a few bits, so maybe two bytes should suffice.

Were you planning on sending that "two seconds of silence" packet at the _start_ of the pause? If so I know a few theoretical physicists and at least one state lottery commission who would _love_ to see your algorithm.

Re:Eloquent silence

[tlhIngan]

I wonder why Skype needs 70 bytes to transmit essentially nothing. Maybe they already do use it for secret data transmission, just to their own servers?

Encryption padding, I'd guess. Use something like AES which only works on 128/192/256 bit blocks (depending on key size)(16/24/32 bytes) and if you have a short packet of silence, it has to be padded in order to be encrypted. I'm guessing there might be a header and other stuff that pushes it to 70 bytes.

Re:Eloquent silence

[Anonymous Coward]

Btw, Silence is a sound for computers which is represented by a flat line or basically the value of 0. Not getting packets and getting a value of 0 are different things whereas the former can be due to packet lost and broken connection while the latter is an actual value.

Re:Eloquent silence

[Anonymous Coward]

+1

Skype is far from the first VoIP protocol to do this.

http://en.wikipedia.org/wiki/Voice_activity_detection
http://en.wikipedia.org/wiki/Comfort_noise

Re:Eloquent silence

[maxwell demon]

It is obvious that Skype uses voice activity detection, or else the silence packets would be as large as the voice packeage. The whole point is why they are still quite large (large enough to send a substantial amount of data).

The second link is totally irrelevant because it doesn't concern the sender, but the receiver. The noise the receiver generates certainly does not depend on the size of the silence packages the sender sends.

Re:Eloquent silence

[ottothecow]

Maybe they found they were having trouble with traffic shaping/QOS type systems.

Have to keep something decently sized flowing through the connection or it gets de-prioritized and then when real content starts flowing again, it lags? I don't know if this is true, but it sounds like a reasonable explanation considering how skype's design is so heavily focused on being able to punch through hostile networking environments and maintain a workable stream.

There goes that idea

[Jeng]

If you are going to hide something, don't let everyone know where you put it.

Now that the exploit has been discussed it will be watched out for.

Re:There goes that idea

[Anonymous Coward]

It's not an exploit.

Move Along

[Anonymous Coward]

Nothing to see hear.

Re:paranoid mode engaged !

[hawguy]

So skype has 1kilobit/sec spare capacity when transmitting silence ? How much data does it actually sent then ? just for silence ?
This protocol is either very inefficient, or there is reason for this 'waste' of bandwidth. So what does skype use it for ?

From TFA, it's 70 bytes per packet (560 bits, excluding packet overhead), so less than 2 packets/second gives 1kbit/second of data. That doesn't seem all that inefficient.

Re:Waste of time

[hawguy]

There are a million ways to communicate in secret, and this ranks among the stupidest.

Which ways are less stupid than hiding your packets in a stream that's believed to be innocuous and even if the voice packets are monitored, your hidden data would presumably remain hidden?

Whitespace!

[Vlad_the_Inhaler]

C may currently have overtaken Java as the most popular language but Whitespace is going to overtake them all!

Re:Bitwise

[vlm]

Each side has a very smart bridge.

If bridge A sees an incoming 130 byte packet from the LAN side thats obviously skype, pass it.
If bridge A sees an incoming 70 byte packet from the LAN side thats obviously skype, add a 60 byte encrypted / hashed / whateverd back channel of data.

If bridge B sees an incoming 130 byte packet from the LAN side thats obviously skype, ram it thru the decrypt / dehash / whateverd thing and see if the last 60 bytes decodes to a valid back channel data packet. To a crude first approximation your bit error rate will approximate your magic number or header or whatever length, so requiring the decrypted packet data to begin with 0x1234 means you'll only false positive about once in 2**32 decodes, probably good enough for text, maybe not so good for DVD iso transfer.

This simple idea is pretty simple to traffic analyze. Are the conversation patterns more like speech or embedded text? A slightly intelligent algo on the TX side could fix that (perhaps only the first silence packet after normal speech gets special data, or it only sends special data in a vaguely normal conversational (very) random pattern). You can come up with traffic analysis systems all day.. my rev-2 design could be caught by displaying a histogram of how long each stretch of silence is, how odd that this convo 1 packet long silences match the typical graph for 2 packet long silences instead of typical 1 packet long...

skype update in

[dutchwhizzman]

3

2

1

Because MicroSoft will have none of this, obviously.

The quiet ones ...

[PPH]

... have the loudest minds.

Side channel communications is not news.

[Frobnicator]

Side channel attacks are old-school but any security researcher worth their title knows about them.

This was a popular attack in the 60's and 70's for governments.

Decades ago CS programs taught about how spies once leaked data from secret-privileged machines by emitting communications through CPU load, or through disk usage, or through various other timing attacks.