GSoC project idea: pluggable transport that hides data in TCP SEQ numbers / UDP SRC ports
Hi,
I recently had an opportunity to watch David Fifield's lightning talk on pluggable transports that he gave on 30C3. I find the topic fascinating and I'm considering an application to your project for the upcoming Google Summer of Code.
My idea is a bit complicated - I'd like to create a pluggable transport that hides data in TCP sequence number gaps or UDP source port numbers. I don't yet have all details thought over, but the way I imagine it right now, the user would have to establish a TCP or UDP connection to the relay. The connection could be completely bogus, though it'd be useful if a lot of data was sent over it. After connecting, the client sends to the server a message with a random RSA key steganographically hidden in the TCP sequence numbers. If the server replies the same way with an RSA-encrypted AES key, the rest of the hidden transmission goes encrypted with it. Since the SEQ number gaps are meant to be random anyway, I believe that this could be very hard to detect.
Obviously, this is a very difficult project. I'd like to point out that I already have some experience in both GSoC (worked for Nmap Project last summer, David Fifield was my mentor) and C programming. I imagine that I'd need to create some kernel-to-userspace interface that would let me do the packet manipulation - I'd probably start my research by looking at how OpenVPN implements this kind of stuff as it supports all major platforms.
The main question is - would you be interested in mentoring such a project during the upcoming summer?
Yours, Jacek Wielemborek
On Tue, Jan 07, 2014 at 06:41:02AM -0800, Jacek Wielemborek wrote:
Hi,
I recently had an opportunity to watch David Fifield's lightning talk on pluggable transports that he gave on 30C3. I find the topic fascinating and I'm considering an application to your project for the upcoming Google Summer of Code.
My idea is a bit complicated - I'd like to create a pluggable transport that hides data in TCP sequence number gaps or UDP source port numbers. I don't yet have all details thought over, but the way I imagine it right now, the user would have to establish a TCP or UDP connection to the relay. The connection could be completely bogus, though it'd be useful if a lot of data was sent over it. After connecting, the client sends to the server a message with a random RSA key steganographically hidden in the TCP sequence numbers. If the server replies the same way with an RSA-encrypted AES key, the rest of the hidden transmission goes encrypted with it. Since the SEQ number gaps are meant to be random anyway, I believe that this could be very hard to detect.
Only the initial SEQ of a TCP connection is random (and usually only ~24 bits at that). The subsequent SEQs are deterministic. Can you clarify your intent?
- Ian
Hello Jacek and all,
Before, going down this path I would recommend reading the very relevant works:
*Embedding Covert Channels into TCP/IP* *Steven J. Murdoch, Stephen Lewis http://www.cl.cam.ac.uk/%7Esrl32/* It is commonly believed that steganography within TCP/IP is easily achieved by embedding data in header fields seemingly filled with “random” data, such as the IP identifier, TCP initial sequence number or the least significant bit of the TCP timestamp. We show that this is not the case; these fields naturally exhibit sufficient structure and non-uniformity to be efficiently and reliably differentiated from unmodified ciphertext. Previous work on TCP/IP steganography does not take this into account and, by examining TCP/IP specifications and open source implementations, we have developed tests to detect the use of naïve embedding. Finally, we describe reversible transforms that map block cipher output into TCP ISNs, indistinguishable from those generated by Linux and OpenBSD. The techniques used can be extended to other operating systems. A message can thus be hidden in such a way that an attacker cannot demonstrate its existence without knowledge of a secret key. *7th Information Hiding Workshop http://www.uoc.edu/symposia/ih05/, Barcelona, Catalonia (Spain), 06–08 June 2005. Published in LNCS 3727 http://www.springerlink.com/content/978-3-540-29039-1/, Springer-Verlag.*[ paper http://www.cl.cam.ac.uk/%7Esjm217/papers/ih05coverttcp.pdf ]
and
John Giffen, Rachel Greenstadt, Peter Litwack, Richard Tibbetts, Covert Messaging in TCPhttps://www.cs.drexel.edu/%7Egreenie/eecs_files/tcpcovertchannels.pdf, Privacy Enhancing Technologies (PET), April 2002 http://www.pet2002.org
Best regards,
George
On Tue, Jan 7, 2014 at 4:02 PM, Ian Goldberg iang@cs.uwaterloo.ca wrote:
On Tue, Jan 07, 2014 at 06:41:02AM -0800, Jacek Wielemborek wrote:
Hi,
I recently had an opportunity to watch David Fifield's lightning talk on pluggable transports that he gave on 30C3. I find the topic fascinating
and I'm
considering an application to your project for the upcoming Google
Summer of
Code.
My idea is a bit complicated - I'd like to create a pluggable transport
that
hides data in TCP sequence number gaps or UDP source port numbers. I
don't yet
have all details thought over, but the way I imagine it right now, the
user
would have to establish a TCP or UDP connection to the relay. The
connection
could be completely bogus, though it'd be useful if a lot of data was
sent
over it. After connecting, the client sends to the server a message with
a
random RSA key steganographically hidden in the TCP sequence numbers. If
the
server replies the same way with an RSA-encrypted AES key, the rest of
the
hidden transmission goes encrypted with it. Since the SEQ number gaps are meant to be random anyway, I believe that this could be very hard to
detect.
Only the initial SEQ of a TCP connection is random (and usually only ~24 bits at that). The subsequent SEQs are deterministic. Can you clarify your intent?
- Ian
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
This is an attempt at security though obscurity, which doesn't work well in open source projects.
On Tue, Jan 7, 2014 at 10:09 AM, George Danezis georged@gmail.com wrote:
Hello Jacek and all,
Before, going down this path I would recommend reading the very relevant works:
*Embedding Covert Channels into TCP/IP* *Steven J. Murdoch, Stephen Lewis http://www.cl.cam.ac.uk/%7Esrl32/* It is commonly believed that steganography within TCP/IP is easily achieved by embedding data in header fields seemingly filled with “random” data, such as the IP identifier, TCP initial sequence number or the least significant bit of the TCP timestamp. We show that this is not the case; these fields naturally exhibit sufficient structure and non-uniformity to be efficiently and reliably differentiated from unmodified ciphertext. Previous work on TCP/IP steganography does not take this into account and, by examining TCP/IP specifications and open source implementations, we have developed tests to detect the use of naïve embedding. Finally, we describe reversible transforms that map block cipher output into TCP ISNs, indistinguishable from those generated by Linux and OpenBSD. The techniques used can be extended to other operating systems. A message can thus be hidden in such a way that an attacker cannot demonstrate its existence without knowledge of a secret key. *7th Information Hiding Workshop http://www.uoc.edu/symposia/ih05/, Barcelona, Catalonia (Spain), 06–08 June 2005. Published in LNCS 3727 http://www.springerlink.com/content/978-3-540-29039-1/, Springer-Verlag.*[ paper http://www.cl.cam.ac.uk/%7Esjm217/papers/ih05coverttcp.pdf ]
and
John Giffen, Rachel Greenstadt, Peter Litwack, Richard Tibbetts, Covert Messaging in TCPhttps://www.cs.drexel.edu/%7Egreenie/eecs_files/tcpcovertchannels.pdf, Privacy Enhancing Technologies (PET), April 2002 http://www.pet2002.org
Best regards,
George
On Tue, Jan 7, 2014 at 4:02 PM, Ian Goldberg iang@cs.uwaterloo.ca wrote:
On Tue, Jan 07, 2014 at 06:41:02AM -0800, Jacek Wielemborek wrote:
Hi,
I recently had an opportunity to watch David Fifield's lightning talk on pluggable transports that he gave on 30C3. I find the topic fascinating
and I'm
considering an application to your project for the upcoming Google
Summer of
Code.
My idea is a bit complicated - I'd like to create a pluggable transport
that
hides data in TCP sequence number gaps or UDP source port numbers. I
don't yet
have all details thought over, but the way I imagine it right now, the
user
would have to establish a TCP or UDP connection to the relay. The
connection
could be completely bogus, though it'd be useful if a lot of data was
sent
over it. After connecting, the client sends to the server a message
with a
random RSA key steganographically hidden in the TCP sequence numbers.
If the
server replies the same way with an RSA-encrypted AES key, the rest of
the
hidden transmission goes encrypted with it. Since the SEQ number gaps
are
meant to be random anyway, I believe that this could be very hard to
detect.
Only the initial SEQ of a TCP connection is random (and usually only ~24 bits at that). The subsequent SEQs are deterministic. Can you clarify your intent?
- Ian
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On Fri, 10 Jan 2014 00:19:32 +0000, Jim Rucker wrote:
This is an attempt at security though obscurity,
I think you mean 'nondiscoverability through obscurity'; transport security would be in a different layer. What is tunneled in an obscure way is still the regular tor protocol which provide encryption on their own.
Also the question is not 'can it be detected' but 'can a detector be integrated into existing filter systems, how long would that take, and is it worth the trouble'.
...
On Tue, Jan 7, 2014 at 10:09 AM, George Danezis georged@gmail.com wrote:
...
used can be extended to other operating systems. A message can thus be hidden in such a way that an attacker cannot demonstrate its existence without knowledge of a secret key.
Also, this exactly does *not* sound like 'obscurity'.
Andreas
-
Andreas Krey -
George Danezis -
Ian Goldberg -
Jacek Wielemborek -
Jim Rucker