Preventing the capture of sensitive information Khaled Hussain

School of Computer Science University of Central Florida

Orlando, Florida 32816 khaled@cs.ucf.edu

Naveen Addulla School of Computer Science University of Central Florida

Orlando, Florida 32816 anreddy@cs.ucf.edu

Sharon Rajan School of Computer Science University of Central Florida

Orlando, Florida 32816 srajan@cs.ucf.edu

Ghada Moussa Dept. of Civil & Envir. Eng. University of Central Florida

Orlando, Florida 32816 ghada@mail.ucf.edu

ABSTRACT Protecting sensitive information (credit card information, social security number …etc) and copyrighted materials (images, e-books, videos…etc) from being captured is of utmost importance as it can lead to serious repercussions if the collected data lands into unscrupulous hands. Despite tremendous advances in security, plenty of security problems still afflict systems. Also existing security approaches do not prevent processes running in the background from capturing sensitive information on the screen. This paper introduces three security levels that can be used to protect sensitive information and copyrighted materials. First level (low security) prevents capturing of sensitive data by users that do not have administration privileges. Second level (medium security) protects many attacks such as replacing the display driver. For the third level (high security), the paper proposes a no-capture hardware security feature and uses this feature for designing the third security level that prevents capturing of sensitive data by users that have administration privileges. Categories and Subject Descriptors E.3 [DATA ENCRYPTION] General Terms Security Keywords Security, no-capture hardware feature, anti-spyware, image security, copyright protection. 1. INTRODUCTION Research in security has concentrated on the development of algorithms and protocols [1, 2, 3, 4, 5] for encryption, authentication, integrity of data …etc. Despite tremendous advances in security; plenty of security problems still afflict systems [6, 7, 8]. Thus, the existing security approaches do not prevent processes running in the background from capturing sensitive information on the screen.

Operating systems (Windows, UNIX, Linux … etc) do not provide adequate means for the protection of this sensitive information by themselves. For example, many software packages such as RealVNC [9] and TightVNC [10] can view the screen of a remote computer. These software packages are portable and can be used as monitoring tools in public computers. They can capture sensitive information on the screen like account information, credit card information, and other personal information including name, birth date and social security number. These software packages might capture business activities done on public computers (e.g.; Library and Internet Café) and thus these activities are insecure. Operating systems also do not provide adequate means for preventing users from capturing copyrighted materials (images, e-book, video …etc) from the screen, this restricts the distribution of these materials over the internet. Despite the importance of having this kind of protection, there is little research in this area. In [11, 12, 13], they introduce secure window systems under the assumption that the user is trusted. Thus they have a different goal from our research. In our research, we do not trust the user. There are commercial applications (e.g., ImageSafe [14] and CopySafe [15]) that prevent capturing of copyrighted images. However, these applications are not secure, as we can write capture software that runs in the background to capture these images. This paper discusses how the intervention of the operating system and the hardware offer security of information (credit card information, images …etc) on the screen. The paper is organized as follows: Section 2 presents the existing methods that can be used to prevent users from capturing images along with the flaws of these methods. Section 3 discusses various features that are provided by different operating systems for dealing with graphics, windows and screen capture. Section 4 presents the first security level that extends the above operating system features to prevent image capture by unauthorized users that do not have administration privileges. Section 5 describes the second security level that can be used to prevent many methods that can be used to capture sensitive data. Section 6 proposes a no-capture hardware security feature and uses this feature for designing the third security level that prevents the capturing of sensitive data by users that have administration privileges. Section 7 presents our results and applications of these added security features. Section 8 concludes the paper. Permission to make digital or hard copies of all or part of this work for

personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.

2. CONVENTIONAL METHODS OF PREVENTING ACCESS TO IMAGES ON WEB 43rd ACM Southeast Conference, March 18-20, 2005, Kennesaw, GA,

USA. Copyright 2005 ACM 1-59593-059-0/05/0003…$5.00. This section describes the conventional methods [16-20] that can be used to prevent a user from capturing an image from the Web. It

2-154

also talks about inconveniences that the user faces with respect to these methods.

Disabling the right mouse click is a very easy technique that makes it difficult for the user to copy images, as he does not have the option of “Save picture as". This technique can be implemented by writing a simple JavaScript code to disable the right mouse click context menu. Of course, if the user knows JavaScript he can delete this part of the code and go about copying the image. Image tiling is a technique in which the image is broken into a number of small images and then transmitted to the browser that displays it as a single image. Therefore, if the user tries to copy this image he will only get a part of the image, thus he will have to copy all the parts of the image and then reassemble them later, which is time consuming. Decoying of images is a technique in which a dummy transparent image is kept on the top of the original image, so when the user tries to save it, a blank image is saved instead of the original one. These techniques are easy to implement and do not require additional software on the user’s computer. However, there are other ways to overrun this technique. For example, the user can use different capture software to copy the image. Another method is to pull the image from the browser cache. Each time the browser loads a webpage; its images are stored in a temporary directory so it is easy to get the images from the cache. Common plug-ins [16] can be used for protection of images but still they do not offer total protection. For example, if a website uses an applet to display an image, it can be programmed in such a way that the image is not stored in the temporary directory as explained above. The user can still use various capture software packages to copy the image. Custom plug-ins can make it more difficult to bypass the copy protection, but the user has to install the plug-in of which the user may be a bit skeptical because of the threat of spyware. In the following, we present various commercial applications that implement the above image capture techniques. We then discuss the flaws associated with these applications.

• ImageSafe [14] is an application that does not prevent the image capture but degrades the quality of the captured image by displaying moving text or images on the top of the original image.

• CopySafe [15] protects against any conventional image saving methods and does not store images in the browser cache. It disables the “Windows Start menu” along with all the browser controls. Custom plug-in needs to be installed. Disabling the “Start” menu provides a great inconvenience to the user and the user still can run any application from its icon on the desktop.

• Pickeeper [20] prevents images from being stored in the cache. It also disables “Save picture as” and “Print Screen” options. It provides a separate application that the users should run it to view images; this causes an addition inconvenience when the user wants to view protected images.

• ImageEscort [18] hides the image on a mouse click or a keystroke. This application uses a plug-in that has been already installed in the browser. The disadvantage of this application is

that it keeps the CPU busy during running and provides a bit inconvenience to the user as it hides the image on a mouse click or a keystroke.

The techniques discussed above do not provide protection against a capture process that runs in the background. The major reason for this flaw is that the operating system and the hardware do not provide adequate capabilities to prevent a background-capturing process from capturing sensitive information from the screen. In Sections 4, 5, and 6 we discuss how the operating system and the hardware can help to solve this problem. 3. GRAPHICS AND WINDOWING FEATURE IN WINDOWS, LINUX AND UNIX Windowing system is responsible for providing most of the features that people expect from a windowing system, such as window borders, ways of moving, resizing, and hiding windows, and placing icons on desktop. This section discusses these features in Windows, Linux, and UNIX. Windows graphical user interface The application programs communicate with the Windows operating system through a call-based interface. The Windows call based interface is an extensive set of system-defined functions that provide access to the operating system features. These functions perform the necessary operating system-related activities, such as memory management, processes management, graphical user interface …etc. CreateWindow, DestroyWindow, MoveWindow, GetDesktopWindow, GetWindowRect, GetClientRect, CloseWindow, ShowWindow, SetForegroundWindow, IsWindowVisible, and BitBlt are samples of the main GUI functions in Microsoft Windows that deal with windows and capture images (known as the Win32 USER and GDI functions, Figure 1 shows the location of these windowing and graphics user interfaces in Windows architecture); a complete list of these functions can be found in [22].

Figure 1, The location of windowing and graphics user

interfaces in Windows architecture.

MS Windows Application

Windowing and graphics user interfaces

Graphics Device Interface (GDI)

Video Card

Display Device Interface (DDI)

Linux and UNIX graphical user interface The X server forms a layer that is on top of the video hardware. Applications can only access the video hardware thought X server [23, 24]. XCreateWindow, XDestroyWindow, XMapWindow, XConfigureWindow, XMoveWindow, XResizeWindow, XRaiseWindow, XLowerWindow, and XSelectInput, XGetImage are samples of the main functions, exported by the X server, that deal

2-155

with windowing and graphics user interfaces (a complete list of these functions can be found in [23, 24]). 4. FIRST SECURITY LEVEL (LOW SECURITY) This section describes the modifications to the existing GUI functions in order to provide the added functionality of disabling image capture. The modifications provide the ability to prevent capture of a window as well as sub-areas in a window by users that do not have administration privileges. This protection is enough for many applications such as viewing copyrighted materials in a public library. To provide this protection, we need to add new GUI functions, adapt the existing GUI functions, and add new fields to the existing data structures. First, we will discuss these new fields: The Window Information data structure stores the information about various windows and their attributes. In addition to the already existing fields [24] in this data structure, we add new fields to facilitate the no-capture feature.

• no_capture: This is used to enable the no-capture feature of a window. When it is set to true, the whole window cannot be captured.

• num_sub_area_no_capture: This represents the number of sub-areas associated with a window. These sub-areas extend the no-capture capability to portions of the window that contains sensitive information.

• p_sub_area_no_capture: holds a pointer to the sub_area_no_capture structure that holds the information of all the sub-areas associated with the window.

Function Description: Now we present the modifications of the main GUI functions that use the above data structures to incorporate the no-capture feature. For the rest of the GUI functions [23], we need either to do similar changes or nothing. 1. Window XCreateWindowC (new): does the same function as

XCreateWindow in [23]. In addition, it specifies whether the window can be captured or not.

2. SubAreaId XCreateSubAreaC (new): creates sub-areas in a window so that only a portion of the window cannot be captured, rather than not allowing the whole window to be captured.

3. XResizeSubArea (new): resizes the sub-areas associated with the window.

4. XMoveSubArea (new): moves the specified sub-area to a specified coordinate.

5. XCancelNoCaptureC (new): allows the application to remove the restrictions of capturing the specific window.

6. XCancelSubAreaNoCaptureC(new): allows the application to remove the restrictions of capturing the specific sub-area.

7. XEnableNoCaptureC (new): sets the no_capture flag for the specific window.

8. XEnableSubAreaNoCaptureC (new): sets the no_capture flag for a specific sub-area.

9. XDestroyWindow: does the same function as XCreateWindow in [23]. In addition, it destroys all the specified window’s sub-areas.

10. XDestorySubAreaC (new): destroys a specified sub-area. 11. XGetSubAreaAttributes (new): returns the information about the

sub-areas of a specific window. 12. XGetImage captures images. The function returns two-

dimensional array of pixel values; areas that cannot be captured are painted with black color.

5. SECOND SECURITY LEVEL (MEDIUM SECURITY) The first security level assumes that the client application is trusted and the user does not have administration privileges. This protection is enough for many applications such as viewing copyrighted materials in a public library. However, if the user has these privileges, he could replace the X-server or replace the display driver, and could capture images. To secure our system against these types of attacks, we add a new XPutSecureImage API and modify the display driver:

XPutSecureImage (new API) The client is restricted to use only XPutSecureImage to send sensitive images. The main idea of using XPutSecureImage can be summarized in the following steps: a. Let SB (Image_Security_Level by Image_Security _Level) be the

random permutation of the integers from 1 to Image_Security_Level2. For example, if

Image_Security_Level=4, SB might be .

⎟⎟⎟⎟⎟

⎠

⎞

⎜⎜⎜⎜⎜

⎝

⎛

47151281114153132610916

b. Shuffle I according to SB, For example, if SB

= , then I

⎟⎟⎟⎟⎟

⎠

⎞

⎜⎜⎜⎜⎜

⎝

⎛

47151281114153132610916

sh1= .

⎟⎟⎟⎟⎟

⎠

⎞

⎜⎜⎜⎜⎜

⎝

⎛

4715

1281114

153132

610916

IIIIIIIIIIIIIIII

c. Apply steps (b) and (c) recursively on each sub-image until the

sub-images are small enough - see Figure 2. Let Is be the output image.

d. The client uses the public key of the display driver (the client has a pre-defined public key for the display driver) to encrypt SB (SBe).

e. The client uses XPutSecureImage to send Is, its coordinates C, and SBe to the X server.

f. The X server then sends Is, C, and SBe to the display driver which reconstructs and renders the image.

(a)

2-156

(b)

(c)

Figure 2, (a) the original image; (b) Sub-image locations after fist shuffling (Image_Security_Level = 8); (c) Sub-image locations after second shuffling. Display driver security updates Once the display driver receives the encrypted image, it decrypts and reconstructs the original image. Then, it renders the image into the frame buffer. The display driver maintains the coordinates of each no-capture area. It also manages the overlaps among different areas. Whenever the X server requests to read information from the display driver, it returns this information; areas that cannot be captured are painted with black color. 6. THIRD SECURITY LEVEL (HIGH SECURITY) The second security level can protect against many attacks such as replacing the X-server and replacing the display driver, this protection may be enough for some applications. However, the second security level can not protect against other attacks such as installing a driver that can access the frame buffer or installing a driver in a lower level than the display driver. To secure our system against these types of attacks, we propose a no-capture hardware feature. We adapt XPutSecureImage API and the display driver to use this hardware feature. XPutSecureImage The client is restricted to use only XPutSecureImage to send sensitive images. The use of XPutSecureImage can be summarized in the following steps: a. Let SB (be the random permutation of the integers from 1 to

Image_Security_Level2. b. Shuffle I according to SB. c. Apply step (b) recursively on each sub-image until the sub-images

are small enough. d. The client uses the public key of the video card (the client has a

pre-defined public key for the video card) to encrypt SB (SB Be). e. The client uses XPutSecureImage to send Is, its coordinates C, and

SBe to the X server. f. The X server then sends Is, C, and SBe to the display driver. g. The display driver sends Is, C, and SBe to the video card which

reconstructs and renders the image.

The no-capture hardware security feature Once the video card receives the encrypted image, it decrypts, reconstructs and renders the image. The video card maintains the coordinates of each no-capture area. Also it manages the overlaps among different areas. Whenever the display driver reads information from the video card, it returns this information; areas that cannot be captured are painted with black color. To simplify the hardware design, the video card can return black color for all read requests if there is a no-capture area on the screen. 7. APPLICATIONS AND EXPERIMENTAL RESULTS To test our approach, we wrote an Xlib, X-Server, and simulated display driver. To test the no-capture hardware security feature, we wrote virtual video card software. We did not implement all functions in [23, 24], but we implemented a subset of these functions that are necessary to test our approach. In the rest of this section, we present practical applications of the modifications that were discussed in Sections 4, 5, and 6. The main applications that we focus on are security of sensitive information and copyrighted materials. 7.1 Security and Spyware Public computers might have some monitoring software, such as RealVNC [9] and TightVNC [10] that can capture the screen and thereby poses a threat for sensitive information on the screen. There is also software that might be installed on computers, which some security professionals and organizations do not know that it exists. This software runs in the background and operates as a spy reporting on the user activities and habits. When considering the amount of valuable personal information including credit cards and banking details, personal e-mails and documents, shopping and browsing habits…etc, the risks of having software intruders become obvious. Known consequences of spyware include identity theft and capture of sensitive information. These PC surveillance tools can monitor all kinds of activity on a computer. Anti-virus software and firewalls do not fully protect the system against the majority of spyware and privacy threats. Spyware is commonly bundled with software downloads, attached to e-mails, or transmitted through networks so it appears to be legitimate software, but once installed it can be nearly impossible to detect and remove it without the help of a dedicated spyware removal tool. Spyware protection and prevention are essential to defend privacy from prying eyes and virtual trespassers. Security Experimental Results This subsection briefly describes how the developed application can be built to ensure security of sensitive information on the screen. The applications call XEnableNoCaptureC function to disable the capture of the window. In case the application needs to enable the no-capture feature on just a portion of the window (sub-area), the application can use XCreateSubAreaC and XEnableSubAreaNoCaptureC functions to enable the no-capture feature on a portion of a window. The application uses XSecurePutImage (see Section 5 and Section 6 for more details) to send sensitive data, for example to send a credit card number the application should construct the image of this number and then send this image.

2-157

Figure 3(a) shows a screen captured on a public computer that has a shopping website open with all the valuable credit card details. Public Computers might have monitoring tools that can capture the screen and thus can lead to serious repercussions if that collected data lands into unscrupulous hands. The application calls the XWindowEnableNoCapture API to enable the no-capture feature. Then the application constructs the images of the credit card number, the credit card verification code, and the date. After that, the application uses XSecurePutImage to send these images. Figure 3(b) shows that our approach obscures the credit card details from the captured screen.

(a) (b)

Figure 4, (a) A screen captured that shows a picture site the client views with the help of decryption software provided by the server. (b)Our approach obscures the two no-capture sub-

areas.

8. CONCLUSION (a) (b) This paper introduces three security levels that can be used to prevent capturing of sensitive information (credit card information, social security number …etc) and copyrighted materials (images, e-books, videos…etc). First level (low security) prevents the capturing of sensitive data by users that do not have administration privileges. This protection is enough for many applications such as viewing copyrighted materials in a public library. Second level (medium security) protects many attacks such as replacing the display driver. The paper proposes a no-capture hardware security feature and uses this feature for designing the third security level that prevents capturing of sensitive data by users that have administration privileges. The existing of this kind of protection will allow the distribution of copyrighted materials over the internet and will help protect sensitive information. This paper does not claim to completely eliminate all security risks but makes it very hard to capture sensitive data such as e-books and videos.

Figure 3, (a) A screen captured on a public computer that has a shopping website open with all the valuable credit card details. (b) Our approach obscures the credit card details from

the captured screen.

7.2 Copyright Protection Our approach can be effectively used to prevent capturing of copyrighted materials (images, PDF files, Word files …etc). This subsection concentrates on internet image security using the client-server architecture. This architecture allows the client to send a request to a server through a query. The server then queues and processes the request by interpreting and sending the information back to the client. The client then has the ability to present this information to the user via a graphical user interface or if it is preferred, through a host terminal. This process allows a multi-user environment to use a shared data source (Server). In the client-server architecture, a user can copy the image that is transferred from the server. This can be prevented by adding encryption logic on the server. The image can be encrypted and transferred to the client. The client on the other hand is provided with decryption software provided by the server that helps to view the image. The decryption software has to incorporate the no-capture feature so that when the decryption software is running, the client can never capture the image displayed on the screen. The frequently accessed images that are stored in the client’s cache are also useless to the client as he gets a garbled image that makes no sense without the decryption logic.

9. REFERENCES

[1] Schneier, B., "Applied Cryptography," John Wiley, second edition, 1996.

[2] Stinson, D. R., “Cryptography: Theory and Practice. CRC Press, 2nd edition, 2002.

[3] William, S., “Cryptography and Network Security,” Prentice Hall, Second Edition, 1999.

[4] Smith, R. E., “Authentication: from passwords to public keys,” Addison-Wesley, c2002.

[5] Sokratis, K., “Information Systems Security”, Chapman & Hall, 1996.

Copyright experimental results

[6] White, G., Pooch, U., “Problems with DCE security services,” ACM SIGCOMM Computer Communication Review, Vol. 25, Issue 5, Oct. 1995.

Applications can use XCreateSubAreaC and XEnableSubAreaNoCapture functions to enable the no-capture feature of sub-areas. Then they can use XSecurePutImage to paint these sub-areas. These sub-areas will be obscured when the screen is captured. Figure 4(a) shows a picture site that the client views. Figure 4(b) shows that our approach obscures the two no capture sub-areas.

[7] Yang, H., Luo, H., Ye, F., Lu, S., Zhang, L., ”Security in mobile ad hoc networks: challenges and solutions”, IEEE Wireless Communications, Vol. 11 , Issue 1 , P:38- 47, Feb. 2004.

2-158

[8] Bistarelli, S., Foley, S. N., O'Sullivan, B., "Computer security (SEC): Modeling and detecting the cascade vulnerability problem using soft constraints", Proceedings of the 2004 ACM symposium on Applied computing, Mar. 2004.

[9] RealVNC, UK Company founded by a team from the AT&T Laboratories in Cambridge, http://www.realvnc.com/, Accessed August 2004.

[10] TightVNC, http://www.tightvnc.com, Accessed August 2004.

[11] Shapiro, J. S., Vanderburgh, J., and Northup, E., “Design of the EROS Trusted Window System,” 13th USENIX Security Symposium, 2004.

[12] Doug Kilpatrick, Wayne Salamon, Chris Vance,” Securing the X Window System with SELinux,” www.nsa.gov/selinux/papers/x11-abs.cfm, 2003.

[13] Carson, M., et. al., “Secure Window Systems for UNIX", Proceedings of the USENIX Winter Conference, San Diego, CA, 1989

[14] ImageSafe, http://www.cellspark.com/imagesafe.html, Accessed August 2004.

[15] CopySafe, http://www.artistscope.net, Accessed August 2004.

[16] Husain, K., “JavaScript developer's resource: client-side programming using HTML, Netscape plug-ins and Java applets,” Prentice Hall, 1997.

[17] Livingston, D., “Advanced JavaScript: insights and innovative techniques,” Prentice-Hall, 2003.

[18] Cowell, J., “Essential XHTML fast: creating dynamic Web sites with XHTML and JavaScript,” London: Springer, 2003.

[19] Keith, G. and Alex, H., “Image Security - Balancing Barriers and Convenience”, http://www.techempower.com/core, Accessed October 2004.

[20] PickKeeper, http://www.pickeeper.com, Accessed October 2004.

[21] ImageEscort, http://www.ImageEscort.com, Accessed Jan. 2004.

[22] MSDN Library, http://msdn.microsoft.com/library, Accessed October 2004.

[23] X Window System, http://www.xfree86.org, Accessed October 2004.

[24] Design of the X Window System, http://www.xfree86.org/current/DESIGN.html, Accessed October 2004.

[25] Ernst, M., Klupsch, S., Hauck, O., and Huss, S. A.,”Rapid Prototyping for Hardware Accelerated Elliptic Curve Public-Key Cryptosystems,” 12th IEEE Workshop on Rapid System Prototyping, Monterey, CA, June 2001.

2-159