JP2003501915A - System for digitally signing documents - Google Patents

Abstract

SUMMARY OF THE INVENTION A preferred embodiment of the present invention provides a trusted display processor (300) and a trusted display processor (305,315,335,345) that are physically and functionally separate from the processor and memory of the computer system. 260). The trusted display processor (260) is secure against unauthorized modification or viewing of internal data. The trusted display processor (260) is physical to prevent falsification of the document, is tamper-resistant to prevent forgery, and has a cryptographic function to communicate securely at a distance. . The trusted display processor (260) interacts with the user's smart cart (122) to obtain and display the trusted image or seal (1000), generates a digital signature of the hotmap of the document image, and provides a computer system. Controls the video memory (315) so that no other process corrupts the image during the signature process. The user interacts with the trusted display processor via the trusted switch (135).

Description

Detailed Description of the Invention

[0001]

[Technical background]

The present invention relates to an apparatus and method for digitally signing image data, in particular a document, so as to provide the signer with a high degree of confidence that the document the signer wishes to sign is actually the document to be signed.

[0002]

[Background technology]

Conventional prior art mass market computing platforms include well-known personal computers (PCs) and Apple Macintosh (PCs).
There is a proliferation of competing products such as registered trademark) and known palmtop and laptop personal computers. In general, the market for these machines is in two categories:
That is, it is divided into household or consumer and business use. Common requirements for home or consumer computing platforms are relatively high processing power, Internet access capabilities, and multimedia capabilities for handling computer games. For this type of computing platform, M
The Microsoft Windows (R) 95 and 98 operating system products and Intel processors, the so-called WinTel platforms, dominate the market.

On the other hand, for business use, there are a great many computer platforms having manufacturing and sales exclusive rights that can be used for various organizations from micro enterprises to multinational organizations. For many of these applications, the server platform provides centralized data storage and application functionality for multiple client stations. For business use, other important metrics are reliability, remote access capabilities, networking capabilities,
And security functions. For such platforms, UN
In addition to IX (registered trademark), Microsoft Windows NT4.0 (registered trademark) operating system is generally used, and more recently, Linux operating system is also used.

Windows type operating systems allow users to run separate applications in separate windows, the so-called WI
It provides an MP (window, icon, menu, and pointer) interface. This allows the user to interact with the application, typically by using the keyboard to enter data, using the mouse to select options, and controlling the application through dialog boxes and drop-down (or pull-up) menus. To do.

With the increasing number of commercial activities transacted over the Internet, known as “E-commerce”, the prior art has been of great interest in enabling data transactions between computer platforms over the Internet. It was In particular, it has been recognized that it is important for users to enter into a contract over the Internet without the need for a handwritten signed paper contract that is currently standard. However, due to the potential for fraudulent and tampering of electronic data, such proposals were fully automated with a wide range of remote strangers required for a completely transparent and efficient market. Transactions have been held back until now. A fundamental issue for making such transactions is the issue of trust between the user and the computer platform and between the interacting computer platforms.

There are several prior art schemes aimed at increasing the security and credibility of computer platforms. Primarily, these are due to the addition of security features at the application level, in other words, the security features were not originally embedded in the operating system kernel,
It is not built into the basic hardware components of a computing platform. Portable computer devices with smart cards are already on the market, and these smart cards carry user-specific data that is entered into the smart card reader of the computer. At present, such a smart card is at the level of an extension device to a conventional personal computer, and may be incorporated in a well-known computer casing. While these prior art methods improve the security of the computer platform somewhat, the level of security and credibility provided by the prior art methods is:
It appears to be insufficient to popularize automated trading applications between computer platforms. Even greater credit for the underlying technology will be needed before large value transactions in a business are exposed to extensive e-commerce.

Applicant's copending international patent application PCT filed February 15, 2000
/ GB00 / 00528 “Trusted Computing Platform” and PCT / GB00 / 00752 “Smart card User Interface filed on Mar. 3, 2000.
The "for Trusted Computing Platform" is incorporated by reference in its entirety. These consist of a computer platform with "trusted components" in the form of embedded hardware components.
The concept of a "trusted computer platform" is disclosed. Two computer entities, each equipped with such a trusted component, can interact with each other with a high degree of "trust". That is, when the first and second computer entities interact with each other, the security of the interaction is enhanced compared to the case where no trusted component is present. This is for the following reasons.
The user of a computer entity has a high degree of credibility regarding the integrity and confidentiality of its own computer entity and regarding the integrity and confidentiality of computer entities belonging to other parties. • Each entity is credible in that the other entity is in fact the intended entity. If one or both of these entities represent a party to a transaction, eg a data transfer transaction, a third party entity that interacts with this entity by a trusted component built in will not It has a high degree of credibility in terms of representing the other party. The trusted component increases the inherent confidentiality of this entity itself through the verification and monitoring processes performed by the trusted component. The computer entity is more likely to behave as expected.

As mentioned above, the conventional method of signing a document is to physically sign on a medium (usually paper) on which the image of the document is reproduced. This method has the advantage that the signed object is unambiguous and that this signed image is proof of the signed object. However, this does not meet the need for electronic commerce.

Today, it is also possible to digitally sign documents using conventional computer platforms and standard encryption techniques. However, the present inventors recognize that on conventional computer platforms, the electronic translation of a digitally signed document is typically not the same as the document that is visible to the user.
Therefore, the user may inadvertently sign data different from the data intended to be signed. It is also possible in the past to fraudulently claim later that the user intentionally signs the data and that the signed data does not match what is displayed to him by the computer platform. Such problems still exist even when the above-mentioned high-trust platform is used.

Conventional electronic signature methods are well known to those skilled in the art. In essence, digital data is compressed into a digest, for example by using a hash function. This digest is then encrypted by the use of some encryption method initialized with a private key (or simply called "secret"). This is typically done on a computer platform such as a PC. One implementation is to sign the data with a private key that is kept secret in the user's smart card, which is inserted into a smart card reader attached to the computer platform. In the specific case of text documents, the digital data is Micro
It can be a file generated by a word processor application such as Softnotepad, Wordpad, or Word. Normal,
The act of signing means that the signer accepts legal responsibility for the meaning of the signed data.

Hash functions are well known in the prior art and are one-way functions that can produce a relatively small amount of output data from a relatively large amount of input data, such that a slight modification of the input data will cause the output data to change. Will be significantly different. Therefore, the data file to which the hash function is applied produces the first digest data (output of the hash function). Minor changes, such as changing a single bit in the original data file, will produce significantly different outputs if the hash function is reapplied to the changed data file. Thus, when a data file containing several megabytes of data is input to the hash function, a 128-160 bit long digital output results as the resulting digest data. Storing a relatively small amount of digest data generated from a data file in a reserved directory is beneficial because the trusted component will operate with less memory space and less processing power.

During the known signing process, the user typically interprets the document as it is rendered on a computer monitor at normal magnification and resolution. In existing applications, the user's smart card signs data in a form that the application used to create and / or manipulate the document represents the document. However, we believe that the software may send data to a smart card that has a different meaning than what the user knows when the user is browsing the screen. . This possibility may be sufficient reason to introduce doubts about the effectiveness of conventional methods of digitally signing electronic representations of documents that are interpreted by people.

[0013]

DISCLOSURE OF THE INVENTION

The present invention comprises a system and method for enhancing the trust of digitally signed documents that are interpreted by people. The system and method necessarily include a reliable representation of the data that can be used for other purposes.

According to a first aspect, the present invention is a data processing system configured to generate a digital signature representing a document, the main storage means for storing a document to be digitally signed, and the document. At least one including means for generating a graphic signal for displaying
Main processing means for executing one application process, means for generating a request signal for the document to be signed, a frame buffer memory, and digital image data representing the document based on the graphic signal Then, means for storing this digital image data in the frame buffer memory, reading the digital image data from the frame buffer memory, and converting the data into a signal suitable for displaying an actual image, A display system comprising: a means for transferring this signal to display means; and a trusted component including independent processing means operable in response to the request signal to generate a digital signature representing the digital image data. And a data processing system consisting of. Here, the digital signature is generated based on the data used to display the document to the user.

In a preferred embodiment, the trusted component denies any unauthorized application or process write access to at least a portion of the frame buffer memory holding the digital image data of the document. And means for generating a digital signature representing the digital image data while each portion of the frame buffer memory is inaccessible for writing data.

In a preferred embodiment, the data processing system further comprises a removable token comprising processing means for receiving digital image data or a representation thereof from the frame buffer memory and generating a respective digital signature.
As a convenient example, a removable token is a properly programmed smart card.

In a preferred embodiment, the trusted component provides a means for obtaining and / or producing trusted image data and a display for highlighting a document image displayed using the trusted image data. And means for controlling the system. This means provides the user with visual feedback that the trusted component is under control of its operation.

The trusted image data may include pixmap data representing a trusted image or instructions for forming a trusted image. Preferably, the trusted component includes means for obtaining and / or generating trusted image data from the removable token. The trusted component preferably further comprises means for controlling the display system to display the message to the user.

In a preferred embodiment, the data processing system further comprises trusted input means by which the user can securely respond to the message. The trusted input means may comprise a switch connected to the trusted component via a secure communication path.

In a preferred embodiment, the trusted component and the secure token are
Perform a mutual authentication process prior to further interaction.

In the preferred embodiment, the trusted component forms part of a display system. For example, the display system may have a trusted component physically and functionally located between the main processing means and the frame buffer memory such that only the main processing means can indirectly access the frame buffer memory through the functionality of the trusted component. Can be configured to Preferably, the trusted component further comprises means for generating data summarizing the digital signature operation.

Other aspects and embodiments of the invention will be apparent from the following description, claims and drawings.

[0023]

BEST MODE FOR IMPLEMENTING THE INVENTION AND INDUSTRIAL APPLICATION

A preferred embodiment is the applicant's copending European patent application No. 99301.
Utilize a trusted component that most conveniently uses some of the features of the "trusted component" described in 100.6. In this application, the trusted component measures the integrity metric of the host computer and compares it with the true value of the integrity metric to notify the user or other host computers of the integrity of the host computer. A hardware device with or without a programmed processor. The key commonalities between this trusted component and the trusted component in the preferred embodiment herein are: • Both use an encryption process, but preferably no external interface is provided for the encryption process. Both have both tamper proof and tamper detection capabilities so that these actions cannot be overturned without the knowledge of a legitimate user. • Both preferably consist of one physical hardware component that is physically and functionally independent of the host computer to which it is attached. Such independence is achieved by the trusted component having its own processing power and memory.

Techniques related to tampering prevention are well known to those skilled in the security arts. These techniques include methods that are not affected by tampering (appropriate encapsulation of high-trust devices, etc.), methods for detecting tampering (out-of-specification voltages, X-rays, physics in the casing of high-trust devices, etc.). Loss of physical integrity, etc.), and methods of erasing data if tampering is detected. Further discussion of suitable techniques can be found at http://www.cl.cam.ac.uk/~mgk25/tamper.html. It will be appreciated that tamper proofing is the most desirable feature of the present invention, but it is beyond the scope of the present invention as it is not included in the normal operation of the present invention.

In this description, the term "trusted" when used in connection with a physical or logical component, operation, or process is behavior that is predictable in various operating environments, and It has the meaning of being highly resistant to external factors such as destructive application software, viruses, and interference or destruction due to physical interference.

As used herein, the term “host computer” refers to data that has at least one data processor, at least one form of data storage, and some form of communication capability for interacting with external entities. The term processing device is used to refer to this communication by an external entity such as an external device, a user and / or another computer, either locally or via the Internet. The term "host computer system" refers to the host computer itself, as well as a keyboard, mouse, attached to the host computer,
Includes standard external devices such as VDUs.

As used herein, the term “document” includes any collection of data that can be visualized using a host computer system. Usually, the document is a text document such as a contract. However, the document may include graphics or pictures in addition to or in place of text. In general, a document may contain a single page or multiple pages.

The term “pixmap” as used herein is broadly used to include data defining either a monochrome image or a color (or grayscale) image. The term "bitmap" is only associated with monochrome images and is set to 1 or 0, for example depending on whether the pixel is "on" or "off". In contrast, “pixmap” is a more generic term that includes both monochromatic and color images, where a color image requires a maximum of 24 bits, a single pixel tint, saturation. , And more bits are needed to define the strength.

As will be made clear below, the trusted component according to the preferred embodiments herein provides a secure user interface, and in particular controls at least some of the display functions of the host computer. The trusted component herein may or may not obtain an integrity metric by the trusted component in Applicants' co-pending patent application, however, the integrity metric acquisition is herein Not considered.

The preferred embodiment is essentially such that the user can use the private key of the user's smart card or some other form of secure token, such as a cryptographic coprocessor, to digitally document the user stored on the host computer. Allows you to sign. The signature is the document being viewed on the screen that is actually signed by the smart card,
This is done by the trusted display processor (ie, trusted component) of the host computer in the context of providing the user with a high degree of trust. In particular, smart cards contain highly trusted image data or "stickers". This trusted image data or "sticker" is passed to the host computer via a secure communication path during the signing procedure and displayed by the trusted component. These are partial representations of the trusted image and are typically unique to the user, providing the user with confidence that the trusted component controls the signature operation. Further, in this preferred embodiment, the host computer is provided with a trusted input device that is directly connected to the trusted display processor so that the user is not disturbed by other functions of the host computer. Can interact with the host computer.

More specifically, a trusted display processor or display device having a similar effect is associated not only with data that can be operated by the standard software of the host computer, but also with video data that is in the stage of video processing. . This allows the trusted display processor to display data on the display surface without interference or tampering with the software of the host computer. Thus, the trusted display processor can identify which image is currently displayed to the user. This is used to clearly identify the image (pixmap) that the user has signed. A side effect of this is that the trusted display processor can display all data, including integrity metrics of conventional patent applications, user status messages, prompts, etc., on the display screen with high confidence.

FIG. 1 illustrates a host computer system according to a preferred embodiment,
In this figure, the host computer is a personal computer or PC running under the Windows NT® operating system.
According to FIG. 1, the host computer 100 includes a visual display unit (VDU) 10
5, keyboard 110, mouse 115, smart card reader 120, and local area network (LAN) 125, which in turn is connected to the Internet 130. Although the smart card reader is a separate unit herein, it may be integrated to form part of a keyboard.
In addition, the host computer comprises a trusted input device. In this figure, the high reliability switch 135 is integrated with the keyboard. VDU, keyboard, mouse,
And trusted switches are considered as human / computer interfaces (HCI) of the host computer. In particular, trusted switches and displays, when operating under trusted control, are considered "trusted user interfaces", as described below. FIG. 1 also illustrates a smart card 122 for use in this embodiment described below.

FIG. 2 shows the hardware architecture of the host computer of FIG. 1, in which the host computer 100 includes a RAM 205 and a ROM 21.
It is composed of a central processing unit (CPU) 200 or a main processing unit connected to a main storage unit of 0, and all of these components are mounted on a motherboard 215 on the host computer 100. In this example, the CPU is Penti
um (registered trademark) processor. The CPU is a PCI (Peripheral Component I)
via a bridge 220 to a PCI bus 225 for attaching other major components of the host computer 100. PCI bus 225 includes appropriate control, address, and data portions, which are not described in detail herein. Pent beyond the scope of the present invention
For a detailed description of the ium processor and PCI architecture, see Hans-Pet
ed Messmer book "The Indispensable PC Hardware Handbook" 3rd edition (Ad
See ISBN 0-201-40399-4), published by dison-Wesley.
Of course, the present embodiment is by no means limited to implementations using the Pentium processor, Windows® operating system, or PCI bus.

The other main components of the host computer 100 attached to the PCI bus 225 are the hard disk drive 24 via the SCSI bus 235.
0 and a SCSI (Small computer sys) connected to the CD-ROM drive 245.
tem interface) adapter, a LAN (local area network) adapter 250 for connecting the host computer 100 to the LAN 125, an IO (input / output) device 225 for attaching the keyboard 110, the mouse 115, and the smart card reader 120, A trusted display processor 260 to enable the computer 100 to communicate with other host computers (not shown), such as a file server, print server, or email server, and the Internet 130 via the LAN adapter. Has become. This trusted display processor handles all the standard display functions plus a number of additional tasks, as described below. This standard display function is compatible with any standard host computer 100.
Is a function normally thought to have, and when it comes to a PC operating under the Windows NT (registered trademark) operating system, it is a function for displaying an image related to the operating system or application software. Note that the keyboard 110 is not only directly connected to the trusted display processor 260, but is also connected to the IO device 255.

The LAN adapter 250 and SCSI adapter 230 may be plug-in types, although all major components, particularly the trusted display processor 260, are preferably provided together on the motherboard 215 of the host computer 100. .

FIG. 3 illustrates the preferred physical architecture of the trusted display processor 260. According to a preferred embodiment, the trusted display processor 260 is a hardware component having the characteristics of a trusted component, the standard display functionality of the display processor and additional non-standard functionality for generating digital signatures. And a trusted user interface. Those of ordinary skill in the art will appreciate that these functions may alternatively be physically separated into two or more separate physical components. However, upon reading the description below, it will be seen that integrating all functions into a single trusted component provides the most sophisticated and useful solution.

According to FIG. 3, the trusted processor 260 comprises a microcontroller 300 and a non-volatile memory 305, for example a flash memory, which contains respective control program instructions (firmware) for controlling the operation of the microcontroller 300 ( Alternatively, the trusted display processor 260 may be an ASIC (application specific I
C), which typically provides high performance and cost efficiency due to high volume production, but is more expensive and less flexible to develop), and connects the trusted processor 260 to the PCI bus. As will be described later, the CPU 20
Receiving image data (ie graphics primitives) from 0,
Interface 3 for receiving highly trusted image data from smart card 122
10 and at least one complete image frame (12 supporting up to 16.7 million colors)
With a screen resolution of 80 × 768, a typical frame buffer memory 31
Sufficient VRAM (video RAM) to store 5 to 1 megabytes
) And a video DAC (digital / analog converter) for converting the pixmap data into an analog signal for operating the (analog) VDU connected to the video DAC via the video interface 325. 320, an interface 330 for receiving signals directly from the trusted switch 135, state information, in particular the received cryptographic key, and the microcontroller 30
Non-volatile memory 335 (eg, DRAM (Dynamic RAM) or more expensive SRAM (Static RAM)) to provide a working area for zero, and a cryptographic identification function for the trusted display processor 260, as described in more detail below. ,
And hardware cryptographic accelerators and / or software cryptographic accelerators provided to provide authentication, integrity, authenticity, and protection from replay attacks, creation of digital signatures, and use of digital certificates. The encryption processor 340, the identifier I _DP of the trusted display processor 260 (eg, a symbol of a simple text string), the secret key S _DP of the trusted display processor 260, and the public key signed by the trusted display processor 260- A private key pair and a confidential public key-VeriSign, which is associated with the private key pair and which contains the corresponding public key of the trusted display processor 260.
Inc. And a non-volatile memory 345 that stores a certificate Cert _DP signed and provided by a third-party credit institution such as a flash memory.

Certificates typically include such information, but not the public key of the certificate authority (CA).
This public key is typically made available using a "public key infrastructure" (PKI). The operation of PKIs is well known to those of ordinary skill in the security arts.

The certificate Cert _DP uses a trusted display processor 260 in a manner that allows a third party to trust the origin of the public key and that this public key is part of a legitimate public-private key pair. It is used to provide the public key of the. Here, the third party does not need to know in advance or obtain the public key of the trusted display processor 260 in advance.

The trusted display processor 260 provides its identification and trusted process to the host computer, and the trusted display processor has these characteristics through tamper resistance, anti-counterfeiting and anti-counterfeiting. . Only selected entities with the appropriate authentication mechanism can affect the processes running within this trusted display processor 260. Neither the normal user of the host computer nor any normal user or any normal entity connected to the host computer via the network can access or interfere with the processes executing within the trusted display processor 260. High credit display processor 26
0 has the property of "impermeable".

First, the high-credit display processor 260 is installed on the motherboard of the host computer 100 and then initialized by its secure communication with the high-credit display processor 260 using its identification, private key, and certificate. R. Writing the certificate to the trusted display processor 260 is similar to initializing the smart card by writing the private key to the smart card. The secure communication is ensured by a "master key" known only to trusted third parties (and the manufacturer of the host computer), which master key is written to the trusted display processor 260 during manufacture. , To enable writing of data to the trusted display processor 260. Therefore, it is not possible to write data to the trusted display processor 260 without knowing the master key.

As is apparent from FIG. 3, the frame buffer memory 315 can be accessed only by the high-credit display processor 260 itself, and cannot be accessed by the CPU 200. This is an important feature of the preferred embodiment because it is essential that the CPU 200, and more importantly the destructive application programs and viruses, not be able to modify the pixmap during trusted operation. Of course, even if the CPU 200 has direct access to the frame buffer memory 315, the trusted display processor 260 is configured to have absolute control when the CPU 200 has access to the frame buffer memory 315. If so, it would be possible to provide the same level of security. Obviously, the latter method seems to be more difficult to implement.

Next, as a background of the story, the graphics primitives are stored in the host computer 1.
A typical process generated by 00 will be described. First, an application program that wants to display a specific image makes an appropriate call to the operating system via a graphical API (application programming interface). For the purpose of displaying images, APIs typically provide application programs with a standard interface to access specific underlying functions, such as those provided by Windows NT. . The API call causes the operating system to call each graphics driver library routine, resulting in a graphics primitive specific to the display processor, in this example the trusted display processor 260. These graphics primitives will eventually
Passed by U200 to trusted display processor 260. Examples of graphics primitives may include "draw a line from point x to point y with thickness z" or "fill the area surrounded by points w, x, y, z with color a".

The control program of the microcontroller 300 provides standard display functions for controlling the microcontroller to process the received graphics primitives. Specifically, it does the following: Receives a graphics primitive from CPU 200 and processes it to form pixmap data that directly represents the image displayed on the screen of VDU 105. Here, the pixmap data generally has intensity values for each of the red, green, and blue dots of the addressable pixels on the screen of the VDU 105; this pixmap data is stored in the frame buffer memory 315; Periodically, for example, 60 times per second, the pixmap data is read from the frame buffer memory 315,
A video DAC is used to convert this data to an analog signal and this analog signal is sent to the VDU 105 to display the requested image on the screen.

In addition to the standard display function, the control program has a function of combining display image data tricked from the CPU 200 with high-credit image data to form a single pixmap. The control program also manages interaction with the cryptographic processor and trusted switch 135.

The trusted display processor 260 forms a part of the entire “display system” of the host computer 100, the other part is the display function of the normal operating system, and the other part depends on the application program. It is "callable" and has access to the graphics processor and standard display capabilities of the VDU 105. In other words, the “display system” of host computer 100 includes any hardware or functionality that is involved in displaying images.

As already mentioned, this embodiment relies on the interaction between the trusted display processor 260 and the user's smart card 122. A smart card processing engine suitable for use in accordance with the preferred embodiment is shown in FIG. The processing engine is a processor 40 for performing standard encryption and decryption functions to assist in verifying digital signatures of data and signatures received elsewhere.
Equipped with 0. In the present embodiment, this processor 400 has a built-in operating system and is ISO7816-3, 4, T = 0, T = 1, and T = 1.
It is an 8-bit microcontroller configured to communicate with the outside world via an asynchronous protocol defined in the 4 standards. The smart card also includes non-volatile memory 420, such as flash memory, which is provided by the identifier I _SC of the smart card 122, the private key S _SC used to digitally sign the data, and a third party credit authority. And includes a certificate Cert _SC that binds the smart card to a public-private key pair and contains the corresponding public key of the smart card 122 (of the same nature as the certificate Cert _DP of the trusted display processor 260). In addition, the smart card includes "seal" data SEAL in non-volatile memory 420, which, as will be described in more detail below, indicates that the process is operating safely with the user's smart card. Graphically represented by trusted display processor 260 for display to the user. In the preferred embodiment, the seal data SEAL is in the form of a pixmap of the image originally selected by the user as a unique identifier, eg, the user's own image, and is loaded onto the smart card 122 using known techniques. The processor 400 accesses the volatile memory 430, eg RAM, to store state information (such as received keys) and to provide a work area for the processor 400, and to communicate with a smart card reader, Access interface 440, eg, electrical contacts.

Sticker images can use a relatively large amount of memory when stored as pixmaps. This is a smart card with a relatively limited storage capacity 1
In situations where images need to be stored at 22, this can clearly be a drawback. Memory requirements can be reduced by several different technologies. For example, the seal image may include: an image that has been compressed for decompression by the trusted display processor 260; a thumbnail image that forms the basis of the repeating mosaic generated by the trusted display processor 260; a trusted display. A normally compressed image, such as a set of alphanumeric characters that processor 260 can display as a single large image, or that can be used as a thumbnail image as described above. In any alternative, the seal data itself may be in encrypted form, requiring the trusted display processor 260 to decrypt the data before it can be displayed. Alternatively, the seal data may be an encrypted index identifying one of many images that may be stored on the host computer 100 or network server. In this case, the index is captured by the trusted display processor 260 via a secure channel and decrypted to obtain and display the correct image. Further, the seal data may be instructed (eg, by a properly programmed trusted display processor 260) to generate an image.
PostScript® instructions) may also be included.

FIG. 5 shows the host computer 100 in a situation where a high-credit signature operation is performed.
3 illustrates the logical relationship between the trusted display processor 260 and the functionality of the smart card 122. In order to clearly express the processes involved in the trusted signature operation, apart from the logical separation into the host computer 100, each function of the display processor 260 or the smart card 122 is expressed independently of the physical architecture. . Furthermore, the "standard display function" is separated from the high-credit function by the line xy,
The features to the left of this line clearly indicate that they are highly trusted features. In the figure,
Features are represented by ellipses, and the "immutable" data on which they act (including the document image being signed) is indicated by a box. Dynamic data, such as state data or received cryptographic keys, are not shown simply for the sake of clarity. Arrows between ellipses and between ellipses and boxes respectively represent logical communication paths.

According to FIG. 5, the host computer 100 may include: an application process 500 requesting to sign a document, eg a word processor process; document data 505; operating system process 510; a display call from the application process 500. API 511 process for receiving the input; keyboard process 513 for providing input from the keyboard 110 to the application process 500; mouse 115 to the application process 5
Mouse process 514 for providing input to 00; Graphics primitive process 515 for generating graphics primitives based on calls received from the application process via API process 511.
API process 511, keyboard process 513, mouse process 514, and graphics primitive process 515 are built on top of operating system process 510 and communicate with application processes via operating system process 510.

The remaining functions of host computer 100 are those provided by trusted display processor 260. These functions include: for coordinating all the operations of the trusted display processor 260 and for receiving graphics primitives from the graphics primitive process and for receiving signature requests from the application process 500. Control process 520; Summarization process 522 for generating a signed digest representing the document signing procedure in response to a request from control process 520; Signature request process 523 for obtaining the digital signature of the pixmap from smart card 122. A seal process 524 for obtaining seal data 540 from the smart card 122; a summary process 522,
A smart card process 525 that interacts with the smart card 122 to perform the challenge / response and data signing tasks requested by the signature request process 523 and the seal process; read the stored pixmap data 531 and use this pixmap. If requested by the signature request process 523 to pass data to the signature request process 523, pixmap read process 526 for doing this; pixmap data based on the graphics primitive and seal image data received from the control process 520. Pixmap generation process 527 for generating 531; Screen refresh process 528 for reading pixmap data, converting this to an analog signal, and transmitting the converted signal to VDU 105; High credit switch process 529 for credit switch 135 monitors whether or not activated by the user. Smart card process 525
Is the identification data I _DP of the trusted display processor, the private key S _DP data, and the certificate C.
The ERT _DP data 530 can be accessed. In effect, the smart card and trusted display processor interact with each other via standard operating system calls.

The smart card 122 includes the seal data 540 and the high-credit display processor 26.
And a display processor process 542 for interacting with 0 to perform interrogation / response and data signing tasks, and smart card identification data I _SC , smart card private key data S _SC , smart card certificate data Cert _SC 543.

A preferred process for signing a document using the arrangement shown in FIGS. 1-5 will now be described with reference to the flow chart of FIG. First, in step 600, the user controls the application process 500 to initiate a "signature request" for digitally signing a document. The application process 500 can be realized by a dedicated software program or addition to a standard word processor package such as Microsoft Word, for example, a macro or the like. In either case, the signature request or application process 50
Neither need be zero. When the user initiates a signature request, the user also specifies the document to sign if the entire screen is not already filled with the signed document. For example, the document to be signed may be displayed in a part of the entire screen area or may be displayed in a specific window. Selecting a specific area on the screen is a simple task, and there are several ways (using the WIMP environment),
This can be accomplished, for example, by drawing a user-defined box that defines an area, or by simply specifying the coordinates.

Next, in step 602, the application process 500 calls the control process 520 to sign the image being displayed (in a defined area or window) on the screen, and the control process 520 makes this call. To receive. At the same time, although not shown, control process 520 receives any graphics primitive from the graphics primitive process and forwards it to pixmap generation process 527. The call from the application process 500 to sign the document is made with the coordinates (a, b, c) of the document edge.
, D). Keep in mind that sending these coordinates allows you to widely sign the entire surface of the screen, some complete window, or any part of the screen. The application process 500 then waits for the control process 520 to return the image signature.

In response to the signature request, in step 604, the control process 520 “statically” forces the image to be signed from the time of the request until the process is complete.
To Here, “static” means that the document image is a highly reliable display processor 2
It means that it cannot be changed except for 60. As a result, the user can be sure that what he / she sees is the signature at all times during the signature process. In this embodiment, control process 520 achieves a "static" display by "don't accept" or process any more graphics primitives. In some circumstances, the graphics primitive process (or its equivalent) may "buffer" graphics primitives until the control process 520 is ready to receive additional graphics primitives. In other circumstances, the graphics primitives of the image being signed may simply be lost. If the document image fills the entire screen, making the image static is simply the case where no graphics primitives are processed. However, if the image to be signed forms only part of the full screen, eg, a window, the control process 520 determines whether the received graphics primitives affect the “static” region and rejects those that affect. There is a need. In this way, the pixmap of the static document image in frame buffer memory 315 is provided by any instruction from the graphics primitive process or any other process executing on CPU 200 while the document image is static. It is kept so that it does not change.

Once the document image is static, at step 606, FIG.
As described in more detail below with reference to c, control process 520 modifies the pixmap to highlight the document to be signed by coordinates (a, b, c, d) provided by application process 500. ) Is sent to the pixmap generation process 527. Next, in step 608, if the smart card process 525 determines that the smart card 122 has not yet been inserted into the smart card reader 120, the control process 520 prompts the user to do so. Instructs the pixmap generation process to display a graphic message asking to insert 122. A countdown timer COUNT of 10 seconds is added to this message. If the countdown timer expires (ie, reaches zero) as a result of not receiving the smart card 122, then in step 614 the control process cancels the signing operation and returns an exception signal to the application process 500. In response to this,
In step 616, application process 500 displays the appropriate user message. If the smart card 122 is inserted in time, or if it was already present, the process continues.

Next, in step 618, the control process 520 causes the sealing process 524 to proceed.
, And the seal process 524 calls the smart card process 525 to obtain the seal data 540 from the smart card 122. Additionally, the control process 520 may call the pixmap generation process 527 to display another message to the user indicating that it is attempting to recover the seal data 540. In steps 618 and 620, the smart card process 525 of the trusted display processor 260 and the display processor process 542 of the smart card 122 interact using well-known “challenge / response” techniques to perform mutual authentication and seal data. Return 540 from smart card to control process 520.
Next, details of the mutual authentication process and the delivery of the seal data 540 will be described with reference to FIG. 7.

According to FIG. 7, the smart card process 525 uses the seal data SEAL 54.
A request REQ1 for returning 0 is sent to the smart card 122. The display processor process 542 generates nonce R ₁ and sends it on the call to the smart card process 525. The smart card process 525 generates a nonce R ₂ , concatenates it with the nonce R ₁ and signs the concatenation R ₁ ‖ R ₂ with the smart card private key to generate the signature sS _DP (R ₁ ‖ R ₂ ). , Concatenation R ₁ ‖ R ₂ , signature sS _DP (R ₁ ‖ R ₂ ), and certificate Cert _DP are returned to the display processor process 542 of the smart card 122. The display processor process 542 extracts the public key of the trusted display processor 260 from the certificate Cert _{DP and} sends it to the nonce R ₁ and signature s.
Using the _{S DP (R 1 ‖R 2)} , connecting R ₁ and authenticated by comparing it with ‖R _2, it seals the request is coming from a desired high credit display processor 260, and the high credit display processor 260 Make sure you are online. Nonces are used to protect users from fraud with genuine signatures (called a "replay attack") caused by an old and repetitive untrustworthy process.

The display processor process 542 of the smart card 122 then concatenates R ₂ with the seal data SEAL 540 of the smart card and signs the concatenated R ₂ ‖ SEAL with the secret key S _SC to sign sS _SC ( R ₂ ‖SEAL) is generated, the seal data SEAL 540 is encrypted by using the secret key S _SC , and the encrypted seal data 540 s
It generates S _SC (SEAL), nonce R _2, encrypted seal data sS _SC (SEAL
), The signature sS _SC (R ₂ ∥SEAL), and the smart card certificate Cert _SC to the smart card process 525 of the trusted display processor 260. The smart card process 525 extracts the smart card public key from the certificate Cert _SC and uses it to verify the nonce R ₂ and the signature sS _SC (R ₂ ‖ SEAL),
Encrypted seal data 540sS _SC (SEAL) to seal data SEAL540
And the seal data SEAL540 is finally converted into the seal process 52.
4 to the control process 520.

Returning to FIG. 6, in step 622, the control process 520 causes the seal data S
Upon receipt of the EAL 540, this data is forwarded to the pixmap generation process 527 to generate a sticker image and use it to highlight the document to be signed, as described below with reference to Figure 10d. Instruct generation process 527. Then, in step 624, the control process 520 directs the pixmap generation process to display a message asking the user if he wants to continue the signing operation. This message contains a 10 second countdown timer COU
NT is added. If, in step 626, the countdown timer expires as a result of not receiving a response from the user, then in step 628 the control process cancels the signing operation and returns an exception signal to the application process 500. In response, application process 500 displays an appropriate user message at step 629. In step 630, the user
If it responds explicitly by activating the trusted switch 135 within the 10 second time limit, the process continues. Persistence authorization is alternatively not limited to using the trusted switch 135, if appropriate levels of authentication are used, but also via untrusted channels and using appropriate software routines. Can also be provided by. Alternatively, the mere existence of a trusted smart card may be considered sufficient authentication for the signature. Such an alternative is a matter of security policy.

Next, in step 632, the control process 520 instructs the signature request process 523 to request the signature of the document image, and the signature request process 523 calls the pixmap process 526 to print the pix of the document to be signed. Requesting to return a digest of map data, the pixmap read process 526 reads each pixmap data, generates a pixmap data digest D _PIX using a hash algorithm, and returns this digest to the signature request process 523. Further, the pixmap read process 526 produces a "display format data" FD. The FD contains the information needed to reconstruct a text-based document from the pixmap data later (the FD is not required, as the document text may not need to be reconstructed). Is similarly returned to the signature request process 523. For example, this display format data FD includes “1024 ×
768 ", etc., the number of pixels on the screen and their allocation, the font type and size used for the text of the document (if the document is text based), etc. (at least some of this information is replaced, as described below). Or in addition, may be included in the "summary" of the document). In steps 634 and 636, the signature request process 523 interacts with the display processor process 542 of the smart card 122 using well known challenge / response processes to generate individual signatures for the document. This will be described in detail next with reference to the flow chart of FIG.

In FIG. 8, the smart card process 525 makes a request REQ 2 to the smart card 122 to generate the signature of the digest D _PIX and the display format data FD. The display processor process 542 of the smart card 122 generates the nonce R ₃ and calls for the smart card process 5 to send the digest D _PIX and the display format data FD back.
Respond by sending to 25. The smart card process 525 concatenates the digest D _PIX with the display format data FD and the nonce R ₃ and signs this concatenation D _PIX ‖FD‖R ₃ to generate the signature sS _DP (D _PIX ‖FD‖R ₃ ). . The smart card process 525 then processes the concatenated D _PIX ‖FD‖R ₃ and each signature s.
Display processor processes 5 S _DP (D _PIX ‖FD‖R ₃₎ a smart card 122
42 to 42. The display processor process 542 uses the public key of the trusted display processor (which it has already received in the exchange of the seal data 540), the signature of the trusted display processor sS _DP (D _PIX ‖FD‖R ₃ ) and the nonce R. Validate ₃ ,
Prove that this digest is the digest of the current image. The display processor process 542 uses the private key to sign the digest of the pixmap D _PIX and the display format data FD, and two signatures sS _SC (D _PIX ) and sS _SC.
(FD) is generated respectively. The smart card display processor process 542 then returns the signed digest sS _SC (D _PIX ) and the signed display format data sS _SC (FD) to the smart card process 525 of the trusted display processor 260. The smart card process 525 then verifies this digest D _PIX and display format data FD with the smart card's public key (which already exists as a result of the exchange of the seal data 540) and verifies the smart card's signature, Prove that your smart card is still online.

Returning to FIG. 6, in step 638, smart card process 525 of trusted display processor 260 causes pixmap PIX, smartcard pixmap digest signed sS _SC (D _PIX ), and display format data. Of the signed sS _SC (FD) to form an individual signature _PIX ‖s S _SC (D _PIX ) ‖s S _SC (FD) of the image, which is passed to the control process 520 via the signature request process 523. return. Control process 520 returns this individual signature to application process 500. The application process 500 then responds by storing this individual signature at step 640 and making a further call to the control process 520 to "summarize" the signature operation at step 642. The purpose of the summary is to complete the signature, for which
Description will be made with reference to the flowchart of FIG. 9 and the example of the following summary.

In step 644, the control process 520, in addition to the number of images (two in the above summary example), the individual signatures of the images (6th and 10th lines in the example), a label identifying the trusted display device ( A digest process 522 to generate the entire digest message, including the first line of the example), the current time and date (the second line of the example), and the signed digest of this summary itself (the 14th line of the example). Call. For each image, this summary includes the image size in pixel representation (eg, 560 × 414 for image 1), the offset from the screen origin in pixel representation (eg, 187,190 for image 1), and the pixel representation. Display resolution (for example, 1024 × 768 in the case of image 1) is also included.

Next, in step 646, the digest process 522 generates a digest digest D _SUM and uses the interrogation / response process to interact with the smart card 122 to generate a signature for the digest digest D _SUM. , Call smart card process 525 of trusted display processor 260. For this,
Next, description will be made with reference to FIG.

In FIG. 9, the smart card process 525 uses the digest digest D _SUM.
Request REQ ₃ to the smart card 122 to generate the signature of The smart card display processor process 542 generates nonce R ₄ and sends it in the call to have the digest digest D _SUM returned. Smart card process 525, a digest D _SUM linked to nonce R _4, to produce the sign this connection D _SUM ‖R ₄ signature _{sS DP (D SUM ‖R 4)} . The smart card process 525 of the trusted display processor 260 then sends the concatenation D _SUM ∥R ₄ and each signature sS _DP (D _SUM ∥R ₄ ) to the display processor process 542. The display processor process 542 then verifies the trusted display processor's signature and nonce R ₄ with the trusted display processor's public key (already present from the exchange of seal data 540), and this summary is the current summary. Prove that there is. The display processor process 542 then signs the digest digest D _SUM with the private key and sends the signed digest sS _SC (D _SUM ) to the smart card process 525. The smart card process 525 of the trusted display processor 260 verifies this digest with the smart card's public key and verifies the smart card's signature to prove that the smart card is still online.

Returning to FIG. 6, in step 652, the smart card process 525 causes the digest process 522 to concatenate the digest of the signed digest sS _SC (D _SUM ) to the digest SUM (resultantly, concatenated SUM∥sS). Returns _SC and (D _SUM) to form a) to a control process 520, the control process 520 returns this summary SUM‖sS _SC (D _{SU M)} to the application process 500. In step 654, the application process 500 receives this summary.

For storage or transmission to other entities, this individual signature and summary
It may also be used by the application process 500, or any other process running on the host computer 100 in various ways other than as described in the present invention as a method of certifying a contract.

Finally, in step 656, the control process 520 unquiesces the screen by resuming reception and processing of graphics primitives associated with the document image, thereby actually controlling the screen to the application. Return to application process 500 or other application software. Alternatively, control may not be returned to application process 500 until the user typically activates trusted switch 135 again in response to another user message, in which case There is no timeout period.
This allows the user more time to review the static document image before the host computer returns to standard or untrusted operation.

To verify the signed document, the individual signature _PIX ‖sS _SC (D _PIX ) ‖
Both sS _SC (FD) and summary _SUM ∥sS _SC (D _SUM ) must be verified. Such verification methods are well known to those skilled in the field of security. For example, the signature sS _SC (D _PIX ) for the digest of the pixmap is verified using the public key. This public key is publicly available and is preferably contained in a digital certificate Cert _SC supplied by a Certificate Authority (CA). The verified digest is then compared to the value obtained by recalculating the digest from the pixmap. In this case, the digest is generated using a standard well-known defined hash function. If this match is an exact match, the signature verification is complete. Other signatures, including abstracts, are verified in a similar manner.

The preferred way to allow a person to verify how a signed document is rendered is to transform the pixmap back into the image. To do this, the application, in fact the trusted display processor 260, must load the pixmap data PIX into the frame buffer memory 315 of each host computer 100. This allows a person to view documents that have already been signed by the signer.

The step of highlighting the document to be signed will now be described with reference to FIGS. In the preferred embodiment, the seal data SEAL comprises a pixmap of high confidence images. For example, as shown in FIG. 10 a, the pixmap of seal data 540 defines a “smiley face” 1000. FIG. 10b shows an image 1005 of the exemplary document to be signed Doc1 in a window 1010 of the screen (not shown). The first step in highlighting is after the image is static, but before the seal data is received,
The trusted display processor 260 highlights the document to be signed by adding a frame 1020 around the document image 1005, as shown in FIG. 10c. Also, if there is no smart card 122, this also prompts the user to insert the smart card 103, as shown in FIG. 10c.
0 is displayed with the 10 second countdown timer 1035. Next, when the pixmap image of the smiley face is acquired from the smart card 122, as shown in FIG.
As shown at 0d, trusted display processor 260 decorates frame 1040 with multiple instances 1045 or mosaics of smiley faces. Further, as shown in FIG. 10d, the trusted display processor 260 generates a further user message 1050 with a 10 second countdown timer 1055 asking the user if they want to continue the signing process. Decorated frame 1
040 indicates to the user that the proper static image area has been selected and gives the user a high level of confidence that the trusted display processor 260 is completely in control of its signing process. Also, the presence of the user's own sticker image allows the message to be displayed by the trusted display processor 26 rather than from some other (possibly destructive) software application or hardware device.
Provide users with the credibility that they are from zero.

10e and 10g show an alternative to the visual effect of the "frame" shown in FIGS. 10c and 10d. In FIG. 10e, four single seal images 1060 have been placed at the corners of the static document image using the coordinates provided by the application process 500 to define static image areas. In FIG. 10f,
This static image is defined by changing the background to show a single sticker image. In FIG. 10g, the static image is defined by changing the background to show a mosaic of the sticker image. One of ordinary skill in the art, in light of the present description, will be able to conceive of other visual effects capable of highlighting static images. Further, it may be desirable to include additional status messages during the signing operation, eg, “currently acquiring seal data 540 ...”, “Currently creating document signature ...”.

It will be appreciated that the trusted display processor 260 is required to be able to display sticker images and messages in the correct locations on the screen. The seal image and message image appear during the signing process and then disappear,
Obviously temporary. It is well known to cover a first image with a second image, thereby hiding a part of the first image, then removing the second image and then restoring the hidden part of the first image. There is standard display technology. Naturally, such a technique is used in a normal window environment, for example, an environment in which a plurality of windows overlap each other. The trusted display processor 260 is configured to implement one or more of these standard techniques for the purpose of overlaying sticker images and message images on standard displays.

In some situations, a document may be too large to fit on the screen of VDU 105 all at once, but still be easily readable. Obviously, for the practicality of this embodiment, it is important that the user be able to read the document very clearly before signing. Therefore, it is also possible to divide a document into multiple screen pages, as described below, in which case each page needs to be signed and cryptographically tied to the signature of the previous page. It

First, the application process 500 displays the image of the first page and makes a call to the trusted display processor 260 to sign, as described above. When trusted display processor 260 returns individual signatures instead of requesting a summary, application process 500 directs trusted display processor 260 to display an image of the second page and sign the image. Obviously, in this case, trusted display processor 260 is configured to assist such requests by application process 500. Only after all images have been signed and returned to the application process 500, the application process 500 makes a request for summarization. This summary then includes the number of signed images in the multi-page document, as illustrated in the two page summary above.

The first page of a multi-page document is signed in the same way as a single page, resulting in individual signatures being returned. However, if there are subsequent images to be signed, the trusted display processor 260 recognizes that they are part of a multi-page document because it did not receive a summary request after the previous signature request. . As a result, trusted display processor 260 displays another message to the user asking for permission to sign the subsequent page. In response, the user signing the multi-page document uses a trusted authorized channel similar to that described above (eg, trusted switch 135) to make this page relevant to the previous page. To the trusted display processor 260 that it is and should also be signed. When the trusted display processor 260 receives this multi-page approval, it concatenates the signature of the previously signed page with the pixmap of the current page, creates a digest of the concatenation, and sends it to the smart card for signature. . This is done in lieu of sending the current pixmap-only digest. This process cryptographically "chains" subsequent pages to the previous one so that a page cannot be reconstructed without detection and no intermediate page can be inserted or deleted without detection.

The validity of the first page can be checked in exactly the same way as a single page. Subsequent pages are checked for validity using the same method as for a single page, except that the digest of the current pixmap is replaced with the concatenated previous signature and the digest of the current pixmap. You can

It will be appreciated that there are many ways to cryptographically chain subsequent pages to previous pages. These methods will be apparent to those of ordinary skill in the art of security in view of the description provided.

To further enhance security, the image of each page of the multi-page document is
It can be configured to include the conventional footer “x page / y”. here,"
“X” is the page number and “y” is the total number of pages. This makes it easy to detect missing documents simply by reading them.

A major advantage of the document signing scheme of the present invention is that the signed document may be a re-signed or sub-signed document. Therefore, the document summary preferably includes an audit trail. There are many variations on resignatures and subsignatures,
However, (obviously) electronic integrity checking should always be done before further signing. As an extreme example, a new signer can browse, approve, and re-sign each signed image in turn, effectively replacing the original signature with the new signature. For example, this method is used when one user signs a document prepared for that user by someone else. At the other extreme, if the new signer does not need to view the document at all, the original signature may simply be "authorized without due consideration" by signing the original abstract. This is useful for managers to sub-sign the work of trusted employees.

In the case of a resignature operation, application process 500 issues a resignature request and sends the signed document (and individual signatures and summaries) to trusted display processor 260. The trusted display processor 260 verifies the signed document using the signer's public key, restores the pixmap of the document (or each page of the document), and renders this verified image from the signature requesting application. To the new user in the correct order as if it were the original image of. The user approves acceptance of each individual image, for example using the trusted switch 135 as described above, and has the new user's smart card sign the image as described above. This results in the same signed document as the original document, except that it was signed by the new user's smart card.

Similarly, for a sub-signature operation, the application process 500 issues a sub-signature request and sends the signed document (and individual signatures and summaries) to the trusted display processor 26.
Send to 0. The trusted display processor 260 verifies the signed document and displays each verified image in the correct order to the new user as if it were the original image from the application process 500. The user approves acceptance of each individual image and the trusted display processor 260 signs the original summary with the new user's smart card. Optionally, the new user provides a certificate of the previous user's public key signed by the new user, reducing the processing overhead associated with later signature verification.

Obviously, there are various variations on the implementation of re-signing and sub-signature, which will be apparent to the person skilled in the art in view of the description of the invention.

Since the document can have a history of signatures, re-signatures, and / or sub-signatures, this embodiment conveniently provides audit information that forms part of the summary of the document. This audit information allows tracking the signature history of the document. This audit information includes data regarding the previous state of the document and the actions (actions) taken by the new user to generate the new state of the document. Audit information is signed by the trusted display processor 260 because it must be independent of the user. Audit information always includes any previous summary information, including the signature of that summary information by the previous signer. If the signed document was originally created, the trusted label processor 260 identification label I _DP is inserted as an audit root. The audit information may also have an indication of which individual images were viewed and approved by the new user, and whether the document was originally created or re-signed or sub-signed by the new user. preferable. To create a digest containing audit information, the smart card is sent a digest of audit information concatenated with the contents of the digest, rather than a digest of only the contents of the digest. The rest of the process is as described above.

As an extension of the process for signing a document, the trusted display processor 260 compresses the pixmap using a reversible compression algorithm before signing the pixmap data to store and store individual signatures. There are also ways to reduce the overhead associated with transmission.

Pixmaps are standard compression algorithms, such as LZ-1 or LZ-.
It can be compressed by a codeword-based algorithm to which 2 compression is applied.
Alternatively, a technique similar to OCR (Optical Character Recognition) can be used to compress the pixmap. In this case, the situation differs from conventional OCR in that the input data is completely "scanned", albeit at a lower resolution than conventional OCR. An OCR compressed version of the pixmap can be created using "BLOB matching" to create the alphabet for the pixmap. The pixmap constitutes a pixmap for each character of the alphabet, and these characters are used to form the message, such that the message represents the original pixmap. This means that the pixmap may be compressed into a new alphabet and messages may be written in this new alphabet. This means that the pixmap may have been compressed into a new alphabet and message written in that alphabet. Obviously, there is no error or ambiguity in this pixmap data, so this is a lossless compression method.

Another way to reduce the size of the image pixmap is to represent the image in pure black and white. This method uses 0 to define whether a pixel is black or white.
Or only a single bit set to 1 is needed. In another situation, the document image is represented as a full color image, where each pixel may typically require up to 24 bits. Obviously, this technique is suitable for simple black and white text-based documents. However, it is not suitable for color documents or images.

At any time, the document image can be converted back to a text-based document using an OCR-type process to reconstruct a standard digital text representation of the document. This technique cannot be used for signing because the text mapping may be inaccurate, but the signature cannot be converted back to a standard digital text representation (such as ASCII) for subsequent machine processing. Can be used by the recipient of the identified document. In the preferred embodiment, the trusted display processor 260 is provided to perform OCR document reconstruction.

To implement OCR, the OCR alphabet is generated in a standard way, then associated with a stored font and converted to a standard character set based on it. Like traditional OCR, the corresponding ambiguous characters can be kept in the pixmap and flagged for conversion by the user (this is a rare situation, especially for font type and size information for display). If the data is provided in the format FD, there is no error in the data). With extreme caution, this entire reconstructed document should be manually checked by a human for the appearance of the document that the signer intends to sign. Preferably, all document reconstruction processes are done by a trusted process.

The preferred embodiment described above goes beyond the point where the video data stored in the frame buffer memory 315 can be manipulated by the software of the host computer 100, including the operating system.
0 is based on the assumption that 0 has direct and dedicated access to this video data. This means that the video data will not be modified unless the trusted display processor 260 makes the modification.

It will be appreciated that not all computer architectures are configured this way. For example, in some computer architectures, the frame buffer memory is provided to form part of the main memory (main storage means), thereby forming a single address space (SAS) display system. One advantage of such a system is that both the CPU and the display processor have access to the frame buffer memory, which improves graphics performance by sharing the overhead of graphics operations. Obviously, implementing the present invention in such a SAS system would be
It is not based on the assumption that it is secure during signing because it can access the memory. However, there are many ways in which such a SAS system can be modified to provide practice of the invention. For example, the memory can be provided with control lines from the trusted display processor so that the data from the CPU is not updated during the signature operation. The storage device itself is preferably modified to include special logic to perform this function. Alternatively, access to the memory is blocked by inserting another logic circuit in the memory's normal control path. Therefore, such systems are based on the modified assumption that video data in the frame buffer memory can be modified by non-trusted display processors only with the permission of the trusted display processor. Obviously, as long as the system is truly secure, this assumption is appropriate for operation as secure as the first assumption.

In other architectures, such as a simple graphics environment, the functionality of the display processor may form part of the operating system itself, eliminating the need for separate display processor hardware. Obviously, in this case, the graphics overhead on the CPU will be higher than in a system with separate display processor hardware, which limits the graphics performance of the platform. Clearly, there is no room for a "high-credit display processor" in such a situation. However, the ability to protect the frame buffer memory provided by the trusted display processor, and the equivalent of interacting with a smart card, is adequate for controlling the display system (in any form) during signing. It will be apparent to those skilled in the art that it can be implemented using trusted components.

In other embodiments of the invention, the functionality of trusted switch 135 may be replaced by software. When the trusted switch process 529 is activated (as in step 630), instead of waiting for the operation of a dedicated switch, the trusted component 260 uses the random number generation capability to generate a nonce in the form of a string. This string is then displayed on the trusted display with a message in the form "Enter <string> to approve the action". Here, in order to approve the action, the user must input the given character string using the keyboard 110. This string is different every time and no other software has access to this string (the string is only passed between the trusted processor 300 and the display), so malicious software could interfere with this approval process. Is impossible.

In another embodiment of the invention, additionally or alternatively, the trusted display processor (or equivalent) comprises an interface for activating a trusted display. The trusted display can be, for example, an LCD panel display.
In a manner similar to the trusted switch providing the user with a trusted means for interacting with the trusted display processor, the trusted display allows the trusted display to provide high-level feedback to the user, other than via a standard VDU. We can provide a means of credit. For example, a trusted display can be used to provide user status messages associated with the signing operation described above. Here, the display is connected directly to the trusted display processor, or via some form of trusted communication path, so that applications running on a standard host computer cannot access the trusted display. It should be possible. In essence, such a trusted display is an addition to the so-called "trusted interface" mentioned above. In practice, the trusted display is just one example, and there is no reason why other forms of trusted feedback devices could not be included as additions or substitutions.
For example, some form of trusted audio device may be useful in providing audible feedback.

[Brief description of drawings]

FIG. 1 illustrates a computer system suitable for operation according to a preferred embodiment of the present invention.

FIG. 2 shows a hardware architecture of a host computer suitable for operation according to a preferred embodiment of the present invention.

FIG. 3 illustrates a hardware architecture of a trusted display processor suitable for operation according to a preferred embodiment of the present invention.

FIG. 4 illustrates a hardware architecture of a smart card processing engine suitable for operation according to the preferred embodiment of the present invention.

FIG. 5 illustrates a functional architecture of a host computer with a trusted display processor and smart card suitable for operation according to a preferred embodiment of the present invention.

[Figure 6]   FIG. 6 is a system diagram showing steps involved in generating individual signatures of a document.

FIG. 7 illustrates a sequence of messages between a trusted display processor and a smart card for restoring sticker image data from the smart card.

FIG. 8 illustrates a sequence of messages between a trusted display processor and a smart card for generating a signature on a document image.

FIG. 9 illustrates a sequence of messages between a trusted display processor and a smart card for generating a signature signature of a document image signing process.

FIG. 10a   FIG. 6 is a diagram showing an example high confidence image.

10b to 10d]   It is a figure which shows the visual step in the signature of a document image.

10e to 10g]   FIG. 6 illustrates an alternative method of highlighting an image of a document to be signed.

─────────────────────────────────────────────────── ─── Continued front page    (72) Inventor Barachev, Boris             Bristol BS 8-4, England             Rutie, Hotwells, Granby             Hill, Rutland House 7 (72) Inventor Chen, Rikun             United Kingdom Bristol BS 32.9 de             IQ, Bradley Stoke, Ha             -Best Close-1 F term (reference) 5J104 AA09 NA12 NA39 NA42

Claims (27)

[Claims] 1. A data processing system configured to generate a digital signature representing a document, the main memory means for storing a document to be digitally signed, and the means for generating a graphic signal for displaying the document. A main processing means for executing at least one application process including: a means for generating a request signal for the document to be signed; a display system; a frame buffer memory; Means for generating digital image data representing a document, storing the digital image data in the frame buffer memory, reading the digital image data from the frame buffer memory, and displaying an actual image of the digital image data on a display means. The digital image data is converted into a signal suitable for display. A display system comprising: means for converting and transferring the signal to display means; and a separate processing means operable in response to the request signal to generate a digital signature representing the digital image data. A data processing system consisting of high-trust components. 2. A means for the trusted component to deny any unprivileged application or process from writing to at least the portion of the frame buffer memory holding the digital image data of the document. The data processing system of claim 1, further comprising: means for generating a digital signature representative of the digital image data while the respective portions of the frame buffer memory are inaccessible for writing data. 3. The method according to claim 1, further comprising: a means for receiving the digital image data or an object expressing the digital image data; and a removable token including a processing means for generating each digital signature. The data processing system according to claim 1. 4. The high-credit component obtains and / or generates high-credibility image data, and the display system for highlighting a document image displayed using the high-credibility image data. The data processing system according to any one of claims 1 to 3, further comprising: 5. The data processing system according to claim 4, wherein the highly credible image data comprises pixmap data representing the highly credible image or instructions for forming the highly credible image. 6. The trusted component controls the display system to define a border that is characterized by the trusted image and that is located at least partly around the document image, or the border. Or a plurality of indicators, a background pattern characterized in that the high-credibility image forms at least a part of the background of the document image, and an image characterized by the high-credibility image formed in the document image, , A text message characterized by the high-credit image formed in or near the document image, and displayed by generating any one or more of the visual effects of Data processing system according to any one of claims 4 or 5, including highlighting the document image according to the invention. 7. The data processing system according to claim 4, wherein the trusted component includes means for obtaining and / or generating trusted image data from a removable token. 8. A data processing system according to claim 1, wherein the trusted component further comprises means for controlling a display system for displaying a message to a user. 9. The data processing system of claim 8, further comprising trusted input means for enabling a user to securely respond to a message. 10. The data processing system of claim 9, wherein the trusted input means comprises a switch connected to the trusted component via a secure communication path. 11. The data processing system of claim 3 or 7, wherein the trusted component and the secure token perform a mutual authentication process before further interaction. 12. The data processing system of claim 1, wherein the trusted component forms part of the display system. 13. The trusted display system allows the trusted component to access the frame buffer memory indirectly through the trusted component, so that the trusted component is physically and functionally. 13. The data processing system according to claim 12, wherein the data processing system is arranged between the main processing means and the frame buffer memory. 14. The method of claim 1 further comprising means for generating data summarizing a digital signature operation.
13. The data processing system according to any one of 13. 15. A method of digitally signing a document, the method comprising: generating digital image data of a document and updating the digital image data in a frame buffer memory; and reading the digital image data from the frame buffer memory. Converting the digital image data into a signal suitable for driving a visual display means and transmitting the signal to the visual display means for displaying an image of the document, and from the frame buffer memory upon request. Reading the digital image data and generating a digital signature representative of the image data. 16. The method of claim 15, further comprising the step of temporarily denying write access to the frame buffer memory by an unauthorized process while generating the digital signature. 17. The method according to claim 14, further comprising the step of acquiring and / or generating high-credibility image data and highlighting a document image using the high-credibility image data.
Or the method according to any one of 15; 18. The step of highlighting the document image comprises a boundary characterized by the trusted image and disposed at least in part around the document image, or one or more defining the boundary. An indicator, a background pattern characterized in that the high-credibility image forms at least a part of the background of the document image, an image characterized by the high-credibility image formed in the document image, the document And a text message characterized by the high-trust image formed in the image or near the document image, wherein at least one of the visual effects is generated. 18. The method of claim 17, comprising: 19. The method according to claim 17, wherein the trusted image data is obtained from a removable token. 20. A data processing system configured to digitally sign according to the method of any one of claims 15-19. 21. A method of digitally signing a document containing a plurality of separately viewable pages, comprising: a) generating digital image data of a first page of the document and storing the digital image data in a frame buffer memory. B) reading the digital image data from the frame buffer memory, converting the digital image data into a signal suitable for driving a visual display means, and converting the signal to display an image of the document. Transmitting to a visual display means, c) reading the digital image data from the frame buffer memory, generating a digital signature representing the digital image data, and storing the digital signature; d) other documents. Steps (a) to (c) are repeated for the page Generating a further digital signature representing all digital signature generated in step, the method consisting of. 22. A method for a second user to sub-sign a document already signed by a first user and attached with a first digital signature generated by the first user's private key. And generating digital image data of the document and updating the digital image data in a frame buffer memory; reading the digital image data from the frame buffer memory and driving the digital image data to a visual display means. A signal suitable for, and transmitting the signal to a visual display means for displaying an image of the document; verifying the integrity of the first digital signature; Generating a digital signature representative of the first digital signature based on a private key. 23. A method for a second user to sub-sign a document already signed by a first user and attached with a first digital signature generated by said first user's private key. And generating digital image data of the document and updating the digital image data in a frame buffer memory; reading the digital image data from the frame buffer memory and driving the digital image data to a visual display means. A signal suitable for, and transmitting the signal to a visual display means for displaying an image of the document; verifying the integrity of the first digital signature; The digital image data is read out and the first digital signature is displayed based on the secret key of the second user. Generating a digital signature, the method comprising a. 24. A data processing system configured to generate a digital signature representing a document, the main processing means for generating a graphics signal for displaying the document, the display system comprising: A frame buffer memory, means for generating digital image data representing the document based on the graphic signal, and storing the digital image data in the frame buffer memory; and reading the digital image data from the frame buffer memory, Means for converting the digital image data into a signal suitable for displaying an actual image of the digital image data on the display means and transferring the signal to the display means; Means for generating a digital signature that represents, and a data processing system consisting of Temu. 25. A system for digitally signing a document, comprising: a frame buffer memory, means for generating image data representing the document and storing the image data in the frame buffer memory; A unit for reading the image data from the memory and displaying each image on a display unit; and a unit for reading the image data from the frame buffer memory and generating a digital signature of the image data. system. 26. A trusted component for use in a data processing system according to any one of claims 1-14. 27. The trusted component of claim 26 manufactured to be tamper resistant.