Reportx - Bitbucket

childrenpenNetworking and Communications

Oct 26, 2013 (3 years and 7 months ago)



Final Project
Socket Programming

ECSE 489

Telecommunications Network Lab

Winston Lin


Xiao Yu



This report
concerns the design of a protocol for
network traffic steganography.
The communication protocol
explained is one that is capable of embedding a secret message in
a file transfer by changing packet statistics.
Included is a
solution for the design problem as well as the methodology
behind the design.




lem Statement

The problem of this experiment involves implementing a
protocol for network traffic steganography by embedding a
secret message within the statistics of each packet during a file
The primary goal with steganography is not to hide
he existence of the transfer itself, but to hide a message within
the transfer in such a way that no one, apart from the sender
and intended recipient, suspects the existence of the message.

Therefore, the protocol must not affect how TCP operates
nor chan
ge the

data being sent.
satisfy the design
constraints below.

The protocol must be efficient and capable of encoding
as much as possible.

The protocol must be secure such that eavesdroppers
t easily decode the message.

The protocol must attempt to be invisible and difficult
to detect.

The protocol must
be robust and not easily interfered

Essentially, the hidden message
must work smoothly
without attracting attention. And
the message



be difficult to decode.


Design Methodology

The first idea to keep in mind while solving this problem
was that there will almost certainly be trade
offs between the
efficiency and the security of this protocol.
For one,

the more
ormation of the hidden message that is inserted into each
packet, the easier it will be to detect its existence. Furthermore,
the more the
is encoded

for security purposes
, the less
amount of the
message each packet
is likely to hold.

This results in
a slower rate of packets being sent.

The next step was to identify the various packet statistics
that can be modified to accomplish the goal of network traffic
steganography. Using the research done in [1] as a base, the

in Figure 1 below were

as possible
choices for this application.

Figure 1.

TCP/IP Header Structure

After weighing the pros and cons of the various
possibilities, the IP identification

field (IP ID) was selected as a
strong choice for this protocol.
This field is used to distinguish
fragments making up one packet from another, with the only
constraints on its value being the uniqueness over the length of
time that fragments of a packet

might remain in a network [1].
It ensures that fragments of different packets are not
reassembled into one packet on the receiving host.
advantages and disadvantages of

this field are
in Table 1 below.






Does not disrupt normal
network operations

Relatively efficient due to
having 16 bits of the IP header
per packet to work with

Relatively easy to understand
and simple to implement

Must be partially unpredictable
to begin with to prevent
attacker ex

May be detectable since the IP
ID field is not entirely random

Perhaps the most important concern for this experiment
from Table 1 above is that the formation of the IP ID is not
entirely random.

According to [1], the formation of the IP ID
follows several possible patterns depending on the operating

However, the paper also implies that there are
numerous strategies and that not all possibilities were
examined, so being able to detect ab
normal alterations in the IP
ID remains difficult.


With the decision on using the IP identification field now
made, the next step was to design the actual communication

One scheme that was particularly desired was port
knocking, so that a sender

must knock on a specific sequence
of ports before being allowed to establish a secure connection
with the receiver.

This prevents an attacker from port scanning
a system because unless the correct knock sequence is
performed, the protected port will appe
ar closed.

Thus, the communication protocol begins with the port
knocking scheme. During this part of the protocol, ports on the
receiver’s end are knocked in a particular order
prior to the transmission. To further make use of this step,
ful information is
also exchanged on each knock

On the first knock
, a

key is exchanged
to allow the
sender to encode the message.


will be
performed using standard RSA methods explained in [2].

the second knock, the size of the t
ransmission is sent. This
allows the server to know exactly how large is the

be able to secure its ports appropriately.

On the last knock, a
final random port is chosen for the transmission. This provides
some randomness to the port
g scheme for security

Once the final port is chosen, a TCP three
way handshake
is performed. This serves no real purpose but to better disguise
the transfer as legitimate. Observations using a packet sniffer
such as Wireshark have shown that no
t performing this step
will attract attention to the packets being transferred.

The last step of the protocol is to perform the actual file
Hidden in the IP ID of each packet will be parts of the
hidden message encrypted using the RSA public k
ey agreed
upon earlier. Once the message is received, the receiver
decrypts the message using the private key.

The communication protocol algorithm
in its entirety is

in Figure 2 below.

Figure 2.

Communication Protocol


Design Outcome

The initial design was followed while programming
the new criteria that the process be programmed as to loo
k as
unsuspicious as possible in Wireshark. Since
inspects many aspects of the TCP protocol and highlights
malformed packets, the program was made to follow the rules
of TCP/IP trans
mission as much as possible.

The programming was entirely built

using the Scapy

framework for Python.
The framework offered convenient
packet manipulations without having to worry about
interfaces or memory issues.

The application is divided into the sender and receiver
parts. The sender
holds the secret

message to transfer and the
receiver holds the private RSA key to decrypt the message.

The port knocking is implemented as previously described.
The receiver
monitors all traffics to its TCP port 9534 initially
and for each packet received, inspects its I
P ID. This process
loops until the ID received

is 7341 (a pre
agreed code). This
ensures the sender is intending to use our steganography
application to send a secret message.

At this point, the receiver produces a pair of RSA keys and
sends the public key as payload
of a ping request. The receiver
then waits for a transmission on the TCP port 7192 where it
will xor the received packet’s IP ID by all 16 bits
and interpret
the re
sult as the number of packets to expect for the entire
length of the secret message.

A third port knock on TCP port 8290 embeds the xor’ed
port number to use for all following transactions in the IP ID.

Then, the receiver listens for the previously determi
number of packets from the sender IP on the previously agreed
port to use. On each resulting packet, a programmatic filter is
first applied.
On condition that the source IP is correct, the
destination port number is correct and sequence number is not a

duplicate, the process will be processed by another method.

On the sender side, the application is called by specifying
the destination IP as well as the message to
transmit. The user
optionally can choose to send a file as packet payload for
The s
ender then perform the port knocking as described
above. After receiving the public key, the secret message is
encrypted with the public key and
the optional file’s size is
checked to make sure it can source enough packets to hide the
entire encrypted secr
et message.

The encrypted secret message’s length is sent during the
second port knock and a random port between 6000 and 9000
is chosen and sent during the third port knock.

The sender then
chooses a random number between
100,000 and 10,000,000 as the sta
rting TCP sequen
ce number.
The sender sends one TCP SYN packet to the random chosen
port with the random chosen sequence number minus one. The
processor method on the receiver
responds the SYN packet
with a SYN ACK packet with the ack number set to the
uence number of the SYN packet + 1.

Then, the sender
splits the secret message into 2 byte parts.
With it, it tacks on a bogus payload or reads 1360 bytes of the
decoy file to set as payload. The 2 byte message in binary is put
Port Knocking

1) Exchange RSA encryption key

2) Exc
hange size of transmission

3) Exchange final random port for
the transmission

Establish connection by performing

TCP three
way handshake

Perform the File Transfer

1) Sender encrypts the hidden
message and stores it in the IP ID

2) Receiver
decrypts the hidden
message from IP ID


the IP packet’s ID fie
ld and TCP packet with sequence
number starting at the random starting offset with increments
of th
e length of the payload and the ack field at 1. The
assembled packet is sent and the process loops until the entire
message is sent. The receiver’s processor

method reassembles
the encrypted message 16 bits at a time and
by default responds
the every second packet with an ack packet with the ack field
set to equal the sequence number of the last incoming packet.
At the end of the transmission, the sender sends

a FIN packet

following the sequence number’s sequence. The receiver
responds with a FIN
ACK packet with the corresponding ack
number. The process is completed on the sender side. The
receiver uses its private key to decrypt the message and
displays the me
ssage to the user.


Design Validation

In application, the succeeds in transmitting a secret message
in lossless networks. TCP functions of retransmission and
congestion control are outside the scopes of this project.
Mimicking a normal TCP transmission, the

traffic looks
unsuspicious to a casual Wireshark observer.

As shown in figure x, all packets appear green in
Wireshark, demonstrating that proper TCP protocols have been

The Steven’s graph below shows the
plot of relative
sequence numbers
as function for time during the transmission.




S. Murdoch and S. Lewis, “Embedding Covert Channels into TCP/IP,”


DI Management Services.
RSA Algorithm
. Retrieved March 27, 2010,


Scapy. Retrieved April 8, 2010, from