KR20040000348A - Systems and methods for securing video card output - Google Patents

Abstract

PURPOSE: A system and method for protecting the output of a video card is provided to overcome a software attack, especially for the case of attack performed by a defective application executed on a user's machine. CONSTITUTION: A graphic processor unit(308) processes the video data rendered to a monitor. A video memory(310) operatively linking with the graphic processor unit(308) stores the data processed or to be processed by the graphic processor unit(308). A display converter(312) converts the digital data into a used signal when the data is rendered to the monitor. A decoder decodes the pixel data provided to the display converter.

Description

SYSTEM AND METHOD FOR PROTECTING VIDEO CARD OUTPUT {SYSTEMS AND METHODS FOR SECURING VIDEO CARD OUTPUT}

The present invention relates to a method and system for processing data using a video card.

Typically, content residing on a computer can be attacked by individuals who wish to steal or alter the content. As an example, consider the case of a content asset such as a movie studio or user published content on the web. Typically these individuals will publish video content with restrictions on how users can view it. This content can typically be viewed or rendered on a computer, such as a personal computer. Substantial time, effort, and money are spent every year by immoral individuals and organizations attempting to steal or otherwise inappropriately obtain such video content. Also consider, for example, eCommerce software that allows individuals to make transactions such as banking. Data displayed on a display monitor for review and manipulation by the user may be attacked by a defective software application running on the user's computer. That is, defective programs or devices often attempt to improperly obtain content once the content is received on a computer, such as a personal computer.

One solution for content security may include several software-based Digital Rights Management (DRM) solutions. The problem here is that although a software-based tamper-resistant "difficult to observe" DRM system with software rendering is good-ultimately, the bits are all recorded on a video card that can be "shown" or Or even by other software. This represents a room for attack. Therefore, video cards processing video content may be subject to software attacks.

1 illustrates an example video (or graphics) card 100 that includes a bus connector 102 that inserts into a port on a typical computer. Video card 100 also includes a monitor connector 104 (eg, a 15-pin plug) that receives a cable connecting to the monitor. Video card 100 may include a digital video-out socket 106 that may be used to transmit video images to LCDs, flat panel monitors, and the like.

Modern video cards are contained within four main components: graphics processor unit (GPU) 108, video memory 110, random access memory digital-to-analog converter (RAMDAC) 112, and video BIOS 114. It consists of driver software.

GPU 108 is a dedicated graphics processing chip that controls the resolution, color depth, and all aspects of all elements associated with the rendered image on the monitor screen. The computer's central processing unit or CPU (not shown) sends a set of drawing instructions and data that are interpreted by the graphics card's proprietary driver and executed by the card's GPU 108. GPU 108 performs operations such as bitmap transfer and painting, window resizing and repositioning, line drawing, font scaling, and polygon drawing. GPU 108 is designed to handle these tasks in hardware much faster than software running on the system's CPU. The GPU then writes the frame data to the frame buffer (or on-board video memory 110). The GPU significantly reduces the workload of the system CPU.

The memory holding the video image is also called the frame buffer and is usually realized on the video card itself. In this example, the frame buffer is realized on the video card in the form of memory 110. Early systems realized video memory in standard DRAM. However, this requires continuous refreshing of the data so that no data is lost, and cannot be changed during this refresh process. The result of the particularly high clock speeds required by modern graphics cards is that performance is severely degraded.

The advantage of realizing video memory on the video card itself is that it can be tailored to specific tasks, and in fact this has led to the proliferation of new memory technologies:

Video RAM (VRAM): A special form of dual port DRAM that can be written and read simultaneously. It also requires much less frequent refreshing than conventional DRAM and therefore performs much better.

Windows RAM (WRAM): As used by Matrox Millennium cards, it is also a dual port and can run slightly faster than conventional VRAM.

EDO DRAM: Provides higher bandwidth than DRAM, can be clocked faster than conventional DRAM, and manages read / write cycles more efficiently.

SDRAM: Similar to EDO RAM, except that memory and graphics chips run on a common clock used for latch data, allowing SDRAM to run faster than regular EDO RAM.

SGRAM: Same as SDRAM, but supports block write and write per bit, further improving performance on graphics chips supporting these enhanced features.

DRDRAM: Direct RDRAM is an entirely new general-purpose memory architecture with the promise of 20-fold performance improvement over conventional DRAM.

Some designs integrate graphics circuitry into the motherboard itself, using part of the system RAM for the frame buffer. This is also called an "integrated memory architecture" and is only used for cost saving reasons, which can result in poor graphics performance.

The information in the video memory frame buffer is any image that appears on the screen and is stored as a digital bitmap. However, while video memory contains digital information, its output medium-monitor-may use analog signals. The analog signal requires exactly more than the "on" or "off" signal, but in practice it ignites at, when, and at what intensity the guns should ignite as they scan across the front of the monitor. Used to determine if it should be. This is the point where the RAMDAC 12 moves as described later. Some RAMDACs also support digital video interface (DVI) outputs for digital displays such as LCD monitors. In this configuration, the RAMDAC converts the internal digital representation into a form understandable by the display.

The RAMDAC acts as a "display converter" because it converts internal digital data into a form understood by the display.

Although not all of the video memory installed on the video card is required for a particular resolution, the extra memory is often used to cache information about the GPU 108. For example, caching of commonly used graphic items, such as text fonts and icons or images, improves performance by avoiding the need for the graphics subsystem to load them whenever new characters are recorded or icons are moved. The cached image can be used to queue up a sequence of images that will be presented by the GPU, allowing the CPU to freely execute other tasks.

Many times per second, the RAMDAC 112 reads the content of the video memory, converts it to a signal, and sends it to the monitor via the video cable. In the case of analog displays, there is typically one digital-to-analog converter (DAC) for each of the three primary colors, and the CRT is used to create the full color spectrum. In the case of a digital display, the RAMDAC is interpreted to output one RGB data stream to be displayed by the output device. The intended result is the correct mix needed to produce the color of one pixel. The speed at which the RAMDAC 112 can convert information, and the design of the GPU 108 itself, dictate the range of refresh rates that the graphics card can support. RAMDAC 112 also dictates the number of colors available at a given resolution, depending on its internal architecture.

Bus connector 102 may support one or more buses used to connect with a video card. For example, the Accelerated Graphics Port (AGP) bus allows video cards to directly access system memory. Direct memory access helps to produce multiple peak bandwidths higher than the Peripheral Component Interconnect (PCI) bus. This allows the system's CPU to do other work while the GPU on the video card is accessing the system memory.

In operation, data contained in the on-board video memory may be provided in the system memory of the computer and managed as if it were part of the system memory. This includes such things as virtual memory management techniques used by the computer's memory manager. Moreover, when data contained in the memory of the system is required for graphics operation on the video card, the data is transferred to the video card via a bus (e.g., a PCI or AGP bus) in the on-board video memory 110 Can be stored. The data can be accessed and manipulated by the GPU 108 as described below.

The present invention arises from the interest associated with providing a method and system for protecting data. In particular, the present invention has arisen from the interest associated with providing methods and systems for coping with software attacks, particularly attacks performed by defective applications executed on a user's machine.

Various methods and systems described herein relate to providing a secure channel to software running on a host computer. This method and system addresses the attack model in which defective software running on a host computer improperly obtains data or otherwise attempts to manipulate the data, and provides a solution to that attack model. Some embodiments may provide pixel data that may be kept confidential (unreliable software applications cannot read data from the display screen). In addition, other embodiments may preserve the integrity of the pixel data by detecting that the pixel data has been improperly manipulated.

Various embodiments are placed on the video card very late in the video processing chain such that program access to the decrypted pixel data is not allowed.

1 is a block diagram illustrating various components of an exemplary video or graphics card intended for use in a computer system.

2 is a block diagram of an exemplary computer system that can use a video card in accordance with the embodiments described above.

3 is a block diagram illustrating various components of an exemplary video or graphics card according to one embodiment.

4 is a block diagram illustrating an exemplary major surface having a safe area and a non-secure area.

5 is a flow diagram illustrating steps of a method according to one embodiment.

6 is a flowchart illustrating steps of a method according to one embodiment.

7 is a block diagram illustrating an exemplary major surface having a safe area and an unsafe area.

8 is a block diagram showing a display screen having an overlapping window.

9 illustrates exemplary pixel data and associated auxiliary function table.

10 is a flowchart describing steps of a method according to one embodiment.

FIG. 11 illustrates an exemplary per-pixel key table in accordance with an embodiment. FIG.

12 is a flowchart describing steps of a method according to one embodiment.

13 illustrates an example table according to an embodiment.

<Explanation of symbols for the main parts of the drawings>

108, 308: Graphic Processor Unit (GPU)

110, 310: on-board video memory

112, 312: RAMDAC

114, 314: Video BIOS

316: memory controller

318: control processor

319 key manager

320: decipher

322: safety applications

Example Computer System

2 illustrates an example of a suitable computing environment 200 in which the systems and associated methods described below may be implemented.

It should be understood that the computing environment 200 is only one example of a suitable computing environment and is not intended to impose any limitation on the scope or functionality of the media processing system. Computing environment 200 should not be construed as having any dependencies or requirements related to any one component or combination of components shown in example computing environment 200.

The various described embodiments may be operable in various other general purpose or dedicated computing system environments or configurations. Examples of well-known computing systems, environments, and / or configurations that may be suitable for use with media processing systems include personal computers, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, networks PCs, minicomputers, mainframe computers, distributed computing environments, including any of the above systems or devices, and the like.

In certain embodiments, a system and associated method may be well described in computer-executable instructions in a general context, such as a program module executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Embodiments may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.

According to the embodiment shown in FIG. 2, the computing system 200 may include various system components including one or more processors or processing units 202, system memory 204, and system memory 204. It is shown to include a bus 206 that connects to it.

The bus 206 is intended to represent any one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. It is intended. By way of example, but not limitation, such architecture is also known as an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Mezzanine bus. Contains the known PCI bus.

Computer 200 typically includes a variety of computer readable media. Such media may be any available media that is locally and / or remotely accessible by computer 200, including volatile and nonvolatile media, removable and non-removable media.

In FIG. 2, system memory 204 includes computer readable media in the form of volatile memory, such as RAM 210, and / or non-volatile memory, such as ROM 208. A Basic Input / Output System (BIOS) 212 is stored in ROM 208 that includes a basic routine that assists in transferring information between elements in computer 200, such as during start-up. RAM 210 typically includes data and / or program modules that are currently accessible by immediately accessible and / or processing unit (s) 202.

Computer 200 may further include other removable / removable, volatile / nonvolatile computer storage media. By way of example only, FIG. 2 illustrates a hard disk drive 228 (not shown and typically referred to as a "hard drive") that reads from and writes to a non-removable nonvolatile magnetic medium, a removable nonvolatile magnetic disk. Magnetic disk drive 230 that reads from and writes to 232 (e.g., " floppy disk "), and removable non-volatile optical disk 236 such as a CD-ROM, DVD-ROM, or other optical media. Shows an optical disk drive 234 that reads from or writes to this disk, hard disk drive 228, magnetic disk drive 230, and optical disk drive 234 are connected to a bus (e.g., by one or more interfaces 226). 206, respectively.

The drive and its associated computer readable medium provide non-volatile storage of computer readable instructions, data structures, program modules, and other data for the computer 200. The example environment described herein uses hard disk 228, removable magnetic disk 232, and removable optical disk 236, but such as magnetic cassettes, flash memory cards, digital video disks, RAM, ROM, and the like. Those skilled in the art should understand that other types of computer readable media capable of storing data accessible by the computer may also be used in the exemplary operating environment.

Multiple program modules may include, for example, but not limited to, operating system 214, one or more application programs 216 (eg, multimedia application programs 224), other program modules 218, and program data. It may be stored on hard disk 228, magnetic disk 232, optical disk 236, ROM 208, or RAM 210, including 220. A user may also enter commands and information into the computer 200 through input devices such as a keyboard 238 and pointing device 240 (eg, a “mouse”). Other input devices may include audio / video input device (s) 253, microphones, joysticks, game pads, satellite dishes, serial ports, scanners, and the like (not shown). These and other input devices are connected to the processing unit (s) 202 through input interface (s) 242 connected to the bus 206, which may be other interfaces such as parallel ports, game ports or Universal Serial Bus (USB). And by bus structures.

The monitor 256 or other type of display device is also connected to the bus 206 via an interface such as a video adapter or video / graphics card 244. In addition to the monitor, the personal computer typically includes other peripheral output devices (not shown), such as speakers and printers, which may be connected via the output peripheral interface 246.

Computer 200 may operate in a networked environment using local connections to one or more remote computers, such as remote computer 250. Remote computer 250 may include many or all of the elements and features described herein in connection with a computer.

As shown in FIG. 2, computing system 200 is capable of communicating to a remote device (eg, remote computer 250) via a local area network (LAN) 251 and a general wide area network (WAN) 252. Is connected. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet.

When used in a LAN networking environment, the computer 200 is connected to the LAN 251 through an appropriate network interface or adapter 248. When used in a WAN networking environment, the computer 200 typically includes a modem 254, or other means for establishing communications over the WAN 252. The modem 254, which may be internal or external, may be connected to the system bus 206 via the user input interface 242, or other suitable mechanism.

In a networked environment, program modules depicted relative to the personal computer 200, or portions thereof, may be stored in the remote memory storage device. By way of example, but not limitation, FIG. 2 illustrates a remote application program 216 residing in the memory device of remote computer 250. It will be appreciated that the network connections shown and described are exemplary and other means of establishing a communications link between the computers may be used.

outline

Various methods and systems described herein relate to providing a secure channel to software running on a host computer. This method and system addresses an attack model in which a defective application running on a host computer attempts to improperly obtain or otherwise manipulate data, and provides a solution to that attack model.

Various embodiments can provide a safe execution environment in which data can be safely rendered on a display screen for user interaction. The described embodiments can implement one or two of the following features, among other features.

The first feature is that the data, for example pixel data residing on the video card, can be kept secret. This means that unreliable software applications (or defective applications) cannot read data from the display screen or from video memory. The confidentiality aspect is useful in digital workplaces, because if it is rendering video or pixel data, it will send the video data to the video card in such a way that a "cracking tool" running on the computer cannot read the data. It is because it is desirable to be able to. For example, consider a user working with a secure email program that allows data to be received in encrypted form. Various embodiments may allow data to be rendered on a display screen without the risk of defective applications that may be able to access the data.

The second feature is integrity. According to this, in essence, a person does not want unreliable software (or defective software) to be able to manipulate the data displayed on the parts of the display. For example, consider an e-commerce setting where a user decides to pay $ 10 to a given entity through software running on their computer. The user may simply type the dollar amount into the window displayed on their display screen. However, there is a possibility that a defective application may change "$ 10" to "$ 1000". As you can understand, this is not a good idea: the user has allowed more payments than they intended.

In addition, if some unreliable software improperly manipulates the data in any way, it would be desirable to be able to signal that this has happened. Thus, some embodiments described below provide a means by which data manipulation can be detected.

Example Embodiments

Embodiments described below relate to providing a secure video output—that is, a video output that is not susceptible to software attacks. Various embodiments may provide window-based protection that may be selectively applied to an area on the user's display screen (ie, a window) rather than the full screen area itself, even if full screen protection is not excluded. Secure video output is typically not readable by unreliable software. This feature provides protection for content such as premium content (eg, videos, books), as well as a wide range of common e-commerce and security applications.

In addition, various embodiments may provide a so-called safety dialog that is not (obviously or completely) obscured by an unreliable dialog. This feature is most useful in general e-commerce situations.

Embodiments described below are encryption-based solutions that provide secure video output. An advantage of the various embodiments is that these embodiments are typically easy to realize and substantially do not conflict with existing software architectures.

Some embodiments to be described are based on a decryption engine that was placed on the video card very late in the video processing chain. In the example described herein, many aspects of the embodiments are realized in hardware-other aspects may be implemented in firmware and software.

A preferred feature of this embodiment is that various data to be displayed on the display screen of the user are encrypted. Thus, an attack on stealing data is simply stealing encrypted data. Encryption techniques can be used such that any stolen encrypted data cannot be mathematically decrypted. Incidentally, decryption of encrypted data occurs at one point in the processing chain such that there is no program access to the decrypted bits to be marked. That is, there is no software access to the decrypted bits such that the defective software running on the user's computer cannot access the decrypted bits.

In one embodiment, the decoder is located on the video card and is positioned in between the GPU and the display converter (eg, RAMDAC). The decryptor is preferably realized in hardware and can process the encrypted data in real time as the video card rasterizes the frame buffer with the display converter.

Example Architecture

3 illustrates an example video (or graphics) card 300 according to one embodiment. Card 300 includes a bus connector 302 that fits into one port of a typical computer. Video card 300 also includes a monitor connector 304 (eg, a 15-pin plug) that receives a cable that connects to the monitor. Video card 300 may include, but need not include, a digital video-out (eg, DVI) socket 306 that may be used to transmit video images to digital displays and the like.

Like the video card of FIG. 1, video card 300 may include a graphics processor unit (GPU) 308, video memory 310, display converter or random access memory digital-to-analog converter (RAMDAC) 312, and a video BIOS. 314 includes driver software that can be included.

GPU 308 is a dedicated graphics processing chip that controls resolution, color depth, and all aspects of all the elements involved in rendering an image on a monitor screen. Memory controllers (sometimes integrated into the GPU) manage the memory on the video card. The computer's central processing unit or CPU (not shown) sends a set of drawing instructions and data that are interpreted by the graphics card's proprietary driver and executed by the card's GPU 308. GPU 308 performs operations such as bitmap transfer and painting, window resizing and repositioning, line drawing, font scaling, and polygon drawing. The GPU may then write the frame data to the frame buffer (or on-board video memory 310).

The information in the video memory frame buffer is an image that appears on the screen and is stored as a digital bitmap. RAMDAC 312 is used to convert the digital bitmap into a form that can be used to render on a monitor, as described above.

In addition to these components, in this embodiment, video card 300 includes a control processor 318 and a memory controller 316, which may include a key manager 319. The video card also includes a decoder 320. Such components may be realized in any suitable hardware, software, firmware or combination thereof.

The memory controller 316 receives data on the video card and manages data in the video memory 310. The memory controller may also be responsible for managing the data transfer between the video card and the system memory.

A control processor 318 is provided and may include a key manager 319. The control processor may be responsible for organizing cryptographic functions occurring on the video card. For example, the control processor 318 may communicate with the decryptor 320 via a dedicated bus or secure channel, such that the decryptor has the decryption capability necessary to properly decrypt the encrypted pixel data for security reasons. Control processor 318 may manage keys associated with encrypting and decrypting appropriate pixel data via key manager 319. In some embodiments, the control processor may be realized as a separate integrated circuit on the video card.

Decoder 320 is configured or configurable to decode the appropriate pixel data. For example, as will be described in more detail below, data to be protected may be encrypted and written to a safe area, which includes data used by the RAMDAC 512 to render an image on a monitor. Of the so-called "major surface" or desktop surface of the video card memory. The encrypted image may be copied to a temporary location in video memory before being copied to the major surface. The control processor 318 may set an encryption key to be used to encrypt the data and provide the decryption key to the decryptor 320 for use in decrypting the encrypted pixel data. Once the data is decrypted, the data can be passed to the RAMDAC for further processing.

While the decoder is shown as a separate component, it should be appreciated that the RAMDAC can be equipped with the appropriate decryption function in order to operate efficiently as the decoder.

In operation, a secure or trusted software application 322 may set up a shared key between the decryptor 320 and the software application. The software application can then use the key to generate encrypted pixel data that can be stored in memory (video memory 310 or system memory).

Typically, there are different ways of combining pixel data that can be written into a protected area or frame buffer of the major surface. First, the pixel data can be written directly to the frame buffer through a " move " operation provided by the memory controller. Second, the application (safety application 322) can assemble the pixel data to be protected in the system memory being encrypted. Encrypted data in system memory will ultimately be copied to the major surface for decryption and rendering.

The control processor then ensures that the decoder 320 knows which key to use to decrypt the pixel data before the data is sent to the RAMDAC 312 (or before it is rendered on the monitor).

Therefore, in this example, there is a mechanism in which one or more keys can be shared between trusted entities. The data can be encrypted on the video card and decrypted at one point in the data processing chain so that the unencrypted data to be rendered on the display monitor is not easily subjected to software attacks. Untrusted or defective entities that wish to read encrypted data in the protected area (s) of the major surface will only read encrypted data that cannot be effectively used. Incidentally, this is still valid when VRAM memory is mapped into system memory through virtual memory management techniques. Therefore, whether data that is thought to be in the protected area (s) of the major surface is on the video card or mapped into the memory of the system, it is encrypted and protected.

Safety window (s)

In one embodiment, one or more safety windows may be provided and used to display secret data on a user's display screen. The safety windows on the user display screen are associated with and correspond to a safe area of the major surface in the video card's memory (or system memory when virtual memory management technology is used). As an example, consider FIG. 4.

There, a graphical representation of the major surface of the video card is indicated generally by the reference numeral 400. Major surface 400 includes an area 402 (dark portion) containing unencrypted data, and one or more areas containing encrypted data. In this particular example, two example areas 404 and 406 may include encrypted data. Corresponding secure windows of each safe area are indicated by reference numerals 404a and 406a, respectively.

In this embodiment, the decoder 320 (FIG. 3) is configured to pass without changing (ie, decrypting) all pixel data in the area 402. That is, since data in region 402 is not encrypted, decoder 320 does not need to decrypt the data. However, the decryptor decrypts the encrypted data present in areas 404 and 406.

Pixel data in areas 404 and 406 can be decrypted by the decryptor using a key associated with the safe area. In some embodiments, one key may be associated with all safe zones. In other embodiments, each safe area may have its own associated key. One reason for having a separate key for each safe zone is that some safe zones may not be associated with any application that can access other safe zones. For example, suppose a secure email application is associated with a single safe zone for encrypted email to exist. Also assume that e-commerce applications relate to different areas of safety. In fact, there is no reason for an email application to access the secure areas associated with an e-commerce application. Now, if there is only one key for every safe zone, every application that can access one safe zone will probably have access to all other safe zones. Thus, by providing different keys for each secure zone, access to each secure zone is limited to those applications that must be accessible.

Alternatively, in another embodiment, the central entity ("mixer" or "compositor") has several areas and can convert them into generic keys that will be decrypted by the display hardware. Each application will need to trust the compositor entity.

5 is a flowchart illustrating steps of an encryption method according to an embodiment. This method can be realized with any suitable hardware, software, firmware or combination thereof. In this example, this method can be realized at least in part by a properly configured video card, the example provided above.

Step 500 defines one or more safe areas of the major surface. These areas can be configured in any suitable shape and size. In this example, the safety zone may be rectangular in shape. These areas are preferably smaller than they should occupy the entire display screen when rendered on the display screen. Step 502 associates at least one key with an individual safe area of the major surface. The key or keys can be used to encrypt and / or decrypt pixel data for being in the secure area. Step 504 uses a key or keys to encrypt pixel data. This step can be realized with trusted system software, firmware and / or hardware. For example, a secure application, such as application 322, may allow pixel data to be encrypted. Step 506 records the encrypted pixel data or otherwise moves to a safe area of the major surface. Once the pixel data is encrypted, the underlying decrypted data is protected from theft.

6 is a flowchart illustrating steps of a decryption method according to an embodiment. This method can be realized with any suitable hardware, software, firmware or combination thereof. In this example, this method may be realized, at least in part, by an appropriately configured video card—an example provided above.

Step 600 provides encrypted data within a secure area of the video card major surface. This step can be realized by the control processor 318 (FIG. 3). For example, the control processor may provide one or more keys to a decryptor for use in decrypting the encrypted pixel data. Step 604 uses the key to decrypt the encrypted data in the secure area of the major surface. This step can be realized by the decoder 320 (FIG. 3). The point in the pixel data processing chain where decryption occurs is difficult to programmatically access. Therefore, the decrypted pixel data is protected from software attack. Step 606 then provides the decoded data to the display converter for further processing, including processing to render the pixel data onto the user's display screen.

Example

In one embodiment, encryption and decryption can occur using a public key based engine. The control protocol allows software, such as security applications, to send commands in encrypted form to the control processor 318 (FIG. 3), receiving a cryptographic confirmation to ensure that the command has been executed.

Any suitable command set can be used. As one example, the following commands (or the like) may be used:

GetPK (): returns the device public encryption key

Setsec (): Sets the security zone shape and the encryption key for the security zone shape.

ClearSec (): clears encryption for one area

In some embodiments, the decryptor 320 may infer the appearance of the safe area to decrypt the encrypted pixel data in the area. In yet another embodiment, the decryptor may be informed of the appearance information. This may be useful, for example, when the safety window is dragged and dropped to another location on the user's display screen. For example, GPU 308 may implement an external processor (not specifically shown) that maintains a list of safe areas of the major surface and various security data associated with those areas. The security data may include x, y coordinates of the area, width and height dimensions of the area, and keys associated with the particular area. When the decoder 320 starts to process the pixel data, it can be notified of this secure data so that it knows whether a particular pixel needs to be decoded belonging to one of these areas, or whether the particular pixel data will be passed to the RAMDAC. have. When the safety window is moved, the external processor can inform the decryptor of the new coordinates of the security window.

In one example architecture, the public key and control functions can be modulated into a separate external device (similar to a 'smartcard') with on-board flash memory. In contrast, the decoder 320 can be integrated into (ie, integrated with) the GPU silicon. The control processor 318 can then pass the decryption key directly to the GPU. As another precaution to prevent software attacks, a dedicated bus may be provided between the control processor 318 and the GPU 308.

In operation, the control processor 318 may be authenticated by the safety software / hardware and may receive an encrypted command such as "set the encryption key for this secure zone to be x". The control processor can then return a cryptographic response so that the command can be executed properly.

The encryption key can now be used to provide video data to the secure area. In this example, an adversarial code may be able to read this encrypted data. However, certain data read by this code is encrypted and cannot be effectively written to the opponent's code. In some embodiments, it may be possible for the adversary's code to change the encrypted data. However, the modified encrypted data will be decrypted into data that can be logically considered in contextual context when rendered on the display screen. For example, such data may appear when rendered on a display screen as random noise / gray output. This kind of attack will most certainly be noticed by the user.

Also, the use of authentication information allows the user to be notified when the pixel data has been changed by the adversary's code. As an example, consider the following: The safety data format may be required to include any number of bits per pixel, for example 24 bits / pixel. Of 24 bits / pixel, 8 bits may always be required to have a value of zero. The decrypter can then be configured to produce non-compliant pixels flash purple and can notify the control processor that there is an attack.

In addition, other techniques may be used to allow such a change to be detected if the pixel data has been inappropriately changed. As an example, consider the following: A hash can be calculated for pixel data associated with each pixel to be rendered. Once the pixel data is processed by the display converter (eg, RAMDAC 312), the display converter can calculate a hash of the pixel data and compare the calculated hash with a previously calculated hash of the pixel data. If there is an inappropriate data change, a hash comparison will indicate that such a thing has happened.

Exemplary Encryption Technology

Various encryption techniques can be used to ensure that pixel data present in the secure area of the major surface is encrypted and then later properly decrypted by the decryptor. While other techniques can be used without departing from the spirit and scope of the claimed invention, two exemplary encryption techniques are described below.

The first encryption technique that can be used is a stream cipher. Stream ciphers are typically very fast in software and very easy to implement in hardware. Stream ciphers are a kind of symmetric encryption algorithm that typically operates on smaller text, usually bits. The stream cipher produces what is called a keystream (a sequence of bits used as a key). Encryption is usually accomplished by combining text or bits with a keystream in a bitwise XOR operation. The generation of the keystream does not depend on the original and cipher text, but yields what is called a synchronous stream cipher, or it may depend on the data and its encryption, in which case the stream cipher is called self-synchronization. Most stream cipher designs are for synchronous stream ciphers. The same stream cipher can then be used to decrypt the encrypted data.

Stream ciphers can be executed over the entire major surface in a way that only decrypts data within the safe area of the major surface. However, this is not the best choice because stream ciphers do not need to be executed across the entire major surface—only in these safe areas. Thus, the range in which the stream cipher is performed may be limited such that the range is defined only as a safe area or a boundary of areas. A preferred way to realize a limited range of stream ciphers is to specify the starting position of the stream cipher, such as the upper left pixel of the safe area, for each refresh of the display. The stream cipher can then be executed in the safe area until the pixels on the bottom right of the safe area have been processed.

As an example, consider FIG. There, the major surface 700 includes an area 702 in which unencrypted pixel data exists and a safe area 704 in which encrypted pixel data (encrypted with a stream cipher) exists. With an appropriately limited stream cipher, the stream cipher may start at the position where the upper left pixel is marked and end at the position where the lower right pixel is marked. When encrypted data is decrypted, a decrypter such as decryptor 320 may be informed of the coordinates of the start and stop positions of the stream cipher. One of the preferred features of this realization is that if the safety window associated with one of the safe zones is dragged and dropped to another location (where the untrusted software can be invoked to move around the window), the encryption operation is performed. It can be done in a new position. To realize this, the cryptographic entity only needs to be notified of the new coordinates of the secure window (and thus the secure area on the major surface) so that it can execute the encryption processing at the new location. Similarly, decrypter 320 may also be informed of the location so that the stream cipher can be executed at an appropriate location for decrypting the encrypted pixel data.

The encryptor allows stream ciphers to persist between several frames, making differential attacks more difficult. The key for the stream cipher may be changed after each frame group. To reduce the number of keys, an array of fixed keys can be negotiated before being used. The encryptor can cycle through an array of keys that elect a different key for each group of frames.

A second encryption technique that can be used is block cipher. A block cipher is a kind of symmetric-key cipher and algorithm that converts a fixed length block of original data bits (unencrypted text or bits) into a block of ciphertext (encrypted text or bits) of the same length. This conversion occurs under the operation of the user-provided secret key. Decryption is performed by applying the reverse conversion of the ciphertext block using the same secret key. The fixed length is called the block size, and for many block ciphers, the block size is 64 bits. In the future, block size will increase to 128 bits as processors become more sophisticated.

Of the two encryption techniques described above, stream ciphers are the preferred choice because they are much faster than block ciphers.

certification

In some embodiments, authentication techniques can be used to ensure the integrity and identity of the video card. An important goal of a safety software application for interacting with a video card is that (1) the application does not actually communicate with the video card and is not part of the software that mimics the video card, and (2) the application is selected for the provision of pixel data. It allows the application to be authenticated reliably so that it actually communicates to a video card that follows or conforms to rules.

The authentication technique can be realized through a pair of different ways-for example, cryptographic proof and other communication protocols.

Cryptographic proof relates to making a video card equipped with a certified key and a digital certificate. Using these keys and certificates, the video card can be used in cryptographic conversations with security software applications. For example, a digital certificate can be used to authenticate a video card, and the certified key can be used to encrypt communications that occur with secure applications. To realize cryptographic proof, each video card may have a separate secure IC chip manufactured by a trusted entity. Cryptographic proof techniques are well known and are understood by those skilled in the art. Therefore, for the sake of brevity, we will not discuss the cryptographic proof any further.

Another means of authentication may be associated with a safety protocol established between the safety application and the video card. The safety protocol can give the application some confidence that it is communicating with a valid video card. For example, a trusted application may challenge the video card to verify itself, and the card may respond with a response that it is a reliable video card. Various known safety protocol techniques can be used.

Several advantages are provided by the embodiments described above. First, a technique is provided that can enable data (on and off of a video card) to be protected from soft attacks. Protection is provided in the form of encryption technology that can be used to encrypt data present on the major surface of the video card. Decryption can then occur at a point in the data processing pipeline without software access. Therefore, any read attack by the defective software will be encrypted resulting in essentially useless data. Therefore, pixel data can be kept secure. Moreover, various techniques can enable the integrity of the data to be preserved. That is, in the case of a data change attack, various detection methods can be used so that appropriate notifications (application notifications and user notifications) can be generated. Advantages are also achieved by being able to define a safe area of the major surface identified by a particular contour.

Per-pixel auxiliary functionality

In some embodiments, it may be desirable to provide functionality to individual pixels of granularity. For example, the safety area of the major surface typically does not overlap. However, in some cases, a user may wish to move to a peripheral window on their display such that the windows overlap. Overlapping areas can take additional design into account in the design of components that perform encryption and decryption functions.

As an example, consider FIG. 8. There, the same display screen as the user can see is indicated by the reference numeral 800. A safety window 802 is provided, and it is also shown that the non-safety window 804 overlaps the lower right corner of the safety window to define the overlapping area 806. One problem that may occur in such a situation is as follows. When implemented on the major surface of a video card, area 806 does not contain encrypted data. Now, the adjacent zone corresponding to secure window 802 contains encrypted data. If no adjacencies are made in view of this, the decoder will probably decode the pixel data associated with the overlap region 806. Since this pixel data is not first encrypted, data decryption will provide false data.

Accordingly, embodiments to be described provide a method and system capable of per-pixel functionality. In one example, per pixel security may be provided.

9 shows the pixel data 900 in a graphical representation. In this example, the pixel data includes 32 bits of data. The red (R), green (G), and blue (B) values are each represented by 8 bits. While the illustrated pixel data includes 32 bits per pixel, it should be appreciated that the pixel data may include more or fewer bits per pixel. Note that in this example, 8 bits (designated here as "Auxiliary") remain. To make memory more efficient, the GPU prefers to read data in chunks that are multiples of two. Thus, 24-bit data is read as a 32-bit block, and 8 bits often remain 'unused', but are always read and written as 'used' bits. These auxiliary bits can be reused to specify various auxiliary functions that can be realized in relation to the individual pixels to be provided on the display screen. Examples of auxiliary functions may include, but are not limited to, alpha or transparent information, depth information, area identification information, or color key information (to indicate areas to be replaced with other data).

Other common video formats use 16 bits per pixel instead of 24 or 32 bits per pixel. For example, RGB data may be stored as 5 bits per pixel, leaving one bit unused and used to specify two auxiliary functions.

One way to realize the assist function is to provide a table such as table 902 that references or specifies the assist function. For example, using 8 bits to specify auxiliary functions can specify 256 auxiliary functions. Thus, when the pixel data is processed, the bits of pixel data related to the auxiliary function can be processed to access and realize various auxiliary functions.

10 is a flowchart describing steps of a method according to an embodiment. This method can be realized with any suitable hardware, software, firmware or combination thereof. In this example, this method may be realized, at least in part, by an appropriately configured video card—an example provided above.

Step 1000 provides pixel data with a predetermined number of bits per pixel. In the example of FIG. 9, there are 32 bits per pixel. However, any suitable number of bits per pixel may be used. Step 1002 uses one or more bits of pixel data to specify auxiliary functions. In the example of FIG. 9, 8 bits are used to specify auxiliary functions through the use of a so-called "alpha channel" (fourth 'unused' channel). By using 8 bits of the alpha channel, 256 separate auxiliary functions are specified. Step 1004 processes the bits to access the auxiliary function. This step can be realized by using the value of an auxiliary bit, such as an index into an auxiliary function table, such as table 902 (FIG. 9). The table then refers to the auxiliary functions that can be realized with respect to the pixel data for a particular pixel, for the individual values. Reference numerals in the table 902 may be pointers to software code for implementing the supplemental function, or it may include some or all of the supplementary function. Then step 1006 realizes the auxiliary function.

If function 0 specified a null function, older applications will automatically be compatible with the new way of using the new application.

Fur pixel security

The auxiliary bit of pixel data may be used to provide pixel level decoding. For example, suppose there is a safe area on the major surface used to hold pixel data that is desired to be protected. This pixel data can be encrypted at the pixel level using an encryption key. Now suppose the auxiliary bit of encrypted pixel data specifies a decryption key that can be used to decrypt the pixel data. For example, consider FIG. 11, which shows a per pixel assist function table 1100. Here, each value in the table is associated with a specific key. For example, the value "1" is associated with "key 1", the value "2" is associated with "key 2" and the like. Thus, if the auxiliary pixel data indicates that a particular key is associated with the pixel data, the decryptor can access the associated key and use the key (typically zero) to decrypt the pixel data. The auxiliary pixel data also has a value indicating that the pixel data is not encrypted. In this case, the decrypter simply passes the associated pixel data along the display converter for further processing, allowing unencrypted data from the application to seamlessly integrate with the new way.

The per pixel key table can hold a separate key that can be used to decrypt associated cryptographic pixel data, or it can carry a reference number to a key that can be used to decrypt associated cryptographic pixel data.

The table can also hold secondary (non-secure) secondary related data such as alpha values. This allows for selective reuse of values between security and previous original use of the secondary channel. For example, values 1 through 3 can be used to specify keys (with their own alpha values), but values 0 and values 4 through 255 can still be used to specify their original alpha values.

12 is a flowchart describing steps of a method according to an embodiment. This method can be realized with any suitable hardware, software, firmware or combination thereof. In this example, this method may be realized, at least in part, by an appropriately configured video card—an example provided above.

Step 1200 encrypts the pixel data associated with the individual pixels. Advantageously, encryption can occur at the pixel level. This step can be realized in any suitable manner. For example, safety applications allow pixel data to be encrypted. Alternatively, other processes may be used to encrypt the pixel data, examples of which are given above. Step 1202 associates auxiliary data with pixel data. The auxiliary data specifies one or more decryption keys that can be used to decrypt the pixel data. In some cases, the auxiliary data may be considered to include the pixel data itself when it includes some of the bits (eg, alpha channels) containing the pixel data. Step 1204 receives pixel data that includes some associated auxiliary data. This step can be realized, for example, by a properly configured decoder. Step 1206 determines whether pixel data needs to be decoded. This step can be realized by examining the auxiliary data. If the ancillary data includes a value associated with the decryption function, decryption is required. If decryption is needed, step 1208 uses auxiliary data to access the decryption key for the pixel data. This step can be realized by maintaining a table such as table 1100 and accessing the table to access the appropriate decryption key. Step 1210 then decrypts the pixel data using the decryption key. On the other hand, if step 1206 determines that decryption is not required, then step 1212 does not decrypt the data. This step can be realized by assigning a specific value (eg 0) to the auxiliary data and using that value to indicate that decryption is unnecessary. The data can then be passed along with the display converter for further processing.

One advantage of selective encryption per pixel is that applications can specify non-rectangular encryption regions. Each pixel in the unencrypted rectangular area can be specified by a null encryption function (index 0).

Secondary table

In addition to the tables described above, so-called secondary tables may be provided to contain additional information useful when processing pixel data. As an example, consider FIG. 13 where a secondary pixel table 1300 is shown. In this example, each pixel in the safe area of the major surface may have an associated entry in this table. Therefore, the "pixel" column identifies a particular pixel area of the major surface. In this example, the table 1300 includes a "Process ID" column that can be used to identify a process or entity that "owns" a particular area. This column can be used, for example, to restrict access to specific pixel data to only those entities that need access.

Data integrity

Incidentally or alternatively, table 1300 may be used to verify the integrity of pixel data. For example, it may be calculated as unencrypted pixel data and stored in the “expected hash” column of table 1300. Then, when the pixel data is decoded, for example by a decoder, another hash can be calculated into the decoded pixel data and placed in the "current hash" column. By comparing the expected hash with the current hash, the safety application or decryptor can examine whether the given pixel data has been manipulated or changed. For example, if a defective application successfully manipulates unencrypted pixel data, a hash comparison will indicate that this has occurred. On the other hand, if a defective application manipulates encrypted pixel data, the data will be decrypted differently. Then, when the current hash is calculated on the decrypted data, the current hash will most certainly compare to the unintentionally expected hash. The decryption hardware may notify the application (or agent on behalf of the application) of the data compromise. This notification may occur to the cryptographic entity via a secure channel.

Other techniques can be used to ensure the integrity of the data in the safe area. For example, an attacker may have the per pixel address capability for some reason, and be able to manipulate pixel data (including auxiliary data). To address this situation, for all safe areas, a process can be realized that allows the auxiliary data to estimate the value at which the data will be decrypted. Thus, this can minimize the effect of certain defective applications attacking auxiliary data, for example by changing the data to a value that will not cause the data to be decrypted.

Some advantages of the per pixel assist function (including, but not limited to, per pixel security) are that the associated table (eg, key table) is relatively small and cacheable. In addition, no additional video bandwidth is required when the ancillary data already contains some of the bits assigned to the pixel data (eg alpha channel). In addition, the alpha value can still be used even if the alpha channel is not used to support the assist function. In addition, per pixel per frame key control can take into account complex key transitions. That is, the keys can be cycled per frame, reducing the problem when switching keys while playing video. The technique can also be used with non-RGB data, direct memory copies to the desktop, and video overlays.

Finally, when an area is moved, the secondary encryption index key moves with the video data so that the encryption information is completely synchronized so that no hardware change is required.

conclusion

The various methods and systems described above provide a safe channel for software running on a host computer, as well as addresses, and provide solutions to attack models where defective applications running on the host computer attempt to improperly obtain or otherwise manipulate data. do. With the present technology, video data to be processed and rendered on a user's display can be kept confidential, and in many cases the integrity of the data can be protected.

Although the invention has been described in terms specific to structural features and / or methodological steps, it will be understood that the invention defined in the appended claims is not limited to the specific features and steps described above. Rather, the features and steps specified are disclosed in a preferred form for carrying out the claimed invention.

Claims (59)

Providing encrypted video data on a video card; And Decrypting the encrypted video data at a point in the data process where there is no programmatic access to the decrypted video data Method comprising a. The method of claim 1 wherein said decrypting step is performed prior to providing said decrypted video data to a display converter on a video card. The method of claim 1, wherein said decrypting step is performed prior to providing said decrypted video data to a RAMDAC on a video card. The method of claim 1, wherein said decrypting step is performed by a hardware decryptor on said video card. The method of claim 1, wherein said decrypting step is performed by a decoder between a video card GPU and a RAMDAC on said video card. A set of one or more computer readable instructions, when executed by one or more computers, causing the one or more computers to realize the method of claim 1. Means for providing encrypted video data on a video card; Means for decrypting encrypted video data on the video card; And Means to prohibit software access to decrypted video data System comprising a. 8. The system of claim 7, wherein the means for providing encrypted video data comprises a stream cipher. 8. The system of claim 7, wherein the means for providing encrypted video data comprises a block cipher. 8. The system of claim 7, wherein said decryption means comprises a hardware decryptor on said video card. A graphics processor unit for processing video data to be rendered on the monitor; Memory operably associated with the graphics processor unit to hold data to be processed or processed by the graphics processor unit; A display converter for converting digital data into a signal for use in rendering the data on the monitor; And A decoder configured to decrypt pixel data for providing to the display converter, the decoder being located at a data processing point without access to the program System comprising a. 12. The memory of claim 11, wherein the memory comprises a primary surface containing data to be rendered on a monitor, wherein the primary surface comprises one or more safe areas where encrypted data can be placed. System. 12. The system of claim 11, further comprising a control processor on the video card configured to impart decryption capability to the decryptor. 14. The system of claim 13, wherein the control processor includes a key manager that manages one or more keys that can be provided to a decrypter that decrypts encrypted pixel data. 15. The system of claim 13, further comprising a secure channel for communicatively linking said control processor and said decryptor. 15. The system of claim 13, wherein the control processor comprises a separate integrated circuit on the video card. 12. The system of claim 11, wherein the decoder comprises a separate component on the video card. Processor means on a video card for processing video data to be rendered on the monitor; Memory means on the video card to be processed by the processor means or operably associated with the processor means for retaining the processed data; Converter means on the video card for converting the digital data into a signal for use in rendering the data on the monitor; Decoder means for decoding the pixel data for providing to the converter means; And Means on a video card that prevents one or more software applications from accessing the decrypted pixel data at all System comprising a. Video card; Memory on the video card, the portion of which includes a major surface containing data to be rendered on a monitor; One or more safe areas on the major surface that store encrypted pixel data; And At least one key associated with one or more regions and configured such that the encrypted pixel data can be decrypted System comprising a. 20. The system of claim 19, wherein the individual safety zones correspond to safety windows that can be provided on the monitor. 20. The system of claim 19, wherein the individual safe zones have individual associated keys. 22. The system of claim 21, wherein there are a plurality of safe areas, each with a different key. 20. The system of claim 19, further comprising a decrypter on the video card configured to decrypt the encrypted pixel data using an associated key. 24. The system of claim 23, wherein the decryptor decrypts the encrypted pixel data at processing points where there is no program access to the decrypted pixel data. 24. The system of claim 23, wherein the decoder comprises a hardware decoder. 20. The system of claim 19, wherein the video card is authenticable. 27. The system of claim 26, wherein the video card includes a digital certificate that can be used for authentication. 27. The system of claim 26, wherein the video card is configured to respond to a request for authentication. 20. The system of claim 19, wherein the video card includes a key for encrypting communication with one or more secure applications. Defining one or more safe areas of the major surface in the memory of the video card; Associating at least one key with the one or more safe areas suitable for use in encrypting pixel data stored within the one or more safe areas; Encrypting pixel data with the at least one key; And Providing the encrypted pixel data into the one or more secure areas Method comprising a. 31. The method of claim 30, wherein the one or more safety zones are rectangular in shape. 31. The method of claim 30, wherein the key comprises a key that can be used to encrypt with a stream cipher. 33. The method of claim 30, wherein the key comprises a key that can be used to encrypt with a block cipher. The method of claim 30, The defining step defines a plurality of safety zones; Said associating step associating a different key with each secure zone. 31. The method of claim 30, wherein said encrypting step is performed using a stream cipher limited in scope to one or more secure areas. A set of one or more computer readable instructions, when executed by one or more computers, causing the one or more computers to realize the method of claim 30. Means for defining one or more safe areas of the major surface in the memory of the video card; Means for associating at least one key with the one or more safe areas suitable for use in encrypting pixel data stored within the one or more safe areas; Means for encrypting pixel data with the at least one key; And Means for providing the encrypted pixel data into the one or more secure areas System comprising a. Providing encrypted data within a secure area of the major surface of the video card; Providing a key associated with a secure area that can be used to decrypt the encrypted data; And Using a key to decrypt the encrypted data within the secure area of the major surface Method comprising a. 39. The method of claim 38, wherein using the key occurs at a processing point where there is no program access to the encrypted data. 39. The method of claim 38, wherein providing the key is executed by a control processor on the video card. 39. The method of claim 38, wherein using the key to decrypt the encrypted data is performed by a hardware decryptor on the video card. 39. The method of claim 38, wherein using the key to decrypt the encrypted data is performed by a decryptor on a video card capable of inferring the geometry of the secure area. 39. The method of claim 38, further comprising providing the decrypted data to a display converter for rendering on a display screen. 39. The method of claim 38, wherein there are a plurality of different safe zones, and wherein providing the key provides a key to be associated with each safe zone. 39. The method of claim 38, wherein there are a plurality of different security zones, and wherein providing the keys comprises providing a plurality of keys, each safe zone being associated with a different key. 39. The method of claim 38, wherein using the key to decrypt is performed using a stream cipher. 39. The method of claim 38, wherein using the key to decrypt is performed using a range limited stream cipher. 39. The method of claim 38, wherein using the key to decrypt is performed using block ciphers. A set of one or more computer readable instructions, when executed by one or more computers, causing the one or more computers to realize the method of claim 38. Means for providing encrypted data within a secure area of the major surface of the video card; Means for providing a key associated with a secure area that can be used to decrypt the encrypted data; And Means for using a key to decrypt encrypted data within a secure area of the major surface System comprising a. Providing encrypted data within a safe area of the major surface of the video card, the safe area having an associated appearance; Providing a key associated with a secure area that can be used to decrypt the encrypted data; Notifying the decoder on the video card of the appearance of the safe area; Providing the key to the decryptor; And Decrypting encrypted data in a safe area of the major surface with the decryptor Method comprising a. 52. The method of claim 51, wherein said notifying step is performed in response to a window displayed on a display monitor and associated with said safe area being dragged and dropped to another location on the display monitor. . A set of one or more computer readable instructions that, when executed by one or more computers, cause the one or more computers to realize the method of claim 51. Providing encrypted data within a secure area of the major surface of the video card; Providing a key associated with a secure area that can be used to decrypt the encrypted data; Using a key to decrypt encrypted data within a secure area of the major surface; And Detecting whether any data has changed Method comprising a. 55. The method of claim 54, wherein said detecting step is performed before unencrypted data is rendered on a display monitor. 55. The method of claim 54, wherein said detecting is performed using authentication information associated with said encrypted data. 59. The method of claim 56, wherein the authentication information comprises a safety data format that requires a predetermined pixel to have a predetermined value. 55. The method of claim 54, wherein said detecting is performed using a hash comparison of hashes of unencrypted data. 55. The method of claim 54, wherein the notification returns to the cryptographic entity via a secure channel.