Hiding Secret Messages In Skype Silences 79
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."
source of funding for this project. (Score:1)
Go old school rather than packet level? (Score:4, Funny)
Re: (Score:2)
True, but the data rate would be much much lower than this can achieve, TFA says they can get almost 1 kilobit/second, good luck getting morse code that fast using pauses. And it would be easily decrypted assuming you didn't use a cipher on top of the Morse code system, while this is (supposedly) undetectable.
Re: (Score:1)
To the eye, an image with encoded input just looks a bit grainy. To the ear, a voice with encoded input would just sound like a bit of background noise,
Re: (Score:1)
Re: (Score:2)
If the people who are talking together wants to have some secret communication, then their whole conversation might be code. Side channel attacks are much more insidious because in any high security environment the source and destinations of traffic are closely monitored. So this looks like Alice is talking to Bob and that is entirely above board and legitimate, but in addition we're piggybacking secret data from Alice's computer that we've compromised to Bob who is our mole on the inside. Secure communicat
Eloquent silence (Score:2)
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: (Score:2, Insightful)
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: (Score:2, Interesting)
My guess is they even added in the 38 byte ethernet overhead. Yielding 66 bytes. Add 4 bytes for the codec and its fairly reasonable.
Of course they probably didn't use the 8021q ethernet overhead which is 42 bytes, or they wouldn't have any payload at all! (I suppose its possible... an empty payload is intuitively about as "silent" as you can get)
Re: (Score:2)
That doesn't make any sense. If they were including Ethernet and TCP/IP then Skype must have the most efficient voice codec ever to transmit voice with 60 bytes.
Remember it is 70 for silence but only 130 for voice.
Also how do you get 1kbit/s in the silence with 4 bytes per packet?
No Skype is definitely sending silence with 70 bytes.
Re: (Score:2, Insightful)
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: (Score:2)
If they were talking IPv6, UDP packet overhead is 48 bytes, leaving only 22 for keeping the CODECs synchronized and specifying how much silence is being encoded.
I note that some carriers deliberately inject what is called "comfort noise" - a small amount of background noise - during silences. This is to keep the user from becoming concerned that the connection has failed.
While I don't know whether, or how, skype does this, it would be reasonable to either actually send the connection's real background nois
Re: (Score:2)
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.
Re:Eloquent silence (Score:4, Interesting)
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: (Score:2)
First, I misspoke, and should have been mentioning milliseconds rather than seconds.
But, still, a keep alive packet arriving once a second should be sufficient, wouldn't you think?
Re: (Score:2, Informative)
+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: (Score:2)
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: (Score:1)
Sending two bytes is not the same as sending nothing.
The point is not that Skype sends packets for silence, but that it sends such big packets, despite obviously detecting the silence as such (otherwise the silence packages would be the same size as non-silence packages).
Re:Eloquent silence (Score:5, Insightful)
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: (Score:2)
Why not send them where the current 70 byte packets are sent?
After all, this decision has already been made and implemented in the Skype protocol, as they are doing one or the other already.
Re: (Score:2)
One word that makes it possible: buffering.
It wouldn't work with a realtime stream. TCP/UDP don't do realtime streams quite so well.
Re: (Score:2)
VOIP needs to be low latency, though, otherwise people get confused and try to talk over each other.
Re: (Score:2)
> 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.
You're confusing media-encoding with telephony. Media encoding occurs in non-realtime, so you can analyze a big chunk of data and plan ahead for both silence and bursts. Telephony is realtime. The more you delay the audio for analysis, the more annoying it becomes to the people having the conversation. With realtime telephony, you don't HAVE "X seconds" to buffe
Re: (Score:2)
You're confusing media-encoding with telephony. Media encoding occurs in non-realtime, so you can analyze a big chunk of data and plan ahead for both silence and bursts. Telephony is realtime. The more you delay the audio for analysis, the more annoying it becomes to the people having the conversation. With realtime telephony, you don't HAVE "X seconds" to buffer and delay transmission so you can analyze a chunk of audio that long.
Wait, wait, wait,...
Skype is already sending silence packets. Its ALREADY made the determination that it has silence, and packaged (something) differently.
So that pretty much makes the rest of what you said either totally wrong, or non germane.
Re: (Score:3)
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: (Score:1)
Since it doesn't contain any information, and it is identifiable as silence packet anyway, then why encrypt it?
Re: (Score:2)
Because there may be other data besides the ones saying "this is silence". Perhaps some identifier, a size, etc. Maybe there's control information like mouse coordinates (for whiteboard mode), maybe some text chat, etc.
As for not sending anything - well, Skype needs to send something in order to ensure the STUN is still active.
Re: (Score:2)
My assumption was for a keepalive in the protocol.
Otherwise, packets would stop coming if someone stops talking, and sooner or later the other side would have to assume you've hung up.
Sending the packet for the silence would be the equivalent to "I'm still here".
Re: (Score:1)
You don't need 70 bytes for a simple keepalive. That's the point. Nobody argues that no packets should be sent. But why such large packets?
Taking your analogy, it would be like holding a short monologue just to tell "I'm still here."
Re: (Score:3)
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 (Score:5, Insightful)
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: (Score:2, Informative)
It's not an exploit.
Re: (Score:2)
Wrong choice of words, but close enough.
One would exploit the information
Re: (Score:1)
If you are going to hide something, point everyone somewhere else. These guys are really using Youtube, but would prefer their Skype calls are monitored.
Re: (Score:1)
Of course, the opponent could just replace the data in the silence packages himself, thus closing that communication path for you. Normal people would not notice (otherwise that data transmission would not work to begin with).
huh (Score:2)
tl;dr: security by obscurity is a bad thing!
Re: (Score:2)
It really depends, you can still encrypt the hidden message, hence, it'd be almost impossible to tell if it's just plain old silence, or an encrypted message.
Re: (Score:2)
tl;dr: security by obscurity is a bad thing!
Maybe that's why this is an article about steganography rather than security?
I'm sure (Score:1)
paranoid mode engaged ! (Score:1)
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 ?
Re: (Score:3)
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: (Score:1)
70 bytes to transmit what could be transmitted in one byte (the status "no activity") seems very inefficient.
Re: (Score:2)
Re: (Score:2)
Except that the packet already has at least an 8-byte UDP header, a 20-byte IPv4 (or 40-byte IPv6) header, and a link-layer header of some sort. There's probably some sort of checksum and block padding within those 70 bytes (which may in fact include the UDP or TCP header as well).
Similarly, VNC tunneled over SSH doesn't use 1-byte and 2-byte packets. For a certain block-size for which I did calculations and watched some real-life traffic, actual packet payloads for the different relevant messages ar
Bitwise (Score:1)
Re: (Score:2)
http://search.dilbert.com/search?w=database+only+zeros&x=0&y=0 [dilbert.com]
Re: (Score:3)
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 appr
Move Along (Score:5, Funny)
Nothing to see hear.
Re: (Score:1)
Obviously. Nothing to see, because it is voice, and nothing to hear, because it is silence.
Waste of time (Score:1)
Re: (Score:3)
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?
Re: (Score:2)
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?
Posting as AC to slashdot where you will be moderated -1, Troll, and your message will never be read by the unknowing yet will be transmitted within a seemingly innocent data stream to thousands of people, thus providing you a covert data channel where it's not known who is the real recipient of the data and it's not possible to prove the covert message was received.
That's as good an explanation for apk as any, I suppose.
Whitespace! (Score:5, Funny)
C may currently have overtaken Java as the most popular language but Whitespace [dur.ac.uk] is going to overtake them all!
Re: (Score:1)
You seem to have posted to the wrong story.
But never mind, worse things happen at C.
I've seen this before (Score:1)
I've had a lot of chats with silences with hidden messages... mostly with women.
Obviously... (Score:2)
Using Reverse Polish Encryption, no doubt.
skype update in (Score:3)
3
2
1
Because MicroSoft will have none of this, obviously.
The quiet ones ... (Score:3)
Side channel communications is not news. (Score:3)
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.
But Can China Read It? (Score:2)
Beep (Score:2)
'Nuff said.
Old news (Score:2)
Believe me, there are HUGE amounts of secret data transmitted in the silences in conversations... with your significant other, at least.
If you play Skype calls in reverse... (Score:1)
Or not (Score:1)