Steganography and Cryptography Over Network Protocols

Radu-Ioan Ciobanu, Mihai-Ovidiu Tirsa, Raluca Lupu, Sonia Stan

Automatic Control and Computers Faculty Politehnica University of Bucharest Emails: {radu.ciobanu, mihai.tirsa, raluca.lupu, sonia.stan}@cti.pub.ro

AbstractNetwork steganography describes all the methods used for transmitting data over a network without it being detected. Several methods for hiding data in a network have been proposed, but the main drawback of most of them is that they do not offer a secondary layer of protection. If steganography is detected, the data is in plain text. This article proposes an implementation called SCONeP (Steganography and Cryptography over Network Protocols) that offers the protection of hidden data by encrypting it. Furthermore, it describes two less utilized protocols for data hiding, ICMP and UDP, and presents the performance of two scenarios that use SCONeP, in comparison to other steganography tools. Finally, a proof-of-concept active warden used for preventing network steganography is described. Index Termssteganography, networking, cryptography

The rest of the paper is structured as follows. Section II presents the most important contributions in the area of data hiding and network steganography. Section III describes the architecture of the SCONeP system, together with the way in which the modules work and communicate with each other. Section IV presents the main aspects of the implementation, including the way data is encrypted and hidden. Section V proposes two scenarios for network steganography with SCONeP and presents experimental results. Finally, section VI concludes our work. II. R ELATED W ORK Digital steganography techniques use different le formats for hiding data. For example, HideInPic [3] is an application that hides les inside GIFs or BMPs, which is a little restrictive. For encoding and decoding, a password is required. WbStego [22] is a software which allows the hiding of les and copyright information inside BMPs, PDFs, HTML les and text documents. However, it doesnt support JPG or GIF. It is easy to operate, as a user can choose between a wizard and a owchart view. StegoMagic [18] hides les or messages inside text, WAV and BMP les. The restriction of the software is that the le to be hidden can be a maximum of 1/8 of the size of the le it is hidden in. The software is operated through a simple GUI and also requires passwords. The text hiding uses tabs and new lines to encode each character. Finally, Mp3stego [8] is an application that allows le hiding inside MP3s. It is Windows-only and no GUI is provided. It also supports passwords and is only in proof-of-concept stage. The term network steganography was rst introduced in 2003 by Krzysztof Szczypiorski [19] as referring to all the information hiding methods that may be used to exchange steganograms in telecommunication networks. However, data hiding in TCP/IP protocols has been described earlier (in 1997) by Craig Rowland [14]. The author states that a covert channel can be used to transfer information to users or system processes that normally would not be allowed access to the information. This is done by encoding ASCII values through the manipulation of TCP/IP header information. Three methods are thus proposed: manipulation of the IP identication eld, manipulation of the TCP initial sequence number eld and the TCP acknowledge eld bounce. The rst two methods are straightforward, as the IP identication eld and TCP initial sequence number eld are replaced with the ASCII characters

I. I NTRODUCTION Network steganography represents all the ways of sending hidden data by using network protocols. This is only possible through the existence of covert channels and is usually done by making use of elds in protocol headers that are unused or irrelevant. Although data transmitted through steganography is usually unencrypted, encryption provides an extra level of security in case the covert channel is detected. We propose the design and implementation of a network steganography application called SCONeP, that offers additional protection of the hidden data by encrypting it. The application is able to send, receive and detect encrypted messages hidden in various TCP/IP network or transport layer protocols. The protocols used are IP and TCP, and two protocols for which steganography hasnt been tested, UDP and ICMP. Prior to sending it, data is compressed for efciency, and then encrypted. For encryption, RSA, Triple DES and Vigenere are used. This article also proposes two scenarios for using SCONeP. The two scenarios present the steps that the application takes in conguring the keys for encryption and in sending the actual hidden data, by using various protocols. The performance and efciency of the two methods are then compared to other known steganography tools. Finally, an active warden used for steganography prevention and implemented as a Linux kernel module, is presented as a proof-of-concept component of SCONeP. It is also important to note that in this paper, the terms packet and message are both used to refer to the container of data traveling through a network.

that are to be sent. The third method uses a basic spoong of IP addresses to enable a sending machine to bounce a packet of information off of a remote site and have that site return the packet to the real destination address. Another example of network steganography in TCP/IP can be found in [1], where Ahsan and Kundur propose several scenarios of data hiding, either by packet header manipulation or by packet sorting. The scenarios that are relevant to our research use either the DF (Do Not Fragment) ag in the IP header together with the knowledge of the networks MTU (maximum transmission unit), or the IP identication eld and chaotic mixing. For the latter, the chaotic mixing is done by using toral automorphism systems. A steganographic system that proposes interprotocol steganography is PadSteg [4]. It uses the ARP and TCP protocols together with an improper Ethernet frame padding vulnerability (known as Etherleak) to facilitate hidden communication in LANs. PadSteg uses ARP request messages with improper Ethernet frame padding to make the other members of a hidden group aware of the presence of a new member. The actual data exchange is done through TCP over Ethernet frame padding. In [9], the authors analyze the TCP/IP header elds that can be used as a carrier for a steganographic covert channel. The conclusion is that most of the elds that have been used so far (like IP Type of Service and identication, or TCP initial sequence number and timestamp) can easily be detected by using a passive warden. A passive warden is an application that prevents steganography by detection, not by attempting to remove any hidden information. Taking into account the implementations of the TCP initial sequence number (ISN) generators in Linux and OpenBSD, the authors also propose two schemes that generate ISNs that are almost indistinguishable from those generated by a TCP stack, but in which data can be hidden. Because the hidden data shouldnt be differentiated from random numbers, it is encrypted. Another example of using encryption over steganography can be found in [15], where the author proposes an implementation called NUSHU, that uses the TCP ISN as well. It encrypts the data by initially generating a one-time-pad XOR key and then XOR-ing the ISN with the rst 32 bits of the key. To ensure a good level of randomness, the key is generated using DES. Because the ISN decryption must also be done at the sender, the only elds that can be used for generating the XOR key are IP source and destination address and TCP source and destination port. Aside from manipulating elds of TCP/IP headers, there are other ways of hiding data in a network, like using torrent les to produce a stego-torrent [5] or the Voice over IP protocol [20], [21]. In the case of torrent les, two approaches are used: Leter Case Change (where the case-insensitivy of torrent les is used for hiding data), and Field Reusage (where information is embedded by using the structure redundancy of torrent les). In Voice over IP steganography, a substitution approach that takes advantage of the similarity between the least signicant bits and embedded messages is used.

III. A RCHITECTURE This section describes the architecture of the proposed SCONeP system and the way its modules work and communicate. A graphical representation of the architecture can be observed in gure 1.

Figure 1.

SCONeP system architecture

SCONeP is used for communication between two entities, a sender and a receiver. The sender wants to hide a message in a network protocol and send it to the receiver, so that anyone that possibly sniffs the trafc wont know about its existence. Both the sender and the receiver have a simple user interface (UI) that helps them interact with the application. The sender may select a protocol the data will be hidden in, and a text or a le that contain the actual hidden data. Similarly, the receiver can choose a le to write the data to, or he may output it to the console. Because TCP/IP protocol headers are small, large quantities of data would require many packets and the communication could take time. Moreover, a longer conversation means a longer period for an observer to discover the hidden data. Therefore, SCONePs compression module has the role of compressing the data before actually sending it, by using Huffman trees. As stated in [9], hidden data must not be differentiated from the usual values of the elds it replaces. Thus, it must be encrypted and a different key must be used at each communication, if possible. SCONeP has a separate encryption module, that uses Vigenere ciphers and Triple DES. Finally, after the data has been compressed and encrypted, it must be sent. The module that hides and then sends the

information is the data hiding module. Its role is to modiy the required protocol headers by adding the hidden data, and then to send the modied packets. To make a hidden communication harder to detect, the module replicates the operation mode of the protocols used. The protocols that SCONeP uses to hide data are TCP, IP, UDP and ICMP. All three modules presented so far are implemented in user space, because large amounts of memory may be necessary for big input les. The receiver uses similar modules, that perform opposite operations to the ones from the sender. The rst action the receiver must perform is to receive the packets and extract the useful data from the headers. This is done by the data retrieval module. Then, the information must be decrypted by the decryption module and nally decompressed by the decompression module. We have to note that, in order have a hidden conversation, the receiver must be aware. This means that he must be waiting to receive packets with hidden data from a sender. Thus, the receiver acts as a server. However, a host can act both as a receiver and as a sender. This paper also proposes a method for steganography detection and prevention. Therefore, SCONeP also has an active warden, similar to the one described in [2]. An active wardens role is to prevent hidden data from circulating through a network by modifying suspicious trafc. Our active warden modies the protocol headers that are most likely to be used by steganographic applications. In order to intercept all the packets that exit the network, the warden must be placed in kernel space. It is thus implemented as a proof-of-concept kernel module that can be inserted whenever steganography prevention is needed. Since SCONeP implements two encryption methods and four data hiding methods, several scenarios that combine them can be created. In this paper, two such scenarios are presented. In short, the rst scenario uses ICMP and IP data hiding to perform steganography, by sending a shared key encrypted with a public key, and then sending the data encrypted with the shared key. The second scenario uses a similar approach regarding encryption, but sends the le by hiding information in the IP header, under a TCP connection. Details about these scenarios and test results are presented in section V. There are several reasons why SCONePs components have been implemented as separate modules. The rst reason is that modules are easier to implement and to test than a single application with many capabilities. Moreover, in some cases, not all the steps that are done in SCONeP would be necessary. For instance, compression might not have to be done for small les, or encryption might not be needed in a secure environment. Details about each modules implementation are presented in the next section. IV. I MPLEMENTATION

A. Compression Both the compression and decompression modules of the project are implemented using the basic Huffman Coding Algorithm [6]: to each character of the input le we assign a binary code according to its position in the Huffman tree. The input is then transformed into a smaller, binary le, which is afterwards transmitted to the next corresponding module. At the beginning of this new le we have the Huffman tree, represented as a list of pairs of the form (character, frequency of character). Although the Huffman algorithm has a very good compression rate for large input les, for very small input les the compressed output might be larger than the input, due to the fact that the whole Huffman tree must be saved in the output le. Therefore, the compression isnt always necessary. Also, the Huffman algorithm output isnt a multiple of eight bits, so a number (smaller than eight) of zero value bits are added at the end, in order to save the output in a binary le. Thus, we implemented the compression module such that the rst byte of the output le contains the information needed to solve these two problems. If the rst byte has a negative value, this means no compression took place. Else, the value indicates a number between zero and seven that represents how many bits from the last byte of the le must be ignored. In order to use both positive and negative values, the rst byte must be read as a signed character. B. Encryption The encryption module combines private key encryption using the RSA algorithm [7], with shared key encryption using Triple DES [17] or the Vigenere [16] algorithm. For the RSA and Triple DES encryption, we used OpenSSL 1.0 [10], an open-source Linux library. The rst step in the implementation of the encryption module is to choose which shared key encryption algorithm to use. For this, a random value is generated at run time. If the value is odd, the Vigenere algorithm will be used; if the value is even, the Triple DES algorithm is used. For the Triple DES case, we use the OpenSSL DES random key() function to generate three 8-byte DES keys. In order to make the encryption module more general, we also use a 24-byte key for the Vigenere algorithm. These keys are used both for encrypting and decrypting the compressed message.

Figure 2.

SCONeP message header

This section presents implementation details for the application, including information about each of the phases of SCONeP.

Regarding data encapsulation, the encrypted message contains a header and a body. The header is 32 bytes long and

contains the 24-byte shared key (SK), the identication byte (ID) of the encryption algorithm (0 for Vigenere, 1 for Triple DES), the compression byte (CB), which is the rst byte of the compression output used to solve the compression problems discussed in section A, and the rst 6 bytes of the compressed message (CM1). The header is encrypted by the sender using a 32-byte RSA public key and then decrypted by the receiver using the matching RSA private key. Although RSA keys shorter than 256 bytes are considered unsafe or soon to become unsafe, we couldnt use such large keys because the padding added to t the length would crush the overall performance of SCONePs implementation. An image of the header data encapsulation is shown in gure 2.

Figure 3.

SCONeP message body

The body of the message mainly contains the rest of the compressed message (CM2), which has variable length in bytes. The body is both encrypted and decrypted using the shared key from the header. Due to a bug in the implementation of the OpenSSL DES ede3 cbc encrypt() and DES ede3 cbc decrypt() functions, the rst or the last 8 bytes of the message are mixed. In order to solve this problem, 8 bytes of bogus data (BD) had to be added both at the beginning and at the end of the message before encryption, which are then ignored before decryption. An image of the body encapsulation is shown in gure 3. C. Hiding In order to hide data in network packets, we used protocols from the TCP/IP stack. The goal was to test several protocols that are less utilized in steganography, and to compare performances for implemented protocols. Therefore, SCONeP is able to send hidden data using headers from TCP, IP, UDP and ICMP. This subsection will describe in detail the way data hiding is accomplished for each of these protocols. TCP headers have been used before for hiding data, but SCONePs implementation has several important differences that will be described. For our implementation, the eld in which data is hidden is the initial sequence number (ISN). The reason we have chosen ISN is that it offers 32 bits for hiding data. After data is read from a le, the application splits it into 4-byte parts and modies the TCP header by replacing the ISN with each of these parts. Prior to modifying the TCP header, the data that has to be sent is encrypted as described in the previous subsection.

The initial sequence number is used in a three-way handshake. The client that wishes to connect to a server sends a packet with a random initial sequence number and the SYN bit set. The server then replies with a SYN-ACK packet that has the servers own ISN and an acknowledgement number that is equal to the clients ISN, increased by one. The nal step is an ACK packet sent by the client that conrms the servers ISN. In Rowlands application [14], only the rst step of the three-way handshake is actually implemented: sending a SYN packet. This approach has the downside of being very easy to detect, because a large number of connection requests from the same client without reply from the server would attract attention. One possibility of solving this problem would be to implement the other two steps of the three-way handshake. However, a big disadvantage of using the TCP initial sequence number eld for data hiding is that a new connection request has to be made for each 4 bytes of data. Consequently, if the le that has to be sent is large, a great number of connections have to be opened. Thus, the server would end up with many half-open connections that use up its resources. Our approach to solving this issue is to alter the nal step of the three-way handshake so that, instead of an ACK packet, the client would send a RST packet. This way, the connection is closed after each 4 bytes of hidden data are sent, thus not leaving half-open connections at the server. The steps used by SCONeP in sending hidden data through TCP are illustrated in gure 4. Another contribution of SCONeP is the encryption of the hidden data, as described in the previous subsection, in order to obtain the overlap and uniqueness constraints of the TCP specication. An additional advantage of implementing the entire threeway handshake connection is that data can be conrmed. When the sender receives the SYN-ACK reply, it compares the message it has sent (the ISN) with the acknowledgement number from the reply, minus one. If they are not equal, the sender will not send a RST, but will instead resend the initial SYN packet.

Figure 4.

Three-way handshake modied for TCP data hiding

IP packets, when employed for hiding data, can be used under any layer 4 protocol from the TCP/IP stack, which represents a big advantage. Consequently, one can appear to

be simply transferring a video le through a normal TCP connection, while at the same time sending precious information hidden in the IP header. However, only 16 bits can be sent in a single packet. The eld that SCONeP uses for IP network steganography is the identication number (IP ID). According to [13], the IP ID is a value assigned by the sender which is used to distinguish fragments of a packet from fragments of another packet. Like at the ISN, the IP ID eld is also required to be unpredictable and unique over a period of time. SCONeP uses an approach that is similar to Rowlands [14], by replacing the identication eld with two bytes from the secret le. In order for the kernel to not modify the identication eld when the packet is sent, the Do Not Fragment (DF) bit in the IP header has to be set. Because of this, all IP packets sent must be smaller than the networks MTU, so that the packets would not be fragmented. UDP is one protocol from the TCP/IP stack for which steganography hasnt been attempted, to our knowledge. The main reason for this is because UDP is an unreliable protocol. Datagrams may arrive out of order, may arrive twice or more, or may not even arrive at all. However, just like there are cases where UDP protocol is used (like DNS, VoIP or TFTP), there may also be cases where UDP can be utilized for sending a hidden message. Therefore, we have analyzed the UDP protocol and attempted to send data hidden in its header. UDPs header has 64 bits, with 4 elds of 2 bytes each. According to UDPs RFC [11], these elds are: source port number, destination port number, length and checksum. First of all, the length eld cant be used under any circumstances, because it represents the length in bytes of the entire UDP datagram. If it were to be modied, the packet wouldnt be correctly formed. Another eld that cant be used is the destination port number, or else the packet wouldnt reach the proper receiver. This leaves us with two possible elds: checksum and source port number. However, if the checksum isnt calculated, the RFC species that its value must be 0. If the checksums value is not 0, then it means that it is calculated, and the receiver checks it at the packets arrival. If it doesnt correspond with the contents of the packet, the packet is dropped. Consequently, the only eld that can be used is the source port eld, which is used by the receiver when it sends replies. As SCONeP does not send replies to conrm data hidden in UDP packets, the source port is not necessary, so it can be used for steganography. ICMP is another protocol for which network steganograhpy hasnt been attempted. According to its RFC [12], ICMP is used for host-to-host datagram service in a system of interconnected networks. Its main role is that of sending error messages between the computers in a network, or of relaying query messages. There are many types of ICMP messages (Echo Request/Reply, Destination Unreachable, Redirect Message, Time Exceeded, Timestamp, etc.), but the most common types (and the ones SCONeP uses) are Echo Request and Echo Reply. The Echo Request and Echo Reply messages are used by ping to test the reachability of a host on an IP network. Because pings are very common in a network,

messages hidden in an Echo Request or Echo Reply packet are harder to detect. The ICMP protocol has an 8-byte header, as seen in gure 5. The rst four bytes of the header are consistent for all types of ICMP packages, and represent the ICMP message type (8 for Echo Request, 0 for Echo Reply), the code (which is a subtype to a given type and is 0 for Echo messages) and a 16-bit ones complement of the ones complement sum of the ICMP message starting with the ICMP type. The remaining 4 bytes vary based on the ICMP type and code. For an Echo Request or Echo Reply message, these 4 bytes contain two elds, an identier and a sequence number. According to the RFC, they may be used by the echo sender to match the replies with the echo requests, much like a port number in TCP or UDP. When an Echo Reply message is sent, the identier and sequence elds must be the same. Both the identier and the sequence number can be 0.
0 16 32

Type Type (0/8) (0/8)

Code (0)

Checksum Checksum Sequence Sequence

Identifier Identifier
Figure 5.

Data hiding in ICMP header

Taking into account the freedom that the RFC gives us in regard to using the identier and sequence number elds, we have used these elds for network steganography in ICMP. Thus, there are 32 bits in which data can be hidden. Moreover, knowing that the identier and sequence number from the Echo Reply message must be the same as the ones from Echo Request, hidden data sent through ICMP can be conrmed at the sender. If the Echo Reply messages identier and sequence number do no correspond to the Echo Requests, the message will be resent. This way, a certain degree of reliability is achieved. D. Detection and Prevention The detection of steganography is called steganalysis. Steganalysis can be very difcult to implement, because there are numerous ways in which data may be hidden in network protocols, as seen in section II. There is always the possibility of a new method of data hiding to appear and to cause damage. However, steganalysis is necessary, especially in networks in which valuable data can be found. Applications that are used for steganography detection and prevention are usually called wardens. There are two types of wardens: passive wardens and active wardens. Passive wardens, as described in section II, are applications that prevent steganography by detecting it, not by removing any hidden data. Information about the packets that are assumed to be carrying hidden data is sent to the user, and it is his decision what to do with this information. On the other hand, an active warden can modify trafc regardless of suspicion. It can remove most of TCP/IP level steganography, but may

have difculty in removing higher-layer steganography [2]. However, in many situations it may be infeasible for a warden to be active: the kind of ltering necessary to remove TCP/IP steganography can increase network latency, and might require a ltering router that can store large amounts of state information. The warden may also wish to avoid the users being aware that the use of steganography is suspected [9]. In the case of a passive warden approach, SCONeP is difcult to detect, mainly because the use of encryption gives the various header elds values that are randomly distributed. Thus, in order to prevent steganography with SCONeP, an active warden approach should be taken. To achieve this, we have implemented a proof-of-concept kernel module that works similarly to the implementation described in [2]. The way the warden functions in presented in gure 6. When a packet arrives or exits the network, its potentially harmful elds (from the point of view of steganography) are replaced with values generated by the warden. When a reply to that packet passes back through the warden, its modied elds are replaced with their original version (or the updated original version, as necessary). This way, the conversation seems valid for both the sender and the receiver, but the hidden data they might send each other is modied. The elds that our warden modies are the ones described in the previous subsection. The reason the warden is implemented in the kernel is for efciency. However, in big networks, there could be too many connections for a kernel module to store information about, so one of our goals in the future is to improve the active warden.

so the input is sent 6 bytes at a time. The last ICMP message may contain less hidden bytes. The second scenario uses the same policy as the rst one to establish a connection and to send the length of the encrypted message. In this use case, the header and the body of the encrypted message are sent in different ways. In order to send the header, three-way handshakes are simulated using TCP and IP headers to hide data. This way, up to 6 bytes can be hidden per simulation, so 6 simulations are needed in order to send the header. To send the body of the message, a real TCP connection is initialized and valid TCP sequence numbers are used, as data is hidden only in the IP header. This way, only 2 bytes per message can be sent, so the number of total messages needed for this use case is almost three times greater than the number of messages needed in the rst scenario. Note that we did not include the UDP protocol in none of the scenarios above because it is not connection-oriented and there is no way to know if the hidden data arrives at the receiver. B. Results The data set used for performance testing and evaluation of SCONeP was obtained by selecting random passages from the book The Guide to The Galaxy. The generated text mainly consists of alphanumeric characters, which helps in obtaining a good compression rate. First, we measured the total time it takes to send hidden data using chunks starting form 512 bytes up to 16 Kbytes from the original data set, in both SCONeP use cases. We ignored the time it takes to compress/decompress and encrypt/decrypt because these modules are use case independent. The results obtained are shown in the rst chart from gure 8. As can be seen, the rst use case scenario works faster than the second one with almost 4 seconds when using a 16-Kbyte input. This happens due to the larger amount of trafc generated in the network when using the second use case. We will explain more in the following tests. Next, we wanted to measure the efciency of SCONeP. We dene the efciency as the ratio between the number of bytes that are hidden and the total number of bytes that must be sent or received in order to send the entire input. We will now refer to the efciency as E. In the use case scenarios, a total number of three ways to hide data into ICMP, TCP and IP headers are used: inside ICMP and IP headers, inside TCP and IP headers when we simulate a three way handshake, and inside IP in an established connection. We will further refer to these methods as M1, M2 and M3. For M1, up to 6 bytes can be hidden per message, but another message containing both ICMP and IP headers for conrmation is needed. For M2, up to 6 bytes can be hidden, but an extra two messages are also needed, one for conrmation and one to close the TCP connection. Finally, for M3, another extra message is needed, and only up to 2 bytes per message can be sent. The values obtained for E(M1), E(M2) and E(M3) are shown in the rst table in gure 7.

Figure 6.

SCONeP active warden

V. S CENARIOS AND R ESULTS This section describes two scenarios in which SCONeP may be used and the results obtained. Furthermore, a statistical analysis of SCONeP, in comparison to other steganography tools, is presented. A. Scenarios The rst scenario uses only ICMP messages to hide data, both in the ICMP and IP headers. In order to establish the connection, an echo request message with the ICMP ID eld containing the string @@@@ must be sent and an identical echo reply message must be received. Once the connection is established, an echo request message containing an integer that indicates the length of the encrypted input is sent. In this use case, SCONeP can send up to 6 bytes of data per message,

M1 0,107

M2 0,055

M3 0,027

ID Application Me thod Efficie ncy 1 Mp3stego WAV to MP3 0,0006 2 StegoMagic WAV 0,12 3 StegoMagic text 0,08 4 HideInPic 4 bit BMP 0,03 5 HideInPic 8/24 bit BMP 0,125 6 SCONeP ICMP + IP 0,106 7 SCONeP TCP + IP 0,027 8 wbStego PDF unlimited 9 wbStego text / html 1 byte / word
Figure 7. Efciency for SCONeP and other steganography tools

We have also tested the initial passive warden with the two scenarios, and the conclusion is that it gives too many false positives to be used in a network. Thus, the active warden should be used instead. VI. C ONCLUSIONS AND F URTHER W ORK In this paper we presented several ways of sending hidden data through networks using TCP/IP stack protocols and also ways of making the transmission more secure by using compression and encryption techniques, alongside an efcient way of detecting and preventing this kind of transmission. We developed two use case scenarios for our implementation and dened a way to compare them with other methods of hiding data. For the rst use case scenario we obtained promising results, very close to the results of hiding data in image les. At the same time, the second scenario is less conspicuous and can be integrated in other applications based on TCP connections. From this point on, research can continue by extending both the data hiding and the encryption modules, and also by implementing a less specic prevention module, in the shape of an active warden. ACKNOWLEDGMENT The authors would like to thank Razvan Deaconescu for all the help and support he has offered during the OS lab. R EFERENCES
[1] K. Ahsan and D. Kundur. Practical Data Hiding in TCP/IP. In ACM MM 02: Proceedings of Workshop on Multimedia and Security at ACM Multimedia, French Riviera, France, 2002. [2] G. Fisk, M. Fisk, C. Papadopoulos, and J. Neil. Eliminating Steganography in Internet Trafc with Active Wardens. In Revised Papers from the 5th International Workshop on Information Hiding, IH 02, pages 1835, London, UK, 2003. Springer-Verlag. [3] HideInPicture. http://sourceforge.net/projects/hide-in-picture/, October 2002. [4] B. Jankowski, W. Mazurczyk, and K. Szczypiorski. Information Hiding Using Improper Frame Padding. CoRR, abs/1005.1925, 2010. [5] Z. Li, X. Sun, B. Wang, and X. Wang. A Steganography Scheme in P2P Network. In Proceedings of the 2008 International Conference on Intelligent Information Hiding and Multimedia Signal Processing, IIHMSP 08, pages 2024, Washington, DC, USA, 2008. IEEE Computer Society. [6] D. R. McIntyre and M. A. Pechura. Data Compression Using Static Huffman Code-Decode Tables. Commun. ACM, 28:612616, June 1985. [7] R. A. Mollin. RSA and public-key cryptography. Chapman and Hall, rst edition, 2002. [8] Mp3stego. http://www.petitcolas.net/fabien/steganography/mp3stego/, June 2006. [9] S. J. Murdoch and S. Lewis. Embedding Covert Channels into TCP/IP. In Information Hiding: 7th International Workshop, volume 3727 of LNCS, pages 247261. Springer, 2005. [10] OpenSSL. http://www.openssl.org/. [11] J. Postel. User Datagram Protocol. IETF RFC 768, August 1980. http://www.ietf.org/rfc/rfc768.txt. [12] J. Postel. Internet Control Message Protocol. IETF RFC 792, September 1981. http://www.ietf.org/rfc/rfc792.txt. [13] J. Postel. Internet Protocol. IETF RFC 791, September 1981. http://www.ietf.org/rfc/rfc791.txt. [14] C. Rowland. Covert Channels in the TCP/IP Protocol Suite. First Monday, Peer Reviewed Journal on the Internet, 2(5), January 1997. [15] J. Rutkowska. Passive Covert Channels in the Linux Kernel. Presented at The 21st Chaos Communication Congress, Berlin, Germany, 2004. [16] D. Salomon. Coding for Data and Computer Communications. Springer, 2005.

In order to have a more accurate evaluation, we compared SCONeP with other steganographical methods such as hiding data in the compression algorithm of WAV les to MP3, hiding data in different image les (4, 8 or 24 bit BMPs), hiding data in text les, HTML les or PDF les. To do so, we used the software applications presented in the beginning of section II. The input of each method represents a chunk of 2 Kbytes from the original data set. The numeric results are shown in the second table from gure 7. As shown in the table, the most efcient way of hiding data in les other than PDF is to use a 4-bit BMP. However, a fact that has to be taken into account is that, if the last bit of an image that uses only 16 types of gray scale colors is modied, the output may seem suspicious. Furthermore, the solution that wbStego offers for hiding data inside PDF les shows a very good result, but a normal ratio must be kept. For example, a 10-MB PDF le that has only one text page will always draw someones attention. As expected, the second use case for SCONeP is less efcient than the rst one, due to the larger number of messages that must be sent or received in order to send the entire input, but it is less conspicuous. The rst use case shows good results, very close to the method of hiding data in a 24bit BMP le which we consider to be the best method we have tested. All tested methods are presented in the second chart from gure 8.
6,000

0,30000

5,000

0,25000

4,000

0,20000

Time

3,000 icmp tcp 2,000

Efficiency

0,15000

0,10000

1,000

0,05000

0,000 512b 1kb 2kb 4kb 8kb 16kb

0,00000 1 2 3 4 5 6 7

File dimension

Application

Figure 8.

Test results

[17] W. Stallings. Network Security Essentials. Prentice Hall, third edition, 2007. [18] StegoMagic. http://gosoftware.org/stegomagic software/, January 2005. [19] K. Szczypiorski. HICCUPS: Hidden Communication System for Corrupted Networks. In ACS 2003: Proceedings of The Tenth International Multi-Conference on Advanced Computer Systems, pages 3140, Miedzyzdroje, Poland, 2003. [20] H. Tian, K. Zhou, H. Jiang, Y. Huang, J. Liu, and D. Feng. An Adaptive Steganography Scheme for Voice over IP. In Proceedings of IEEE International Symposium on Circuits and Systems, pages 29222925, Taipei, Taiwan, 2009. IEEE Computer Society. [21] H. Tian, K. Zhou, H. Jiang, J. Liu, Y. Huang, and D. Feng. An MSequence Based Steganography Model for Voice over IP. In Proceedings of the 2009 IEEE International Conference on Communications, ICC09, pages 683687, Piscataway, NJ, USA, 2009. IEEE Press. [22] WbStego. http://wbstego.wbailer.com/, March 2004.