|Numéro de publication||US20050102266 A1|
|Type de publication||Demande|
|Numéro de demande||US 11/009,879|
|Date de publication||12 mai 2005|
|Date de dépôt||10 déc. 2004|
|Date de priorité||8 juin 2001|
|Autre référence de publication||US7007025, US8370646, US20050086666, US20050102264, US20050108525, US20050149485, US20050149486, US20050204165, US20100077231, US20100077360, US20120237029|
|Numéro de publication||009879, 11009879, US 2005/0102266 A1, US 2005/102266 A1, US 20050102266 A1, US 20050102266A1, US 2005102266 A1, US 2005102266A1, US-A1-20050102266, US-A1-2005102266, US2005/0102266A1, US2005/102266A1, US20050102266 A1, US20050102266A1, US2005102266 A1, US2005102266A1|
|Inventeurs||D. Nason, Carson Kaan, John Easton, Jason Smith, John Painter, William Heaton|
|Cessionnaire d'origine||Xsides Corporation|
|Exporter la citation||BiBTeX, EndNote, RefMan|
|Citations de brevets (13), Référencé par (21), Classifications (8), Événements juridiques (1)|
|Liens externes: USPTO, Cession USPTO, Espacenet|
All of the above U.S. patents, U.S. patent application publications, U.S. patent applications, foreign patents, foreign patent applications and non-patent publications referred to in this specification and/or listed in the Application Data Sheet, including but not limited to, U.S. Provisional Patent Application No. 60/297,273 entitled “Method and System for Maintaining Secure Data Input and Output,” filed Jun. 8, 2001, U.S. patent application Ser. No. 09/726,202 entitled “Method and System for Controlling a Complementary User Interface on a Display Surface,” filed Nov. 28, 2000, and U.S. Pat. Nos. 6,018,332, entitled “Overscan User Interface,” issued on Jan. 25, 2000, and 6,330,010, entitled “Secondary User Interface,” issued on Dec. 11, 2001, are incorporated herein by reference, in their entirety.
1. Field of the Invention
The present invention relates to methods and systems for maintaining the security of data in a computer-based environment and in particular, to methods and systems for maintaining the security of data as it is input from an input device such as a mouse or keyboard and as it is output through, for example, audio or video means.
2. Background Information
The concept of security continues to become increasingly more important in a world where personal computer systems are generally connected via wireless or wired networks and/or internetworks, such as the Internet, to other computing systems. Many companies and institutions have addressed security issues as they relate to, for example, the transfer of data from a personal (client) computer system to server computer systems over network communications. For example, firewalls are typically present on local area networks (LANs) to form boundaries between the rest of the internetworking world and the computer systems on the LAN. In addition, widely used cryptography techniques are often applied to such data transfers to ensure the security of the data communication paths.
However, there still remains a problem on the client computer systems themselves regarding valuable data that is often stored in valid form on the client computer system even though it may be transmitted in encrypted form over a communications channel to a server machine. For example, a user desiring to buy an object over the Internet, may connect and log into a website and provide his/her credit card information in order to purchase the object. Although the website (and client browser on the client machine) may support the transfer of the credit card information using a secure communications layer (such as SSL—secure socket layer protocol), the credit card information, in order to be displayed on the display device of the client computer system actually resides in storage as valid data for some period of time. Unauthorized “hackers” can then access such stored data (providing they are not kept out by a firewall or have been installed as rogue applications on the client computer system) using sophisticated mechanisms, even if the data is stored briefly. Thus, there is an ever-increasing need for providing techniques for securing data on a client machine.
Embodiments of the present invention provide computer-based methods and systems for enhancing the security of data during input and output on a client computer system in order to prohibit and/or frustrate attempts by illegitimate processes, applications, or machines to obtain data in an unauthorized fashion. For the purposes of this description, “data” includes digital bits or analog signals in a computer system transferred or stored for any purpose, including graphics, text, audio, video, input signals, output signals, etc. Example embodiments provide a plurality of obfuscation techniques and security enhanced, system level drivers that use these obfuscation techniques to prohibit unauthorized receivers/viewers of the data from receiving/viewing valid data. When these obfuscation techniques are used with the security enhanced drivers, the drivers can ensure that invalid data is always received/viewed by unauthorized recipients/viewers, thus preventing unauthorized hackers with access to valid data. Several obfuscation techniques by themselves offer varying levels of security.
For the purposes of this description, the term “obfuscation” refers to any mechanism or technique for transforming or hiding valid data so that the valid data becomes difficult to view, intercept, process, or modify without proper authorization and thus, appears as invalid data when accessed in an unauthorized manner. Obfuscation techniques may be implemented as software, hardware, or firmware, depending upon the execution environment of interest.
In some embodiments, the obfuscated data comprises, for example, an opaque color such as all black or all white, a pattern, a random bitmap, noise, masked data, an image, a company logo, or an advertisement. Other types of obfuscation, depending upon the type of data, are also possible.
For secure display of data on a display device and other types of display storage, the obfuscation techniques include “copy-out”, “replace and restore,” and “in-place replacement.” These techniques specify where (and how) obfuscated data is de-obfuscated to generate valid data for display and where (and how) data is re-obfuscated. Some techniques utilize an overlay buffer or a mask buffer in conjunction with a frame buffer to accomplish the obfuscation process. Others take advantage of any standard raster operation or overlay operation logic already present on a video card. In other embodiments, the obfuscation techniques are applied to the scheduling of content in other types of storage,.
In some embodiments, the security enhanced drivers (SEDs) implement varying degrees and levels of security, from making the data present with garbled information or noise, to encrypted data. The SEDs can be used with the different obfuscation techniques to determine what is used to obfuscate data, how, and where the data comes from. The SEDs are responsible for scheduling the obfuscation and de-obfuscation (and re-obfuscation) of the data.
In one embodiment, a security enhanced display driver (SEDD) is provided to schedule content of portions of a frame buffer stored in a video display memory. In one such embodiment, a request to display data to a secure region on a video display made to the SEDD. In response, the SEDD allocates a corresponding secure portion of the frame buffer and schedules the data content of this secure portion such that valid data is only present in the secure portion at the time it is needed for projection to the display device and when other tasks are locked out of accessing (reading or writing) to the secure portion. The SEDD determines, depending upon, the obfuscation techniques used, when data stored in the secure portion needs to be de-obfuscated and when it needs to be re-obfuscated.
In other embodiments, security enhanced drivers are provided for input devices, such as a mouse, keyboard, or other pointing device. These SEDs operate by intercepting the input data as it comes directly from the input device, transforming the data to an obfuscated form when secure input data has been requested, and forwarding the transformed data to the requesting code. When input data is received for a task that has not been authorized to receive secure data, then the input data is forwarded to standard operating system input drivers through a standard input stack.
In some of these embodiments, the SEDs are installed first-in-line in the driver processing sequence to ensure that the SED will intercept the data prior to any other code. In some embodiments, monitoring and/or watchdog services are spawned to ensure the security of these first-in-line hooks.
In yet other embodiments, different techniques are provided to denote various levels of security offered in the system. Some of these techniques present information regarding the source of the security as well. Techniques are present for manipulating standard user interface elements like scroll bars, titles, etc. as well as techniques that modify a cursor representation automatically as input focus travels from one area into a different security area.
Embodiments of the present invention provide computer-based methods and systems for enhancing the security of data during input and output on a client computer system in order to prohibit and/or frustrate attempts by illegitimate processes, applications, or machines to obtain data in an unauthorized fashion. For the purposes of this description, “data” includes digital bits or analog signals in a computer system transferred or stored for any purpose, including graphics, text, audio, video, input signals, output signals, etc. Example embodiments provide a plurality of obfuscation techniques and security enhanced (typically, system level) drivers that use these obfuscation techniques to prohibit unauthorized receivers/viewers of the data from receiving/viewing valid data. When these obfuscation techniques are used with the security enhanced drivers, the drivers can ensure that invalid data is always received/viewed by unauthorized recipients/viewers, thus preventing unauthorized hackers with access to valid data. Several obfuscation techniques by themselves offer varying levels of security.
For the purposes of this description, the term “obfuscation” refers to any mechanism or technique for transforming or hiding valid data, so that the valid data becomes difficult to view, intercept, process, or modify without proper authorization, and thus appears as invalid data when accessed in an unauthorized manner. (The word “obfuscate” means to render obscure.) Obfuscation techniques may be implemented as software, hardware, or firmware, depending upon the execution environment of interest. Although standard encryption techniques are one type of obfuscation, a variety of others can be employed including transformations of data between valid forms and invalid forms, temporary and dynamic movement of noise data throughout otherwise valid data, etc. The methods and systems of the present invention describe many techniques for thus preventing unauthorized hacking and retrieval of data. Hacking, for the purposes used herein, describes any type of illegal and/or unauthorized use or view of data, using any technique for intercepting data or for monitoring data or access patterns.
The security enhanced drivers (SEDs) implement varying degrees and levels of security, from simply storing or presenting the data with garbled information or noise, encrypted data, to data that is perceived or received as invalid by unauthorized code. In each case, a central focus of each security enhanced driver is to store and present valid data as obfuscated (and thus invalid) data to unauthorized “clients” (code, users, hardware, etc.). In one embodiment of the present invention, the security enhanced drivers include a security enhanced (video) display driver (SEDD); a security enhanced mouse driver (SEMD), which techniques are useful generally to any pointing type input device (or any x,y coordinate input device); a security enhanced keyboard driver (SEKD); and a security enhanced audio driver (SEAD). Each of these drivers and the concomitant obfuscation techniques that can be applied are discussed in the subsections that follow. One skilled in the art will recognize that other drivers for other types of input and output devices may be similarly designed and/or implemented using the techniques, methods, and systems described herein.
In order to implement data obfuscation in a manner that ensures valid data only to authorized clients, each SED typically needs to have some type of mechanism for locking out a part of the system (a resource such as a portion of a frame buffer on a video card). Because varying operating systems (kernels, or other process schedulers) provide different mechanisms for ensuring that a driver will have “priority” in the scheduling of operating system tasks (processes, threads, code of any type, etc.), it is often necessary to implement a mechanism for ensuring that a SED is a “first level driver” in the system. That is, a mechanism needs to be present to ensure that the driver that is “hooking” the input or output can obtain the data first, before other drivers or code, such as operating system drivers (OS device drivers 105 in
To complement the obfuscation techniques and security enhanced drivers, the methods and systems of the present invention also provide different techniques for denoting various levels of security in the system. Example screen displays of these techniques are provided and described relative to
Video content is generally vulnerable to hacking on a variety of levels and in different scenarios.
While the data is stored in an area of the VRAM 203 that is accessible to system level code (such as software and hardware video drivers, and other code that known how to communicate directly with the video card, e.g., Direct-X and DirectDraw), which is typically when the data is appearing on the display device 220, the data is vulnerable to hacking by malicious programs.
Once the data is stored in VRAM 302, the data is still vulnerable to illicit copying or viewing by an unauthorized client, for example, a rogue application 322 that uses a library, such as Direct-X, to communicate directly with the video card. The data is ripe for hacking as long as the video card needs to store the valid data in VRAM to allow the GPU to project the data onto display device 303. A Security Enhanced Display Driver is provided by the methods and systems of the present invention to prevent this type of hacking at lower levels in the system; that is, the enhanced driver supports techniques that secure designated data that is temporarily stored in conjunction with the video card and display mechanisms.
In one embodiment, the SEDD supports the ability for an application (or other code) to define a region on the display device as a “secure region.” Depending upon the level of security implemented in the particular system, the SEDD is able to guarantee that level of security for the secure region. For example, if the highest level of security is offered, the SEDD ensures that no unauthorized process can view or intercept the valid data, from the frame buffer, while it is being displayed in the secure area. In that scenario, a user can see the data on the display screen, but the secure region appears obfuscated to all code (other than the scheduler and driver processes).
Once one or more secure regions are defined, the content of the frame buffer (FB) is appropriately scheduled by the SEDD. In essence, the SEDD ensures that the contents of the secure portion of the FB that corresponds to the secure region on the display contains valid data when the GPU needs to read it (or the GPU obtains the valid data through other means), and at (effectively and practically speaking) all other times, the contents of the secure portion contains obfuscated data. The various obfuscation and de-obfuscation approaches used in conjunction with the SEDD are described with reference to
The first obfuscation/de-obfuscation approach is termed “copy out,” because, in summary, valid data is provided by the SEDD to be projected on the display device at “copy out” time—when the GPU copies the secure portion of the frame buffer to the corresponding secure region on the display.
There are two cases to consider. In the first case, Case 1, the frame buffer 601 contains invalid data in the secure portion 605 and valid data is stored in another buffer 602. Other data (shown as valid data) is stored in the areas of the frame buffer that are not designated as secure portions. The SEDD uses the valid data in buffer 602 to overwrite the contents of secure portion 605 when the FB data is copied out to the display device 603. The buffer 602 could be the overlay buffer, in systems that support direct raster operation combinations of the contents of the overlay buffer and the frame buffer. Further, the overlay buffer may contain an encrypted version of the valid data (with noise, for example, stored in the secure portion 605). In the latter case, a decryption key is stored in some auxiliary location. One skilled in the art will recognize that, although referred to as the overlay buffer (for video card and system supported mechanisms), other buffers such as a valid data buffer (VDB) or a secured data buffer (SDB), stored elsewhere in VRAM may be used in combination with raster operations. In the second case, Case 2, the invalid data stored in the secure portion 606 is an encrypted or masked version of the valid data and an encryption key or a mask used to unmask the masked version of the valid data is stored in another buffer 604. The key or mask stored in the buffer 604 is used to create valid data on copy out by either decrypting the data stored in the secure portion 606, or by combining the data stored in the secure portion 606 using a Raster Operation (ROP) and the mask stored in the buffer 604. The primary distinction between the first and second cases is whether the data stored in the other buffer (602 or 604) is valid data or other (key or mask) data. One skilled in the art will recognize that some use the work “mask” interchangeably with the term “key,” and for the purposes described herein, the terms are interchangeable.
The second obfuscation/de-obfuscation approach is termed “replace and restore,” because, in summary, the SEDD provides valid data by replacing the invalid data stored in the secure portion of the frame buffer with valid data just prior to being projected (or during projection) on the display device—when the GPU copies the secure portion of the FB to the corresponding secure region on the display—and provides obfuscated data by restoring the invalid data after (or during the time) the secure portion of the FB is projected by the GPU. (The exact timing of the de-obfuscation and re-obfuscation is dependent upon whether data is being handled pixel-by-pixel, scan-line at a time, or in block operations.)
In particular, in Case 3, valid data is stored in valid data buffer (VDB) 803 and obfuscated data (or data, for example, a mask, used to obfuscate the contents of the secure portion of the FB) is stored in a mask buffer (MB) 804. Recall that these buffers may be stored wherever it is convenient in the system and meets the security needs intended. The SEDD, at an appropriate time prior to the time when the contents of the secure portion needs to be valid for projection, copies in valid data from VDB 803. After the valid data has been scanned and copied out for projection to the display (or sometime in the interim), the SEDD copies-in the invalid data from the mask buffer 804 in order to re-obfuscate the secure portion of the FB 802. Note that, although shown as coming from the mask buffer 804, one skilled in the art will recognize that the invalid data may be created any number of ways, including system operations, machine instructions, or other means that turn a set of bits on (all black) or clear the bits (all white). As shown in the figure, when the obfuscated data is to be formed by masking versions of the valid data, then a mask can be stored in MB 804 and applied to the already copied-in valid data stored in the secure portion 802 using ROPs to recreate the newly obfuscated data. Alternatively, when the obfuscated data is invalid data such as a logo, advertisement, or random bit patterns, then invalid data from the mask buffer 802 can be copied in to the frame buffer as is.
In Case 4, valid data is only stored in a more secure form (such as stored as encrypted or masked data) in secure data buffer (SDB) 805. This same encrypted or masked data (since it is “obfuscated” data) is used as the invalid data to be copied in to the secure portion of the FB when obfuscated data is to replace the valid data in the frame buffer. A mask or key is stored in mask buffer (MB) 804 to be used by the SEDD to decrypt or de-mask the secure data stored in SDB 805. Thus, the SEDD, at an appropriate time prior to the time when the contents of the secure portion 802 needs to be valid for projection, creates valid data to copy in from the SDB 805 by applying (decrypting or de-masking) a key or mask from the MB 804 to the secure data stored in the SDB 805, and copies out the result (valid data) to the secure portion of the FB 802. Similarly, after the valid data stored in the secure portion 802 has been scanned and copied out for projection (or thereabouts), the SEDD copies-in the invalid data (the encrypted or masked form of the valid data) from SDB 805 in order to re-obfuscate the secure portion of the FB 802.
The third obfuscation/de-obfuscation approach is termed “in-place replacement,” because, in summary the SEDD provides valid data in the secure portion of the frame buffer by manipulating the invalid data in-place just prior to being projected on the display device—when the GPU copies the secure portion of the FB to the corresponding secure region on the display—and then provides invalid data by manipulating (toggling) the valid data in-place to once again generate invalid data.
As described relative to
Note that the (0,0) point is simply an origin relative to the screen (the upper leftmost corner). The actual portion of the display screen being used by the operating system and other code, may in fact be less than the total amount on the screen. The relative origin point in the frame buffer used as a data source for what is scanned to the display is also described as (0,0), however, it will be understood that this point is not necessarily the first address location available in the frame buffer.)
The gun projects scan lines (travels) at a particular rate. The SEDD needs to determine when the gun will reach point A. Point A represents the time (relative to the VB signal end at origin 0,0) the gun will reach the beginning of a designated secure region on the display, which corresponds to a designated secure portion of the frame buffer (memory). At point A, the data in the secure portion of the FB needs to be valid data. Point B represents the relative time when the gun will reach the end of scanning the designated secure region on the display, which corresponds to the end of the secure portion of the frame buffer. By point B, the data in the secure portion of the FB needs to be obfuscated data, so that other code (code other than any SEDD code used in the scheduling of frame buffer content) cannot view or intercept valid data. In reality, due to system latencies, including the VB interval to start scanning from the display origin, the time to load code and invoke processes, threads etc., and due to any time needed for the de-obfuscation (including in some cases decryption) to occur, the SEDD needs to start the process of de-obfuscated the data stored in the designated secure portion of the frame buffer at some time prior to when it is needed at point A. Point C represents this time delta. One skilled in the art will recognize that the values of points A, B, and C are highly system dependent. Points A and B can be determined by polling for the VB signal or, in an event-driven system that supports VB events, by receiving a VB event and calculating (knowing the travel rate of the gun) the time it will take to reach point A and point B. Point C, however, the time delta, is typically determined empirically, based upon system latencies and the particular obfuscation and de-obfuscation techniques being used. In general, point C is:
point A (in time)−system latency time−de-obfuscation process time (1)
One skilled in the art will recognize that many different techniques can be used from a scheduling perspective for re-obfuscating the data by point B. For example, the re-obfuscation process make take place a scan line at a time, pixel by pixel, or as a block of memory. Thus, the process may trail the gun by some interval. As described below relative to
Also, in order to prevent other code from accessing the valid data while it is present in the secure portion of the frame buffer, some process/thread locking mechanism needs to be employed to lock out other code during critical intervals. In the embodiment described below relative to
In summary, at typically an application or operating system level, a request will be made to create a secure region on the display device and to render data into that region in a secure fashion. This request will be processed by the SEDD, which schedules the content of the frame buffer according to the scheduling plan (e.g.,
Once the driver is invoked, a number of steps happen, which are dependent upon the operating system being used, especially what events (signals) can be received and what task (process/thread, or . . . ) locking mechanisms are available.
Depending upon the particular implementation, an application (or the operating system) may explicitly stop the obfuscation process (thereby destroying the secure region) or may simply change the data being presented in the already allocated secure region, or some combination of both. The “stop obfuscation” ioctl entry point is an interface for stopping the obfuscation process of a particular secure region. In step 1307, if the ioctl received indicates a desire to “stop obfuscation” then in step 1308, the driver code signals the real time thread (if one is currently running) to terminate (and obfuscate the secure portion). If a separate “DestroySecureDisplayRegion API (not shown) is used to invoke the “stop obfuscation” ioctl, cleanup of the VDB and other related data should be performed by that API.
Although the examples are described primarily with respect to implementing driver code for one designated secure region, one skilled in the art will recognize that these techniques are extendible to multiple requesters and multiple secure regions using standard programming techniques such as look up tables or by invoking one real time obfuscation control thread (RTOC thread) per requester, or using similar mechanisms. If multiple secure regions are being supported, then the driver code may register for a separate VB event for each secure region and spawn a RTOC thread for each, otherwise it may send a list of relevant VB events to the RTOC.
Specifically, in step 1401, the driver code determines whether the driver has been invoked at the entry point corresponding to the “start obfuscation” process and, if so, continues in step 1403, else continues in step 1404. In step 1402, the driver code allocates a secure portion of the frame buffer to correspond to the secure region on the display, if this is not already done by the corresponding API. In step 1403, the driver code invokes a (non real-time) timing and synchronization thread to emulate the event handling to determine when the VB signal corresponds to the VB_event_start. Then, either the timing and synchronization thread invokes the real time obfuscation control thread directly, or it is done following step 1401 (approach not shown). The driver code then waits for the next signal or ioctl event. In step 1404, if the ioctl received indicates a desire to “stop obfuscation” then in step 1405, the driver code signals the real time thread (if one is currently running) to terminate (and obfuscate the secure portion). (Again, if a separate “API (not shown) is used to invoke the “stop obfuscation” ioctl, cleanup of the VDB and other related data should be performed by that API.)
In step 1701, the RTOC thread determines whether decryption/de-masking is needed, and, if so, continues in step 1702, else continues in step 1703. In step 1702, depending of course on the obfuscation technique being used by the SEDD, the RTOC thread creates valid data by decryption or de-masking and sets an indicator to this value (pValidData). In step 1703, since valid data is already available, the RTOC thread just uses the valid data stored, for example, in the VDB. In step 1704, the RTOC thread copies in the indicated valid data to the secure portion of the frame buffer. In step 1705, the RTOC thread waits (if time not already passed) until VB_event_end and then in step 1706 re-obfuscates the secure portion of the frame buffer by whatever obfuscation technique is being used. (See, for example,
In one embodiment, the SEAD obfuscates the content of the pool of audio buffers 2202 by selecting in a SEAD specific manner, which buffers to use for sequencing the audio. For example, a random or pseudo-random sequence of numbers can be used to select which buffers to use to accumulate the digital form of the audio signal. To confound attempts to track utilization of the buffers, distracter information is placed into the buffers that are not being used. As the audio is passed in digital form to the next software component, if the component is authorized to use the SEAD for obscuring audio, then the audio is extracted from the audio buffers 2202 using the same random or pseudo-random sequence of numbers to determine the appropriate source buffers. When the audio is no longer required, the buffer is returned to the pool of available buffers or optionally, has distracter information placed in it.
The SEAD also can be implemented to obfuscate the audio data sent to the card by, for example, performing some operation “F” on the audio to encrypt or somehow encode or mask the data. (Operation “F” is soundcard dependent, and like other forms of encryption, has a counterpart reverse operation for decryption purposes.) When the audio is presented by the SEAD to the soundcard for conversion to the analog audio signal, SEAD instructs additional software on the soundcard, for example a DSP present on certain soundcards, to perform the de-obfuscation. This may be achieved on certain soundcards by creating an equalizer and sound processor code and treating the de-obfuscator codes in a manner similar to reverb, symphony hall, or other special effects.
In addition, when the SEAD is receiving a stream of audio information or the receiving security authorized software is forwarding a stream of audio information to the SEAD, the digital representation of the digital audio information may be pre-obfuscated or encrypted, in a secure driver specific manner, such that the SEAD can decrypt the audio in a safe manner. For example, the format of the may be encoded, or transcoded into the form acceptable for use by that system. The origins of the audio stream are derived from a conventional source, such as MP3 files or streams, streaming servers, or other encoded digital audio sources. The receiving secure software, that knows how to decrypt these encoded audio sources then renders the audio stream into the SEAD's internal obfuscation format such that plain “text=” of the audio is never present in the system in digital form.
The ability to control when a driver has access to input and/or output is especially important to security enhanced drivers. Each operating system provides mechanisms for ensuring that a particular driver has access before all other drivers, or before all of the drivers of its type (for example, hard disk drivers), depending upon the operating system. In operating systems similar to Windows 9× operating systems, event processing is performed in a “chain,” and drivers can be installed in various parts of the chain depending upon when they are loaded into the system.
For example, input event processing for Windows 9× operating systems proceeds typically as follows:
A hardware event occurs: mouse or keyboard activity (mouse movement or key presses).
A V×D style (virtual) device driver (or system level driver) detects and reads input from hardware and sends event to hardware virtualization layer.
The virtualization layer successively sends the driver event input to the list of device handlers registered for those events; allowing each device handler function to process the data or return without processing, allowing the next device handler in the chain to process the data.
Driver events may be processed by the handler or sent on to the application which registered for them.
Techniques of the present invention, when used in conjunction with Windows 9× operating systems, ensure that (especially) input SEDs are optimally secure by installing the relevant drivers as the top (first) event handler in the handler chain for each input device. In addition, a watchdog process is invoked, as described further below to periodically validate the handler position.
In Windows NT and derivative operating systems, input event processing follows a different model. For example, input event processing in these systems proceeds typically as follows:
A Hardware Interrupt Service Routine (ISR) works fast to collect data, building IRP I/O Request Packet
The ISR feeds into a Mini Port, which contains the hardware interface and knowledge of the device.
Data is abstracted and passed up further to the Port Driver. The port driver (usually 1 per I/O device). The port driver abstracts the process further and does more processing on the IRP
Data is then passed up to the Class Driver. Examples of this can be mouse class and kbdclass. These are the standard mouse and keyboard classes for the Windows Operating System.
Above the class drivers are the filter drivers, the filter drivers can become the first to receive input and then determine to pass it onto the existing system or not.
For example in Microsoft Windows OS a kernel driver can add itself into the upper filter key of the registry to note that it wants to receive key events.
Using the sequence as outlined above for NT OS I/O loading and processing, in one embodiment, a SED can be created as a class driver. The SED would then place a value in the upper filter of the registry to denote itself having input focus within the OS system. In this embodiment, the SED needs to ensure that it is the first filter in the registry along with ensuring that is the first of the filter drivers to receive the I/O Request Packet directly from the class driver.
The concepts for implementing a watchdog service to monitor security in both the Windows 9× and NT are similar, however the implementation varies to adhere to the driver model of each operating system. By inserting a SED's filtering (and potentially obfuscating) function as the first function to examine and/or process the driver's event data, SEDs ensure the validity and security of the mouse, keyboard, and other input devices; either processing the data for the secure environment or allowing the data to be returned to the operating system via the normal mechanism. One skilled in the art will recognize that similar techniques can be developed in other operating system environments, as long as the driver model is known and an SED filtering function can be appropriately inserted.
One skilled in the art will also recognize that no distinction is made between the mouse and keyboard devices for the purposes of using these techniques. The device drivers both operate in a similar manner for the purposes of this description. In addition, these techniques may be implemented with a trackball, a digitized tablet, a cordless keyboard, a cordless mouse, a numeric keypad, a touch pad, or any other pointer or key-based input device.
In an example Windows 9× implementation, a SED security service is installed which acts as a timer. Upon startup, the SED security service establishes a communications path to the SED driver using a standard mechanism, IOCTL( ). Via the IOCTL path, the SED security service signals the SED to verify that the SED is in the first (top) device handler position in the event processing handler chain of the mouse and keyboard. If this is not the case, the SED attempts to re-register the SED handler into the first position. If this attempt fails an error message is registered and the system is now considered to be unsecure for obfuscation purposes.
Upon detection of an unsecure environment, an event, for example, a application-specific event, is propagated through the environment, to inform all relevant applications. For example, in the xSides environment, described in detail in U.S. patent application Ser. No. 09/726,202, entitiled “Method and System for Controlling a Complementary User Interface on a Display Surface,” filed on Nov. 28, 2000, an xSides event is prograted throughout, informing all xSides applications that rely on secure input functionality that those devices (e.g., mouse and keyboard devices) are no longer considered secure. This change of security is communicated preferably to the user as well via an icon which is displayed in a secure region (as described above in the section entitled “Secure Storage and Display of Video Content.” Common bimaps used for this purpose are a locked or unlocked padlock.
To ensure that continuous security validation checks occur by the security service, a second service is started up to act as a watchdog to the SED security service called the SED security watchdog. The purpose of the security watchdog is to establish a bi-directional communications path to the security service on which messages are sent to and from the two services. These messages act as an “I'm alive” or ping mechanism, which informs each service that the other is functioning normally. If one service fails to receive a message from the other in some arbitrary time period, an attempt by the receiving service will be made to restart the other service.
If the receiving service is unable to restart the other service, then the system, for obfuscation purposes, is considered unsecure and the same notification to the user is performed as described above for the security service.
The security service for Windows NT derivative operating systems is essentially the same as for the Windows 9× version. One difference is that the value being verified is not a handler chain, but instead the value of the callback function pointer in the I/O completion structures for the input devices (e.g., mouse and keyboard). This is done by a comparison of the function pointers. If the SED callback function is not the callback function pointed to in the I/O completion structure, an attempt to replace it will be made. The failure modes described for Windows 9× for failing to change the function pointer for the callback function to the SED version are also preferably available for the Windows NT technique; i.e., secure/un-secure notification.
The basic SED security watchdog service operates similarly in the Windows NT environment as in the Window 9× environment.
An additional watchdog service (or an extension of the existing service) may be made available to verify the status of hooks, and verify that the SEDs have not been tampered with. An NT implementation includes two separate processes that registers an interest in two different system registry entries. If they are not in sync, the watchdog service notifies or automatically repairs registry entries that are not correct. The two registry entries have sufficient state to allow the watchdog executable to verify that the registry entries have not been tampered with. This may be, for example, the storing of the checksum, certificates, or the signature of the application in the registry entries of the watchdog itself, along with an XOR of the signature and another known value, or alternatively a signature derived by a different mechanism than the first. The watchdog is invoked if the registry entries are modified and verifies that the entries are correct at that time; and, if they are not correct, determines the correct values and replaces them. Since it is unlikely that (1) the signatures stored in the registry, (2) the watchdog itself, (3) the software the signatures were derived from, and (4) the software that verifies the watchdog itself can all be changed in a manner as to appear valid, this mechanism alone or in combination with other measures may be used to determine the state of intrusion or modification of the software codes.
As mentioned, to complement the obfuscation techniques and security enhanced drivers, the methods and systems of the present invention also provide different techniques for denoting various levels of security in the system. Some existing systems, such as applications like a web browser, provide a basic graphical representation of security or security-level. Microsoft's Internet Explorer for example, uses a representation of a “padlock” located in the bottom status bar region of the browser to represent to the user that a web site location is currently using secure or non-secure communication protocols, usually in the form of technologies such as SSL or HTTPS.
The security enhanced drivers of the present invention provide a mechanism by which a secure region on the display device, such as a displayed desktop, window, or an alternative display area may use the display cursor to intuitively identify to the user the security level of the region. Specifically, each secure region is associated with an attribute value that causes the display cursor to inherit a color value for the level of security associated with the specific region. As the cursor is moved, whether automatically or by the user, from one display area into another display area with a higher or lower security level, the cursor color and/or representation can change to an appropriate value. For example, as a user moves the cursor from within a non-secure Windows desktop display area into the alternative display area created by a alternative-display technology such as that developed by xSides Corporation, the cursor color may change from white to red or it may change from the standard Windows arrow cursor into a gold-key representation.
Similarly, this denotation mechanism can be used in an environment where multiple secure (or unsecure) regions are displayed on a display device, each with different inherent capabilities or security values. The security values associated with each region are queried using a mechanism such as the standard Microsoft Windows API routine, SetCursor( ). The return value of the SetCursor( ) routine contains the information necessary for application to identify the security level associated with the specific region.
This denotation mechanism is not limited to using a cursor as a means of security representation. One skilled in the art will recognize that other components of the desktop display or regions within or outside the desktop display can reflect the security level and capabilities to the user. If a secure desktop is loaded it can contain attributes that allow the end-user to distinguish its security level through a visible or auditory alteration to the windows of the secure desktop. For example, a secure desktop may have a lock or key associated with it and blended into a corner of the desktop display. The desktop might also take a different gradient of color when associated with a different security level. A window, an alternative display, or an arbitrary secure region may contain a colored border, which is associated with the security level. Or, for example, the surrounding border may change width, pattern, or even look like a chain, depending the security level of the window, alternative display, or secure region. Other implementations regarding the alteration or additions to the window, display, or region may optionally be used, such as placing additional decoration above the area, a diagonal striped black and yellow bar for example, or other placement in immediate proximity to the area, or within the area itself. Another alternative is to change the appearance of a standard user interface element decoration, such as a scroll bar, to an alternative form, pattern, color, or any combination of these. In addition, or in combination with the above variations, changes to the Title Bar, caption, or navigation icon may also be used to denote the level of security provided by the associated software of a particular window or region. These changes may be as simple as rendering the title bar caption in a different color set, or denoting a number or other symbol over the navigation icon of the window.
In the event that security can be provided or assured through multiple “agencies” or instances of software, it may benefit the user to know the origin of the security assurance. The system preferably indicates the security level through any of the mechanisms described above, while providing either persistent text denoting the security provider in the title bar, above the title bar, in a status bar, or other relatively fixed location, or in a non-persistent manner, such as a pop-up display, “tool tip” display, or transient text display in some other portion of the window or secure region of the display device. This transient text display may be triggered periodically, or by some outside event such as entry into the security state or movement of the text or mouse cursor over the security icon.
From the foregoing it will be appreciated that, although specific embodiments of the invention have been described herein for purposes of illustration, various modifications may be made without deviating from the spirit and scope of the invention. For example, one skilled in the art will recognize that the methods and systems for secure data input and output are applicable to other types of storage and input devices and to other types of data, streamed or otherwise, other than those explicitly described herein. For example, the obfuscation techniques used to obfuscate data within the frame buffer may be extended to obfuscate other types of storage. In addition such embodiments may be extended to provide a content scheduler for such storage using techniques similar to those described with respect to the security enhanced drivers described herein.
|Brevet cité||Date de dépôt||Date de publication||Déposant||Titre|
|US4290105 *||2 avr. 1979||15 sept. 1981||American Newspaper Publishers Association||Method and apparatus for testing membership in a set through hash coding with allowable errors|
|US5027400 *||16 août 1989||25 juin 1991||Hitachi Ltd.||Multimedia bidirectional broadcast system|
|US5583561 *||7 juin 1994||10 déc. 1996||Unisys Corporation||Multi-cast digital video data server using synchronization groups|
|US5715515 *||19 sept. 1994||3 févr. 1998||Scientific-Atlanta, Inc.||Method and apparatus for downloading on-screen graphics and captions to a television terminal|
|US6064739 *||14 août 1998||16 mai 2000||Intel Corporation||System and method for copy-protecting distributed video content|
|US6149522 *||29 juin 1998||21 nov. 2000||Silicon Gaming - Nevada||Method of authenticating game data sets in an electronic casino gaming system|
|US6151659 *||22 déc. 1997||21 nov. 2000||Emc Corporation||Distributed raid storage system|
|US6353892 *||5 déc. 2000||5 mars 2002||Alchemedia Ltd.||Copy protection of digital images transmitted over networks|
|US7066382 *||17 avr. 2001||27 juin 2006||Robert Kaplan||Method and apparatus for transferring or receiving data via the Internet securely|
|US20010016829 *||27 déc. 2000||23 août 2001||Hideki Toshikage||Image commercial transactions system and method|
|US20020057893 *||3 mars 1999||16 mai 2002||Anthony Wood||Digital recording and playback|
|US20020116630 *||20 févr. 2001||22 août 2002||Stehlin Jeffrey A.||System and method for establishing security profiles of computers|
|US20040049637 *||10 mars 2003||11 mars 2004||Mitsubishi Denki Kabushiki Kaisha||Cache memory for invalidating data or writing back data to a main memory|
|Brevet citant||Date de dépôt||Date de publication||Déposant||Titre|
|US7065651||16 janv. 2002||20 juin 2006||Microsoft Corporation||Secure video card methods and systems|
|US7197648 *||27 janv. 2005||27 mars 2007||Microsoft Corporation||Secure video card methods and systems|
|US7206940||24 juin 2002||17 avr. 2007||Microsoft Corporation||Methods and systems providing per pixel security and functionality|
|US7272726||27 janv. 2005||18 sept. 2007||Microsoft Corporation||Secure video card methods and systems|
|US7284135||30 juil. 2003||16 oct. 2007||Microsoft Corporation||Methods and systems for maintaining an encrypted video memory subsystem|
|US7293178||9 déc. 2002||6 nov. 2007||Microsoft Corporation||Methods and systems for maintaining an encrypted video memory subsystem|
|US7299365||27 janv. 2005||20 nov. 2007||Microsoft Corporation||Secure video card methods and systems|
|US7302586||27 janv. 2005||27 nov. 2007||Microsoft Corporation||Secure video card methods and systems|
|US7337328||27 janv. 2005||26 févr. 2008||Microsoft Corporation||Secure video card methods and systems|
|US7337329||27 janv. 2005||26 févr. 2008||Microsoft Corporation||Secure video card methods and systems|
|US8001607||21 avr. 2007||16 août 2011||Direct Computer Resources, Inc.||System and method for obfuscation of data across an enterprise|
|US8155314||24 juin 2002||10 avr. 2012||Microsoft Corporation||Systems and methods for securing video card output|
|US8738929||2 mars 2012||27 mai 2014||Microsoft Corporation||Auxiliary functionality for pixel data|
|US20040109563 *||30 juil. 2003||10 juin 2004||Evans Glenn F.||Methods and systems for maintaning an encrypted video memory subsystem|
|US20040111627 *||9 déc. 2002||10 juin 2004||Evans Glenn F.||Methods and systems for maintaining an encrypted video memory subsystem|
|US20050125619 *||27 janv. 2005||9 juin 2005||Microsoft Corporation||Secure video card methods and systems|
|US20050152547 *||27 janv. 2005||14 juil. 2005||Microsoft Corporation||Secure video card methods and systems|
|US20050154902 *||27 janv. 2005||14 juil. 2005||Microsoft Corporation||Secure video card methods and systems|
|US20050154903 *||27 janv. 2005||14 juil. 2005||Microsoft Corporation||Secure video card methods and systems|
|US20050160285 *||27 janv. 2005||21 juil. 2005||Microsoft Corporation||Secure video card methods and systems|
|US20050166042 *||27 janv. 2005||28 juil. 2005||Microsoft Corporation||Secure video card methods and systems|
|Classification aux États-Unis||1/1, 707/999.001|
|Classification internationale||G06F1/00, G06F21/00|
|Classification coopérative||Y10S707/99932, Y10S707/99939, G06F21/82|
|13 sept. 2006||AS||Assignment|
Owner name: XSIDES CORPORATION, WASHINGTON
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:NASON, D. DAVID;EASTON, JOHN E.;SMITH, JASON M.;AND OTHERS;REEL/FRAME:018244/0109;SIGNING DATES FROM 20020830 TO 20020904
Owner name: XSIDES CORPORATION, WASHINGTON
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:KAAN, CARSON;REEL/FRAME:018244/0136
Effective date: 20030623