Reportx - Bitbucket

childrenpenΔίκτυα και Επικοινωνίες

26 Οκτ 2013 (πριν από 3 χρόνια και 10 μήνες)

129 εμφανίσεις


1

Final Project
:
Socket Programming

ECSE 489


Telecommunications Network Lab


Winston Lin

260235451

Xiao Yu

260158645


Abstract

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.

I.

S
OCKET
P
ROGRAMMING

A.

Prob
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
transfer.
The primary goal with steganography is not to hide
t
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
intended

data being sent.
Additionally,
the
communication
protocol
must
also
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
canno
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
with.

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

is
suspected,

it
must

be difficult to decode.


B.

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
inf
ormation of the hidden message that is inserted into each
packet, the easier it will be to detect its existence. Furthermore,
the more the
message
is encoded

for security purposes
, the less
amount of the
desired
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
italicized
field
s

in Figure 1 below were
identified

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.
The
advantages and disadvantages of
using

this field are
summarized
in Table 1 below.

TABLE I.

P
ROS AND
C
ONS OF
IP

ID

Pros

Cons



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
ploits



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
system.

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.



2

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

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
agreed
-
upon
prior to the transmission. To further make use of this step,
use
ful information is
also exchanged on each knock
.

On the first knock
, a

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

Cryptography

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

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

and
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
-
knockin
g scheme for security
purposes.

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
transfer.
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
o
utlined

in Figure 2 below.



Figure 2.

Communication Protocol

C.

Design Outcome

The initial design was followed while programming
with
the new criteria that the process be programmed as to loo
k as
unsuspicious as possible in Wireshark. Since
Wireshark
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

[3]
framework for Python.
The framework offered convenient
packet manipulations without having to worry about
sockets,
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
ned
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
decoy.
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
seq
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
a

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


3

into
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.

D.

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
respected.



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



II.

R
EFERENCES


[1]

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

[2]

DI Management Services.
RSA Algorithm
. Retrieved March 27, 2010,
from
http://www.di
-
mgt.com.au/rsa_alg.html

[3]

Scapy. Retrieved April 8, 2010, from
http://www.secdev.org/projects/scapy/