PCoIP Traffic Analysis - insurehub.org Traffic Analysis! (Final Report for Deriving Intelligence from an Encrypted VPN Stream Project)! Joshua Blake, Zach Fuerst, Cody Welu! Dakota

PCoIP Traffic Analysis

(Final Report for Deriving Intelligence from an Encrypted VPN Stream Project)

Joshua Blake, Zach Fuerst, Cody Welu

Dakota State University

May 4, 2015

Authors Note

Contact: [email protected]

[email protected]

[email protected]

Deriving Intelligence from an Encrypted VPN Stream Dakota State University

Blake – Fuerst – Welu 2

Abstract PCoIP is a secure protocol that is used by VMware thin client applications. The company that created it, Teradici, states that it is secure because it only transfers images from client to server, without ever letting any information leave central systems. We analyzed the protocol PCoIP to find out if it is possible for an attacker or otherwise malicious person to find out what the thin client is doing just by looking at the packet data or information. A baseline for traffic was created using a virtualized VMware setup in a lab environment by capturing simulated user behavior between the thin clients and user workstations. The traffic was then analyzed using manual and automated techniques with classifiers that include uplink packet numbers and bytes, downlink packets numbers and bytes, and total packet numbers and bytes. Using Naïve Bayes and the KNIME framework, a method was created to successfully analyze the traffic.

Keywords Naïve Bayes, Traffic Analysis, PCoIP, KNIME, Supervised Learning, Statistical Analysis Side-‐Channel Attacks

Project Description Our research involves analyzing encrypted thin-‐client traffic with the goal of looking for information leakage, which can be derived from statistical analysis based attacks. The current scope of the project is limited to looking at one protocol, PCoIP. Analysis is comprised of classifying PCoIP traffic across the local area network in an attempt to derive intelligence from any number of arbitrary PCoIP streams. PCoIP is a fairly new protocol and as such no previous research has been conducted on PCoIP's resiliency to statistical analysis attacks, thus any discoveries (or lack thereof) within the area will be beneficial to the security community.

Proposal Many organizations are moving away from a distributed computing environment, and opting for the easier-‐to-‐manage thin client approach. Additional security is also assumed, as the data never actually has to leave the datacenter to be processed. That brings up the question, just how secure is the link between the server and the thin client? Enterprises rely on the security of the encrypted link between the server and thin client to protect their company data from unauthorized disclosure, but could someone with access to the encrypted link derive any intelligence from it? This research project will attempt to answer that question by performing detailed analysis on an encrypted thin client environment link.

There are a number of solutions utilized in the public and private sectors today, including Citrix Xen Desktop and Microsoft Remote Desktop Protocol. However, because of its widespread use in the industry today, we have chosen to perform our research on the PCoIP protocol used by VMware products. Many companies utilize VMware View products to deliver virtual desktop computing environments securely to internal thin clients as well as devices outside a company's network, including an employee's laptop or mobile device. Should we be able to expose any flaws by being able to derive a user's actions over the encrypted link, companies may need to re-‐think just how secure the PCoIP thin client environment actually is.



The first step in our research will be to install and configure the required VMware products to resemble a real enterprise Virtual Desktop Infrastructure (VDI) environment. We will then utilize our testing environment to collect various data for further analysis. By analyzing the collected data, we will attempt to fingerprint a user's actions on a virtual desktop. We will attempt to develop classification algorithms to correctly identify user actions. Should time allow, we have set a stretch goal to implement such algorithms into automation techniques, to derive data from the encrypted PCoIP streams without additional heavy analysis.

The team of researchers for this project consists of three graduate students who are pursuing masters degrees from Dakota State University in Madison, South Dakota. Cody Welu and Josh Blake are working towards M.S. Applied Computer Science degrees, while Zach Fuerst is working towards a M.S Information Assurance degree. All three hold Bachelors degrees in Computer and Network Security from DSU. The team brings broad knowledge and experience through a variety of classes and various internship experiences to the project.

Previous Work User privacy has historically been a considerable complication for the Internet. It is an issue that still pursues users into the present, and it carries even more weight now than it did in the past. Privacy is currently a much larger hurdle than it has ever been as the solution has become more intricate, in part because of user's growing digital footprints as well as the needs of businesses to track users for big data analytics. The want for privacy on behalf of users and the need for tracking by the enterprise leave both parties at odds. This division creates a hole for malicious users to exploit. The fundamental design flaws and the naïve assumptions made when designing the primitives that run the Internet are growing more apparent. Widespread industry adoption of encrypted has helped in maintaining privacy for users over the years. Unfortunately simple encryption measures are not enough to protect user's privacy against statistical side-‐channel attacks.

To get a full picture of the field, it is beneficial to look to the past. Some of the earliest research was conducted in the early 1990s and that laid the groundwork for later methodologies used in statistical analysis type attacks. In 1991, Ramón Cáceres et al. built a model to categorize unencrypted TCP conversations across the WAN [1]. They did this by recording traffic at three different collection sites. The variations they found in packet sizes and inter-‐arrival time between protocols is significant. Steven Bellovin carried out further work within the traffic analysis domain in 1997, where he took it in an offensive security direction. This paper primarily focuses on what he calls a probable plaintext attack [2]. This is very different from a statistical analysis attack but the traffic analysis methodology he demonstrated is still relevant. Bellovin described an early notion of footprinting encrypted traffic at its most basic level by looking at the context of each packet in a conversation. In the following year Heyning Cheng et al. looked at analyzing and footprinting SSL traffic from a given website. Their method was primarily based on packet size analysis. The core idea was that each page on a website will have a unique signature, or a conversation pattern, that can be saved and the resulting data can be used to identify encrypted user activity within an arbitrary website [3]. For example, an HTML object header is the smallest part of the transfer followed by the object's data, which will most likely fill the maximum packet size for that network. The delimiter is the first packet in the object data transfer that is not the maximum packet size. This would allow an observer to figure out the size in bytes of the HTML objects sent across the wire and from there deduce what the interaction was based on the context of the



communication. Cheng et al. demonstrated the simplicity of this attack but also pointed out a number of defenses that make plaintext probabilistic identification of encrypted traffic more difficult. Finally, in 2000, Jean-‐Francois Raymond briefly discussed a timing based attack. A timing attack uses the round trip time (RTT) to deduce other information about the encrypted communication [4]. Timing attacks are discussed in more detail later in this section.

The defensive and offensive aspects of encrypted traffic analysis go back and forth through the early 2000s to 2010. Cheng's research was recreated two years later in 2002 by Qixiang Sun et al. They looked at SSL's successor TLS [5]. Sun et al. modeled their work after Cheng's packet size methodology. They automated the identification process and even with a number of traffic analysis mitigations (padding, morphing, and mimicking), the number of positive identifications was still significant. In 2007, a breakthrough was made in traffic analysis. Charles Wright et al. looked at VoIP traffic and they made a remarkable discovery. They found that when using variable-‐bit rate encoding, they could identify the languages spoken within encrypted conversations with a high rate of accuracy [6]. What makes this possible is, that with the nature of modern speech encoders using variable bit-‐rate, different syllables are encoded at different bit-‐rates. Even though the communication is encrypted, the conversation still retains some of its structure (size). As a result, an observer can compare the packet size distribution of what is passed on the wire to what is saved locally for identification. Wright continued to build on the VoIP research for his dissertation, which also acted as an exhaustive survey of the field and as a building block for more recent research within the domain [7].

In more recent years, research on traffic analysis has branched in other directions to more specific applications. Quang Hien Vu et al. analyzed HTTP traffic over VPNs. What they found was surprising. They could still differentiate and identify user interactions in this context. What is notable about their research is the signature model they developed that factors in the term frequency of objects minus the inverse document frequency. Thus, unique objects that characterize a document are given more weight in identification than common objects [8]. This research resulted in the development of an automated tool called TunnelSnooper. Salini Selvaraj Kowsalya discovered in 2010 that different browsers result in unique signatures for the same web page [9]. Work on VoIP was continued a year later by Andrew White et al. They discovered that not only could an observer discern language from a VoIP conversation; they can also identify phrases and potentially the identity of the speakers. Their classifier is able to learn from the classification history and the current context of the sequence to identify the boundaries of phonemes. These phonemes are then analyzed against their model to extract words [10]. Kevin Dyer et al. explained in their research why traffic analysis countermeasures fail when efficiency is part of the implementation. Only the most extreme countermeasures such as fixed packet sizes sent at fixed intervals had a significantly negative impact on traffic analysis classification. This is achieved with substantial overhead and a massive degradation in overall performance. They also showed that simple coarse methods like total per-‐direction bandwidth was enough to get accurate readings [12]. In 2012, Zhen Ling et al. used a novel network delay attack to infer what web sites a user visited. Traffic RTT spread by itself could be used to accurately identify website interaction. RTT based attacks work much the same way as packet size sequence based ones [13].

In 2013, Tang and Lin bring attention to many different techniques for performing traffic analysis. [14] They have decided to group all techniques into the following groups: website identification, passive website identification, object based techniques, IP-‐packet based techniques, traffic-‐burst based techniques, network-‐delay based techniques, and others. From using these techniques Tang and Lin



conclude that though they were able to discover a lot of private user information, further investigation is needed. Some of this future research includes: using multiple machines to intercept the traffic, using other techniques to analyze a higher number of website that the user is visiting, analyzing webpage updates, consideration of "open world" scenarios, techniques of separating traffic of multiple users, accounting for browser caching, more robust and comprehensive analysis tools, and finding a way around, or an alternative to, countermeasures already in place such as traffic padding or traffic morphing. The research done by Tang and Lin is important to our cause because it shows past techniques that have had success in the past. Although this document focuses more on web traffic instead of the protocol PCoIP it will still show us techniques that can be used and a possible starting point for our analysis.

In 2014 Saman Fenghhi and Douglas J. Leith conducted research on traffic analysis using only timing information of the packets. [15] This attack focused only on the timestamp information of the packets that were sent by the user's computer instead of packet size or packet count information. This timing attack is different from previous attacks used to analyze traffic because it will not be affected by traffic padding, which is a standard defense against analysis attacks. Because this attack is impervious to popular defenses, it can be used in a variety of ways. The researchers were able to use this timing technique against wired and wireless networks, femtocell traffic, and Tor networks with results averaging from 90% in Ethernet and wireless channels and 68% against Tor traffic. This research is important to our work because it discusses ways to bypass some of the basic defenses against traffic analysis, which Tang and Lin mentioned was needed in their research the previous year. This timing attack could possibly give us a starting point to begin our traffic analysis since the protocol PCoIP is sending secured image data from the server to the user.

Another paper that was released in 2014 talks about traffic analysis using thin clients. This research was completed by Suznjevic et al focuses on detecting user tasks and applications using remote desktop client (RDC) based on employing statistical traffic analysis and machine learning. [16] To do this, they had to first train a Machine Learning algorithm to classify different types of behavior. In order to do this, they utilized the WEKA Java library, which contains a large collection of tools for data processing, machine learning, and data analysis. They categorized user activities into five categories, which are: idle, document editing, browsing, audio, and video. To analyze the traffic, the researchers utilized a technique focusing on packet size and rate. The main focus of this research was to find out what the main thing users do while using thin client apps. Using this research, they were able to find out that users spend up to 92% time idle with 6% time editing documents, and less than 1% browsing, listening to audio, or watching video. Their future work will focus on improving the accuracy of the analysis and analysis on real world thin client services. This research is important to our project because one of our end goals would be to eventually create a machine learning algorithm that analyses the traffic. The research conducted by Suznjevic et al discussed how they created a machine learning algorithm, and though it is not focused on the protocol PCoIP, it will help us greatly in our research goals.

More research that focuses on thin-‐client connections took place in 2014 by Dusi et al. [17] This research focused on detecting the applications being run in thin-‐clients so that they could better realize user quality of experience (QoE). Using statistical classification techniques to analyze the IP-‐level data the research team was able to detect what applications were running in thin-‐clients with up to a 90% accuracy. Future plans to expand the research include the analysis of other thin-‐client protocols and applications, as well as investigating the QoE algorithm used by comparing it to other algorithms that



are being used. This research is important to our project because the protocol we are investigating, PCoIP is used primarily for thin-‐client apps in VMware products. Using some of the ideas discussed in the paper will give us a good idea of how to begin analyzing the protocol traffic because it is similar to the way other thin-‐clients work.

There has been a lot of research that has been completed about traffic analysis in the past. For instance, in 1991, research was done to analyze unencrypted TCP traffic across the WAN. This research was able to increase the understanding that traffic going across networks needs to be secure, which was evident again in 1997 when research demonstrated a probably plaintext attack. Mitigation against the risk of traffic analysis attacks using traffic padding or encrypting the traffic were implemented. Most research does not account for those mitigations and simply analyzes the traffic in a lab environment or with the mitigations not implemented. Recent research has shown that the timing of packets alone can be used to analyze the traffic, thought the traffic analyzed was primarily TCP traffic or Tor network traffic. Our research does not aim to go around the traffic analysis mitigations, because the protocol we are analyzing is slightly unique when compared to regular network traffic. PCoIP used UDP instead of TCP because it aims to provide images of the screen as fast as possible. Another way that PCoIP is unique is that it sends images to the user, and not data. This will make our traffic analysis more challenging and will perhaps need to rely on other means to analyze the traffic instead of analyzing the packet size and frequency.

Methods and Lab Setup Hypothesis After conducting initial research, a number of things were learned about the PCoIP protocol. Because PCoIP essentially secures itself by encrypting and transmitting only the image on the screen, it would be difficult or impossible to inspect the data in the packets for information leakage. It was learned, however, that PCoIP is an extremely efficient protocol. Instead of transmitting the entire screen from the server to the client all the time, PCoIP will rather only transmit the portions of the screen that are changing. This lead us to believe that, because of these efficiencies, we may be able to differentiate between different types of traffic, based solely on the flow of packets from the server to the client. Research will need to be conducted to prove or disprove this hypothesis.

Lab Setup The first major step that needed to be completed before we could begin our research was to setup a testing environment. We selected the PCoIP protocol to study for this project, so we set up an appropriate VMware environment that employs the PCoIP protocol. VMware’s product solution for remote desktops or virtual desktop interface is VMware Horizon View. We found that, to setup our environment, we would need at least 4 servers and a few client machines, all of which could be virtualized. We selected an HP ProLiant DL380P Gen8 server with 80GB RAM, two Intel Xeon E5-‐2620 CPUs (6 cores @ 2.00GHz each), and four 600GB SAS drives configured in RAID 5. This server has more than enough resources required to setup our testing environment and carry out our research on.

There are a number of requirements for setting up a VMware Horizon View environment, first of which is a virtual server. We first installed ESXi on the server onto a flash drive. ESXi is an enterprise hypervisor developed by VMware. After installation, networking was configured with three separate networks: WAN, LAN, LAN2. Each of these networks have physical connections on the server, as well as virtual



connections to a pfSense virtual machine. This machine takes care of DHCP and routing for the network. All other virtual machines will connect to the LAN network directly. The LAN2 network was created to give us the ability to apply bandwidth limits to simulate a limited WAN environment.

In addition to an ESXi host, there are a number of other services that we installed on the network. We chose to use Windows Server 2008 R2 for our entire network, and Windows 8.1 clients. Two server virtual machines were configured as Active Directory and DNS servers in the INSURE.local domain. These provide name resolution services, as well as authentication services to the rest of the network.

A third server was setup, and joined to the domain. This server will host a number of services that are critical to the VMware Horizon View product. VCenter Server, Single Sign On, and the VMware Web client are all critical to Horizon View, and any multi-‐server VMware virtualization setup. The other service that was installed on this system is VMware View Composer, which allows the administrator to easily configure and deploy the virtual machines that the end users will be accessing. Finally, a fourth virtual server was setup and joined to the domain. This server is the VMware View Connection server, and handles the setup of connections between the Horizon View Client and the virtual machine clients.

After the servers have been setup and configured, client virtual machines need to be created. The VMware View Composer software makes this an easy process. After installing Windows 8.1 onto one virtual machine, a snapshot is taken, and it is loaded into View Composer. VMware then automatically can deploy and power on additional virtual machines as the end users request them. A total of four virtual machines and four user accounts were set up with the appropriate permissions to be used for remote access. It is these connections that we will be monitoring throughout our project. The environment as described above is pictured in the diagram below (Figure 1).

Figure 1 -‐ Network Diagram of Testing Environment



Experiments

Capturing Traffic The first step in our experimentation phase was to gather PCoIP traffic to analyze. This was achieved by using Wireshark to sniff PCoIP traffic on the wire. In order to simulate a more real world scenario, one researcher would use one VDI box to generate traffic, while another researcher would use a different VDI box to monitor traffic with Wireshark. Then only the relevant traffic, UDP traffic originating from the victim VDI box or from the server to the victim box, would be filtered for visibility. This traffic was then dumped to a pcapng file for further analysis. The traffic collected covered a broad range of use cases. These cases included full screen video, typing, idle, mouse movement and web traffic. Some of the traffic collected was synthetic or pure. Other traffic collected had a mix of varying classes intermixed. Our focus was on analyzing traffic that updated the screen rather than looking at USB traffic or audio, both of which are easily identifiable from image data. This is due to the fact that USB traffic is mostly uplink traffic while no other class generates nearly the same kind of signature. Audio traffic is a bit more challenging to differentiate but it still stands out much like video traffic with huge bursts of downlink traffic, only at much lower rates than video thus making it easy to identify and distinguish from video traffic. However if both are occurring at the same time such that someone is streaming high bit-‐rate audio while watching a video, it would be challenging to separate that traffic.

Manual Analysis Our first step in analysis was manual classification. We looked at the traffic we had collected to see what differences existed, if any, between specific activities. The first test we conducted was graphing traffic generated by email, no activity, file traversal, command line, and PowerShell. Our line graph (Figure 2) displayed number of bytes over time.

Figure 2 -‐ Manual Analysis of packet captures

Notice the variations in bytes per second between the applications. It was obvious that many of the samples had very different signatures just based on the bytes per second diagram. It was concluded that because we could visibly see differences by eye, it would be possible to automate the process.

Classification Our chosen method of classification was the simple Naive Bayes model. This was implemented using the Konstanz Information Miner (KNIME) framework. KNIME is an open source data analytics, reporting and



integration platform. Implementing our model using a standardized framework has many advantages such as speeding up development, simplifying experiment reproduction, and reducing the complexity of explanation by way of abstraction. KNIME offers a variety of classification models; we implemented the most generic form of Naïve Bayes. Naïve Bayes is a class of supervised learning networks that are used for learning and prediction problems. Naïve Bayes was chosen as the classification method due to being previously used in similar research, conceptual simplicity, and acceptable accuracy.

Classification Metrics The derived data from an arbitrary group of packets that was used for classifications included:

• Uplink Packet Number o The packets from client to server

• Uplink Bytes o The sum of the frame sizes from client to server

• Downlink Packet Number o The packets from the server to client

• Downlink Bytes o The sum of the frame sizes from server to client

• Total Packet Number o The sum of the uplink and downlink packets

• Total Bytes o The sum of the frame sizes of both uplink and downlink traffic

Note: Each metric is defined over time

Window Size We define window size, in our model, as the interval of time for each classification to occur; such that if our data is grouped by interval of time T and the set of packets is represented as P we can look at classification grouping like this:

Classification Group Statistics {uplink bytes, downlink bytes, …, n} = P{1,2,3,…,n} / T

The interval of classification is important and the ideal size depends entirely on the type of traffic that is being analyzed and the amount of information that needs to be derived. For example, traffic generated by websites would take a much larger window size for analysis than one second because many web pages take longer than one second to fully render to the screen. Our model supports any arbitrary fixed window size. The ideal window size for all situations would not be fixed but rather dynamic. This would lend itself to being efficient at classifying both complex traffic (web traffic) and simple traffic (video traffic). However, this model would be much more rigorous to implement than a fixed window size. With a larger window size, the classes of traffic can be more specific. With a smaller window size, the classes

Figure 3 -‐ Classification Metrics



have to be more generic. Careful consideration should be taken in assigning a fixed window size because window sizes that are too large or to small can drop accuracy significantly.

The Model In designing our model we tried to take a more real world approach by making classifications on the fly. Instead of pre-‐aggregating traffic metrics to feed to the model, we let the model do the work. CSV files with this type of data were read in:

Packet #, Src IP, Dst IP, Frame Size, Relative Timestamp, Class

From this point the packets are grouped by changes in traffic direction such that adjacent downlink packets are grouped until an uplink packet is observed and vice versa. After separating downlink and uplink traffic to gather uplink and downlink specific data, the traffic is put back together and grouped by window size. Then the traffic is partitioned for training and prediction. Partitioning is the process of splitting the data that is given to the learner and the predictor. Data that is passed to the learner is used for training the model, while data passed to the predictor is used for predicting. When partitioning, a variety of sampling methods can be used to decide what is passed to the predictor or the learner. This model is more realistic in that it can make classifications on a more acceptable timeline (real time).

The added metrics specific to generic classifications model include:

Figure 4 – Additional Classification Metrics

In addition to the metrics identified in Figure 3, we also included the following metrics for our tests:

• Millisecond – The number of milliseconds • Packet Burst – The number of packet bursts (changes in traffic direction) • Average Size Bytes – Standard deviation • Uplink Packets – The mode of uplink packets • Downlink Packets – The mode of downlink packets • Downlink Bytes – Standard deviation • Uplink Bytes – Standard deviation



Modifying the aggregation methods can increase accuracy and precision, as shown in Figure 4. The aggregation methods used for one test may not provide the same level of performance for another test with different data.

Results

Generic Classes For highly generic classes like idle, typing, mouse movement, and video traffic our model is very effective. For partitioning 20% for training and 80% for prediction, and a window size of one second the model is able to achieve from 76% to 81% accuracy with random sampling. Given the rudimentary implementation detailed above, it is reasonable to assume that accuracy can be improved with more data and better metrics to a small degree. It is however, not good at classifying more complex traffic patterns that require larger signatures and larger datasets to accurately identify; such as web traffic (specific websites) or more specific classifications such as the identity of the application being rendered to the screen. Web and application (Microsoft Word, cmd.exe, etc.) traffic is difficult to classify at this level because it is an ambiguous mixture of loading images, typing, mouse movement, and video.

Generic Classes:

• Idle • Mouse Movement • Typing • Video • Web

These are our results with a sample size of a little over 800 (window size 1 second):

Idle Mouse Typing Video Web

1. True Positives 277 50 21 28 287 2. False Positives 6 33 3 6 101 3. True Negatives 475 704 734 778 408 4. False Negatives 54 25 54 0 16 5. Recall 0.837 0.667 0.28 1 0.947 6. Precision 0.979 0.602 0.875 0.824 0.74 7. Sensitivity 0.837 0.667 0.28 1 0.947 8. Specificity 0.988 0.955 0.996 0.992 0.802 9. F-‐Measure 0.902 0.633 0.424 0.903 0.831 Accuracy 0.817

Cohen's kappa 0.724



Figure 5 -‐ Results Table

Accuracy is not the only performance metric that should be used. Other important performance metrics include recall rate, the level of precision for each class, sensitivity, and specificity. These performance metrics illustrate that our model shows promise, but still has a number of problems. The low recall rate of typing, for example, shows that our model is weak at classifying intermittent activities.

• True Positives -‐ A correct classification of an actual occurrence • False Positives -‐ Indicates a presence when there is none • True Negatives -‐ A correct classification for an absence of occurrence • False Negatives -‐ Indicates an absence when there is one • Recall -‐ The fraction for relevant samples that were retrieved • Precision -‐ The fraction of retrieved samples that were relevant • Sensitivity -‐ The true positive rate • Specificity -‐ The true negative rate • F-‐Measure -‐ The measure of a test’s accuracy • Accuracy -‐ The closeness to a measurement of the true value • Cohen’s kappa -‐ Measures concordance for qualitative items

Sub-‐Classes We conducted two other experiments using the model we developed for classifying more specific cases with mixed results that show promise for further research with more data and rigorous testing.

The first test we conducted was to classify websites using the same criteria as the generic classes but different parameters. The classes are as follows:

• amazon.com, apple.com, cnn.com, google.com, imgur.com, microsoft.com, netflix.com, reddit.com, wikipedia.com, youtube.com

When the window size is increased from one second to five seconds ,in our example, and with a very small amount of training data (two sixty second captures for each class) we can achieve 25% accuracy with 10 different classes (websites). This level of accuracy is not ideal, but it is much better than guessing. Thus we can conclude that it is in fact possible to identify website signatures over PCoIP. However, it should be noted that using our methodology on real world web traffic one can expect even lower performance or performance equivalent to guessing.

Another test was conducted looking at specific applications being rendered to the screen. Using five different applications that included cmd.exe, email (outlook), PowerShell, Windows Install Wizard, and a directory traversal using explorer.exe. Looking at these over thirty second periods we can observe 60% accuracy at best case with a window size of 125 milliseconds. This shows promise in application classification over PCoIP. Again, with our techniques, lower performance can be expected on real world traffic.

Classifying ASCII Characters One of the tasks we wanted to achieve was to see if it was possible to identify specific characters typed to the screen. Within our environment, we found that it is not possible to identify specific characters typed to the screen. This is due to one primary reason and that is there is a limit to how small a PCoIP packet can get. At common font sizes (11pt -‐ 14pt) typed characters appear identical in most



circumstances. Depending on the timing of the characters typed, a single character may be able to update two adjacent grid spaces thus causing a change in packet size, however in our research we found this to be rare. More differences can be observed at much larger font sizes (> 20pt), however it is uncommon for users to meet this criteria unless they are using some kind of magnification feature. We suggest further research be done in this area.

Remaining Problems The experiments detailed in this paper were using partitioned test traffic for learning and for predicting. Testing against real world data was outside the scope of this research as our only goal was to prove that the possibility for traffic analysis against PCoIP exists. Consistent concurrent updates to the screen can be expected in real world traffic. The majority of the traffic analyzed in our experiments was synthetic and thus a simplification and mostly did not exhibit concurrent rendering behavior. This must be taken into account when implementing this to analyze non-‐test data. Our model only works if one update is occurring on the screen at any given time. More time would have to be spent on the model to make it robust enough to handle concurrent changes to the screen.

Conclusion By way of example, we have proved through three experiments that deriving intelligence from PCoIP traffic is possible in a test environment with synthetic data. However, we have not proved that it is feasible or even possible to reproduce in a production environment. Every test that was conducted was a simplification and thus no prediction of the real world. The only conclusion that we can come to in regards to the real world is that traffic analysis on PCoIP is not impossible. Further research should be conducted on PCoIP to see how increases in granularity of classification can be achieved while maintaining accuracy. At the very least, this paper can serve as a bootstrap for further PCoIP traffic analysis research.

References [1]R. Cáceres, P. Danzig, S. Jamin and D. Mitzel, 'Characteristics of wide-‐area TCP/IP conversations', SIGCOMM Comput. Commun. Rev., vol. 21, no. 4, pp. 101-‐112, 1991.

[2]S. Bellovin, 'Probable plaintext cryptanalysis of the IP security protocols', Proceedings of SNDSS '97: Internet Society 1997 Symposium on Network and Distributed System Security, 1997.

[3]H. Cheng and R. Avnur, 'Traffic Analysis of SSL Encrypted Web Browsing', 1998.

[4]J. Raymond, 'Traffic Analysis: Protocols, Attacks, Design Issues, and Open Problems', 2000.

[5]Q. Sun, D. Simon, Y. Wang, W. Russell, V. Padmanabhan and L. Qiu, 'Statistical Identification of Encrypted Web Browsing Traffic', 2002.

[6]C. Wright, L. Ballard, F. Monrose and G. Masson, 'Language Identification of Encrypted VoIP Traffic: Alejandra y Roberto or Alice and Bob?', USENIX Security, vol. 3, no. 36, 2007.

[7]C. Wright, 'Statistical Analysis and Information Leakage Attacks of Encrypted Network Traffic', Ph. D, Johns Hopkins, 2008.



[8]Q. Hieu, A. Syed, K. Khu and K. Anagnostakis, 'TunnelSnooper: an Attack on Encrypted VPN Tunnels (Time to Pad and Cover?)', 2010.

[9]S. Kowsalya, 'Website Fingerprinting using Traffic Analysis Attacks', 2010.

[10]A. White, A. Matthews, K. Snow and F. Monrose, 'Phonotactic Reconstruction of Encrypted VoIP Conversations: Hookt on fon-‐iks', 2011 IEEE Symposium, 2011.

[11]C. Onete and D. Venturi, 'Security & Indistinguishability in the Presence of Traffic Analysis', IACR Cryptology ePrint Archive 2011, 2011.

[12]K. Dyer, S. Coull, T. Ristenpart and T. Shrimpton, 'Peek-‐a-‐Boo, I Still See You: Why Efficient Traffic Analysis Countermeasures Fail', 2012 IEEE Symposium on Security and Privacy, 2012.

[13]Z. Ling, J. Luo, Y. Zhang, M. Yang, X. Fu and W. Yu, 'A Novel Network Delay Based Side-‐Channel Attack: Modeling and Defense', 2012 Proceedings IEEE INFOCOM, 2012.

[14]'Traffic Analysis on Encrypted Web Application', JCIS, vol. 3, no. 2, pp. 12-‐20, 2013.

[15]S. Feghhi and D. Leith, 'A Successful Web Traffic Analysis Attack Using Only Timing Information', arXiv preprint arXiv: 1410.2087, 2014.

[16]M. Suznjevic, L. Skorin-‐Kapov and I. Humar, 'User Behavior Detection Based on Statistical Traffic Analysis for Thin Client Services', New Perspectives in Information Systems and Technologies, vol. 2, 2014.

[17]M. Dusi, S. Napolitano, S. Longo and S. Niccolini, 'A closer look at Thin-‐Client connections: Statistical Application Identification for QoE Detection', Communications Magazine, 2012.

Documents

PCoIP Traffic Analysis - insurehub.org Traffic Analysis! (Final Report for Deriving Intelligence from an Encrypted VPN Stream Project)! Joshua Blake, Zach Fuerst, Cody Welu! Dakota