Tamper-resistant computer system

CROSS-REFERENCES TO RELATED APPLICATIONS

[0001] NOT APPLICABLE

STATEMENT AS TO RIGHTS TO INVENTIONS MADE UNDER FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT

[0002] NOT APPLICABLE

REFERENCE TO A “SEQUENCE LISTING,” A TABLE, OR A COMPUTER PROGRAM LISTING APPENDIX SUBMITTED ON A COMPACT DISK.

[0003] NOT APPLICABLE

BACKGROUND OF THE INVENTION

[0004] The present invention relates to a technique for preventing illegal analysis and alteration of software used on a computer to assure high-level security protection. More specifically, the present invention relates to a technique and system for preventing illegal analysis and alteration of computer software to protect copyrighted material on a device used to play digital contents.

[0005] A device for playing digital contents, including motion pictures, still pictures and music, uses dedicated hardware or player software having a copyright protection function. For player software having a copyright protection function, a general-purpose computer, such as a personal computer (herein referred to simply as a PC), is typically used as a player device. Therefore, the example presented here describes a situation where a PC is used to play digital contents.

[0006] In the use of dedicated hardware having a copyright protection function, digital contents are encrypted before distribution. When each user receives the encrypted digital contents, decryption is performed through a tamper-resistant module for preventing illegal analysis and alteration in an authorized player device. Then, additional information, such as the conditions for use of the program, is read out, and the decrypted digital contents are played only if those conditions are satisfied.

[0007] If digital contents are played on a PC a software program having a copyright protection function is often employed. More specifically, in one method of streaming digital content, the digital content is not stored on a user's PC. In an alternative method, encrypted digital content is stored on the user's PC, and then, at the time of playback, it is decrypted and the conditions for use are read out for confirmation in the same manner as in the use of the dedicated hardware.

[0008] To prevent the copyright protection function of player software from being altered or illegally analyzed, the software is stored as an encrypted file, or as a hidden file. When player software is stored as an encrypted file, decryption is performed in an internal memory at the time of execution. If the player software is stored as a hidden file, the contents thereof are loaded into internal memory at the time of execution. In either of these methods, unauthorized analysis of internal memory can be conducted at the time of execution.

[0009] For protection against illegal copying, digital contents are stored similarly to the player software mentioned above, as an encrypted file or as a hidden file. In either method, illegal copying of the digital contents can still be conducted, as is the case with the player software.

[0010] On a common type of PC, a person having a certain level of expertise in electronic computing can analyze or tamper with a player software program stored on a hard disk, or on any other storage medium, by probing the operating system (OS) running on the PC or by using another software program on the PC. It is therefore possible to duplicate digital contents having protection against illegal copying or to infringe the conditions for use thereof. It is also possible to tamper with digital contents authorized for use only by a particular person so that another person can use them. A copyright on player software or digital contents could thus be infringed.

[0011] Where dedicated hardware is used for playing digital contents, a copyright thereon can be securely protected. However, when a portable device is redesigned or upgraded, a user must replace it with a new-model portable device to use new additional functions incorporated therein, increasing the cost of playing back digital contents. Because rapid advances in the functionality of dedicated hardware are expected, it is economically disadvantageous for each user to successively replace hardware models to use the latest functions.

BRIEF SUMMARY OF THE INVENTION

[0012] The present invention provides a technique for securely protecting copyrighted digital contents in a digital content player system (hereinafter referred to as a “system”) that uses player software for playing digital contents on a general-purpose computer, such as a PC. The present invention provides a technique and system for making player software used on a general-purpose computer, such as a PC, resistant to illegal or unauthorized analysis and alteration.

[0013] According to one aspect of the present invention, the following computer system configuration is provided: two independent operating environments, which are a first environment (1) for user interface processing and a second environment (2) for protection against illegal tampering, and a communication function for connecting these environments are arranged on a general-purpose computer, such as a PC. Individual process units (programs), each of which runs on each of the environments, run cooperatively to constitute application software (e.g., player software).

[0014] To preclude illegal tampering, the present invention provides a communication control function for limiting communications from environment 1 to environment 2, and from environment 2 to environment 1. More specifically, the following operations are carried out:

[0015] In communication from environment 1 to environment 2, player software in environment 1 writes a command or information to be transferred into a specific memory region that has been allocated for the purpose of communication. Then, by evoking the specific memory region, the program in environment 2 receives the command or information from environment 1. Environment 2 has a list of commands or information permitted for processing therein, and, according to this list, each of the permitted commands or information is processed in environment 2.

[0016] In communication from environment 2 to environment 1, the program in environment 2 writes a command or information into a specific memory region. Then, by evoking the specific memory region, the program in environment 1 receives the command or information for carrying out processing. Since the program in environment 2 is in control, as mentioned above, protection is ensured against illegal tampering by a malicious user even if it is attempted through environment 1.

[0017] More specifically, environments 1 and 2 are respectively managed by two independent operating systems (OSs) of each environment. The present invention introduces a multi-OS control program for running the two OSs on an apparatus and for controlling OS-to-OS communication. The multi-OS control program allocates an independent memory area to each of the OSs in such a manner that direct access from one OS to the other OS is not allowed. Each OS in the present invention has a process control function, a process scheduling function, an interrupt control function, and a memory management function. The present invention is thus applicable to any software having these functions, and is not limited to a conventional OS.

[0018] With regard to application software, such as player software, environment 1 provides a user interface component for receiving input information, such as operational instructions from a user, and for delivering output messages to the user; and environment 2 provides a command processing component (including a player control component) for carrying out operational instructions input from the user. The user interface component in environment 1 receives each operational instruction from the user, and then, through a communication control function, such as mentioned above, for controlling communication between environments 1 and 2, the user interface component transfers the operational instruction to the player control component in environment 2. Then, the command processing component in the environment 2 carries out processing as instructed by the user.

[0019] The user gets the application software by means of a removable storage medium, such as a CD-ROM, or from a server, through a network, by using a communication medium.

[0020] Before installation into a PC, the application software has a component program to be run in environment 1, a component program to be run in environment 2, and a digital signature. When the application software is to be installed in the PC, the component program executable in environment 1 issues an installation command to environment 2 by using the above-mentioned communication method between environments 1 and 2. Environment 2 authenticates the application software by verifying the digital signature, and the application software is installed so that the software can be used on the PC.

[0021] For system startup, system installation, permission for application software operation, and permission for digital contents playback, the present invention provides a tamper-resistant hardware module which is operatively associated with the PC to prevent unauthorized internal analysis and alteration of physical and logical elements. For example, an add-in PC board or an IC card (smart card) can be used as this tamper-resistant hardware module.

[0022] The player software may be partially or wholly encrypted. Before using the partially or wholly encrypted player software, the user obtains a decryption key. For example, a communication path is set up between the PC and a server supplying the decryption key, and after user authentication, the hardware module receives the decryption key from the server via the PC through the communication path. The hardware module receives a decryption command and decrypts the player software in environment 2.

[0023] Because the player software is usually stored on a device such as a hard disk, the portion of player software stored thereon may be encrypted to prevent unauthorized static analysis. Further, by adding a digital signature to the player software, unauthorized tampering therewith can be prevented. When the portion of the player software stored on the storage device is encrypted, a decryption key may be stored in the hardware module.

[0024] Digital content to be processed by the player software is distributed to each user in an encrypted form, as required. The user obtains a decryption key for the encrypted digital contents in the same way the decryption key for the encrypted player software was obtained, and then the digital contents are stored in the hardware module. The digital contents may also be stored in environment 1 or 2 instead of in the hardware module.

[0025] In the operation to access a cryptographic key for the player software or digital contents stored in the hardware module, the hardware module and the player software operating in environment 2 perform authentication using a digital signature. Only after authentication can the player software access the hardware module. Thus, illegal extraction of information from the hardware module can be prevented.

[0026] To ensure normal system startup, a boot program having a tamper-resistant feature is also prestored in the above-mentioned hardware module. At system startup, an authentication program is loaded into the PC's internal memory. After the authentication program determines that no unnecessary process (e.g., an illegal analysis program) is active in the internal memory, the boot program is loaded into internal memory for execution. When the boot program is executed, the multi-OS control program and system files OS1 and OS2 are loaded into internal memory from the hard disk. As required, a key for decrypting an encrypted system file is extracted from the hardware module, and the encrypted system file is decrypted on the internal memory. After decryption, the initial settings for each OS are input for system startup.

[0027] In the method above, memory access and analysis are inhibited or restricted during execution of the player software. Thus, unauthorized alteration and analysis of the player software can be prevented, and a copyright on digital contents can be protected. Where a removable storage medium, such as an IC card (smart card), is used as a hardware module, digital contents for which playback rights have been granted to each user can be played on another portable device having a system of the present invention by setting the hardware module thereon.

[0028] Although player software for digital contents has been used as an example in the foregoing description, it is to be understood that the present invention is not limited thereto. The present invention is also applicable to any OS-executable application software that could otherwise be subjected to illegal or unauthorized use, alteration or analysis.

[0029] These and other benefits are described throughout this specification. A further understanding of the nature and advantages of the invention may be realized by reference to the remaining portions of the specification and the attached drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

[0030]FIG. 1 is a diagram of the entire configuration of a tamper-resistant software system according to the preferred embodiment;

[0031]FIG. 2 is a diagram of a structure of system installation software;

[0032]FIG. 3 is a flowchart of a processing sequence to be performed for system startup;

[0033]FIG. 4 is a diagram of a method of communication between OS1 and OS2;

[0034]FIG. 5 is a diagram of a structure of a hardware module;

[0035]FIG. 6 is a diagram of a structure of distribution software;

[0036]FIG. 7 is a diagram of a procedure to be performed for getting a software key;

[0037]FIG. 8 is a flowchart of a processing sequence to be performed for software installation;

[0038]FIG. 9 is a diagram showing software stored in hard disks;

[0039]FIG. 10 is a flowchart of a processing sequence to be performed for software startup;

[0040]FIG. 11 is a diagram of a procedure to be performed for getting a contents key;

[0041]FIG. 12 is a diagram showing operations used for playing digital contents; and

[0042]FIG. 13 is a flowchart of a processing sequence to be performed for system installation.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0043] Outline of System

[0044]FIG. 1 shows an exemplary configuration of a system in a preferred embodiment. In this system, a multi-OS control program <b>8</b> presides over two operating systems, OS1 and OS2, on a PC. Reference numeral <b>12</b> indicates an internal memory on the PC, reference numeral <b>6</b> indicates a memory area managed by OS1, and reference numeral <b>7</b> indicates a memory area managed by OS2. An area in the PC's memory is allocated for carrying out the multi-OS control program <b>8</b>. OS1 manages a hard disk <b>204</b><i>a</i>, a keyboard <b>205</b> and a mouse <b>206</b>, and OS2 manages a hard disk <b>204</b><i>b </i>and a hardware module <b>3</b>. A display monitor <b>13</b> under exclusive control of multi-OS control program <b>8</b>, can be used for display by both OS1 and OS2. Further, in a modified arrangement, a speaker that can be used for output by both OS1 and OS2 may be provided. Reference numeral <b>10</b> indicates player software that has a user interface (UI) component program <b>504</b>, a player control program <b>503</b>, and a configuration file.

[0045] Multi-OS control program <b>8</b> is designed for controlling a plurality of OSs on the PC, and, more specifically, the multi-OS control program carries out initialization and partition-occupancy processing for each hardware part, CPU scheduling for each OS, and interrupt processing.

[0046] Each OS has a table for conversion from virtual addresses to physical addresses (also referred to as a page table). In Japanese Patent Application Laid-open No. 11-149385, discloses a technique in which a multi-OS control program performs a table changeover for running a plurality of OSs on a PC without emulation of privileged instructions (used for setting protection and memory management functions executable only by an OS). Further, as a method for concurrently running a plurality of OSs on a PC, a virtual machine system technique is known in which PC hardware emulation is performed. Based on these techniques, the present invention can be practiced as described below.

[0047] In the preferred embodiment, a first operating system OS1 provides functions to be operated directly by a user <b>11</b>, whereas a second operating system OS2 does not provide user-operated functions. Further, because OS-to-OS communication control is implemented, there is no function for direct access to OS2 from OS1. These arrangements prevent user <b>11</b> from identifying details of software running on OS2. Thus, dynamic analysis, such as tampering with software running on OS2, can be prevented.

[0048] In the system configuration described above, player control program <b>503</b> of player software <b>10</b>, which is not to be analyzed by user <b>11</b>, is run on OS2 for carrying out player operation control, and UI component program <b>504</b> is run on OS1 for receiving operational information from user <b>11</b>. Since OS1 cannot refer to the memory area managed by OS2, user <b>11</b> is prevented from learning how player control program <b>503</b> runs. User <b>11</b> is allowed to know only information provided by UI component program <b>504</b>.

[0049] Communication Between OS1 and OS2

[0050] Referring to FIG. 4, communication between the respective environments managed by OS1 and OS2 is carried out by communication control program <b>501</b>. For OS-to-OS communication, communication control program <b>501</b> refers to the contents of an OS2 reference region <b>9</b>. At system startup, the multi-OS control program <b>8</b> performs memory mapping of OS2 reference region <b>9</b> in OS1 to provide a page table to be used by OS2. Thus, communication control program <b>501</b> can refer to the OS2 reference region <b>9</b>. Communication control program <b>501</b> checks a command list <b>502</b> against information written in OS2 reference region <b>9</b> by UI component program <b>504</b>. More specifically, in OS2 reference region <b>9</b>, the UI component program <b>504</b> writes information regarding player control program <b>503</b> (program name for information transfer) and control information. If, as a result of checking command list <b>502</b>, it is found that an input command matches one of the commands contained in the command list, the input command is transferred to player control program <b>503</b>, which corresponds to UI component program <b>504</b>. Note that it is not necessarily required to provide a one-to-one correspondence for the UI component program <b>504</b> and player control program <b>503</b>.

[0051] Command list <b>502</b> contains commands that have been written by player control program <b>503</b> running on OS2 at startup, and execution requests from OS1 are permitted only for these commands. Any command from software that is not running on OS2 is not contained in command list <b>502</b>. If an input command does not match any of the commands contained in command list <b>502</b>, an error message is issued to UI component program <b>504</b> through a communication procedure from OS2 to OS1 (to be described in detail later). UI component program <b>504</b> provides the user with a visual or audible error indication using a function of OS1.

[0052] The contents of command list <b>502</b> vary according to the player control program running on the OS2. Each time player control program <b>503</b> is started up, command list <b>502</b> is rewritten by player control program <b>503</b>. When player control program <b>503</b> is terminated, commands associated with the player control program are removed from command list <b>502</b>.

[0053] During communication from OS2 to OS1, communication control program <b>501</b> receives information from player control program <b>503</b>; then communication control program <b>501</b> writes the information into OS2 reference region <b>9</b>. UI component program <b>504</b> obtains the information from OS2 by referring to the contents of OS2 reference region <b>9</b>.

[0054] In another embodiment, command list <b>502</b> may be provided in advance for each of player control programs <b>503</b>. Thus, communication control program <b>501</b> can conduct communication control through comparative checking of the command lists <b>502</b>. It is preferable that the command list <b>502</b> should be stored in an encrypted form on a storage device such as a hard disk device. Further, a technique for communication between different types of OSs, disclosed in Japanese Patent Application Laid-open No. 11-085546, which is hereby incorporated by reference for all purposes, is also applicable.

[0055] Features and Functions of Hardware Module

[0056] Hardware module <b>3</b> is a tamper-resistant hardware module, protected against unauthorized internal analysis and alteration of the physical and logical elements thereof. FIG. 5 shows an exemplary structure of hardware module <b>3</b>. A nonvolatile memory domain <b>309</b> of hardware module <b>3</b> stores a private key <b>301</b> unique to the hardware module in public key cryptography, a public key <b>302</b> corresponding to the private key, a certification authority public key <b>310</b>, a boot program <b>4</b> for launching the multi-OS control program <b>8</b>, a cryptographic system file decryption key <b>303</b>, an authentication program <b>5</b>, a key management program <b>19</b>, a contents key <b>17</b>, a software key <b>18</b>, and an additional information file <b>305</b>.

[0057] Contents key <b>17</b> is used for decrypting encrypted digital contents, and software key <b>18</b> is used for decrypting encrypted player software. Information such as the use period and conditions for use of contents key <b>17</b> and software key <b>18</b> is written in additional information file <b>305</b>. Moreover, hardware module <b>3</b> has a CPU <b>307</b>, a memory <b>306</b>, and an interface <b>308</b> for external communication. Using these components, hardware module <b>3</b> processes external input. In a modified arrangement, digital contents may be stored in nonvolatile memory domain <b>309</b>.

[0058] In operations involving external access to information stored in hardware module <b>3</b>, except at PC startup, the hardware module sends authentication program <b>5</b> to internal memory <b>12</b> of the PC. Then, on internal memory <b>12</b>, a software program attempting access to hardware module <b>3</b> is examined for authentication. Public key <b>302</b> or certification authority public key <b>310</b> is used for the authentication operation. If authentication is successful, hardware module <b>3</b> sends information needed for further access to the software program concerned. If the authentication is not successful, the hardware module sends an error message to the software program concerned.

[0059] When access to hardware module <b>3</b> is sought at the PC startup, hardware module <b>3</b> sends authentication program <b>5</b> to internal memory <b>12</b> of the PC, and then the authentication program determines whether or not any unnecessary process is active on the PC's internal memory <b>12</b>. If no unnecessary process is active, boot program <b>4</b> is extracted from hardware module <b>3</b> for booting up the PC. If an unnecessary process is active, the startup is aborted.

[0060] More specifically, authentication program <b>5</b> carries out a CPU register check on the PC to determine whether an interrupt-disabled state (interrupt-inhibited state) is set. If the interrupt-disabled state is set, boot program <b>4</b> is extracted from hardware module <b>3</b> for execution. If the interrupt-disabled state is not set, the startup is aborted.

[0061] In addition, limitations are imposed on information extraction by each software program attempting access to hardware module <b>3</b>. For this purpose, hardware module <b>3</b> includes a table indicating information contained in the hardware module and identifiers of software programs which are permitted to extract that information. Using this table, key management program <b>19</b> imposes limitations on information extraction by each software program.

[0062] Key management program <b>19</b> generates a temporary session key at random for the purpose of obtaining a contents key <b>17</b> or a software key <b>18</b> from a server <b>201</b>. Further, key management program <b>19</b> carries out decryption of encrypted data, authentication using a digital signature, and a key management operation described below.

[0063] A private key <b>301</b>, unique to each hardware module <b>3</b>, is used to pass the contents key <b>17</b> or the software key <b>18</b> for decrypting encrypted application software or encrypted digital contents. Because private key <b>301</b> and the public key <b>302</b> corresponding thereto are used, contents key <b>17</b> or software key <b>18</b> can be delivered in an encrypted form unique to each hardware module. Thus, illegal use of the application software and digital contents can be prevented, and it is also possible to provide different services to individual users. Key management program <b>19</b> does not provide a command function for outputting private key <b>301</b> outside hardware module <b>3</b>, thus preventing private key <b>301</b> from being accessed externally.

[0064] Instead of including all the above-described functions in one hardware module <b>3</b>, a plurality of hardware modules <b>3</b> may be used to contain each group of functions. For example, in an alternative arrangement hardware module <b>3</b> is divided into two modules: hardware module <b>3</b>A, which includes a group of functions regarding system startup (boot program <b>4</b>, authentication program <b>5</b>, key management program <b>19</b>, cryptographic system file decryption key <b>303</b>), and a hardware module <b>3</b>B, which includes a group of functions regarding key management for encrypted application software and encrypted digital contents (authentication program <b>5</b>, private key <b>301</b>, public key <b>302</b>, contents key <b>17</b>, software key <b>18</b>, key management program <b>19</b>, additional information file <b>305</b>).

[0065] Hardware module <b>3</b>B for management of the contents key <b>17</b> and the software key <b>18</b> may be provided in a removable type of storage medium such as an IC card. Thus, on one PC to be used by a plurality of users, different digital contents can be played for individual users. It is also possible to play digital contents on another PC having the system of the preferred embodiment by adding to it a removable hardware module <b>3</b>B.

[0066] Key Management

[0067] Key management program <b>19</b> resides in the hardware module and manages contents key <b>17</b>, software key <b>18</b> and cryptographic system file decryption key <b>303</b> (hereinafter “decryption key <b>303</b>”). The key management program uses additional information file <b>305</b>, which contains the usage conditions for contents key <b>17</b> and software key <b>18</b>. For example, on expiration of the use period of a key, key management program <b>19</b> removes the key so that digital contents and application software corresponding to the key become unavailable.

[0068] Through the use of the above-mentioned feature, it is possible to provide a free introductory service whereby each potential customer may play digital contents or use all the software functions for a trial period. Because contents key <b>17</b>, software key <b>18</b> and additional information file <b>305</b> are managed in hardware module <b>3</b>, illegal tampering therewith by a user can be prevented.

[0069] System Installation

[0070] For installation of the system of the preferred embodiment, hardware module <b>3</b> is connected to an external interface (e.g., universal serial bus (USB), PC card, add-in board) equipped on a common-type PC owned by user <b>11</b>. Then, system installation is carried out using system installation software <b>14</b> contained in a storage medium such as a CD-ROM.

[0071] Referring to FIG. 2, there is shown an exemplary structure of system installation software <b>14</b>. System installation software <b>14</b> has a plain text system installation program <b>221</b> (hereinafter “installation program <b>221</b>”), a cryptographic system file <b>222</b>, and a digital signature <b>223</b>. Installation program <b>221</b> includes a function for terminating an active unnecessary process, a function for partitioning hard disk <b>204</b>, and a function for installing the system of the preferred embodiment. Cryptographic system file <b>222</b>, which is wholly or partially encrypted, contains multi-OS control program <b>8</b> and OS2. The cryptographic system file may also contain OS, 1 if required. Digital signature <b>223</b> is used to verify that the system installation software has not been tampered with. This verification can be carried out with public key <b>302</b>. For system installation, user <b>11</b> needs to [access?] hardware module <b>3</b>, which contains public key <b>302</b>.

[0072]FIG. 13 is a system installation flowchart.

[0073] At step <b>1301</b>, user <b>11</b> executes installation program <b>221</b> for the PC, thus starting system installation.

[0074] At step <b>1302</b>, installation program <b>221</b> checks whether any process is active, and terminates any unnecessary active process so that sensitive information cannot be stolen during installation.

[0075] At step <b>1303</b>, installation program <b>221</b> issues a command to hardware module <b>3</b> for obtaining decryption key <b>303</b>.

[0076] At step <b>1304</b>, before executing the command received from installation program <b>221</b>, hardware module <b>3</b> sends authentication program <b>5</b> to the internal memory of the PC. Authentication program <b>5</b> calculates the hash values of installation program <b>221</b> and cryptographic system file <b>222</b>, and sends the calculation results and digital signature <b>223</b> to hardware module <b>3</b>. Then, key management program <b>19</b> performs authentication using the calculation results, digital signature <b>223</b>, and public key <b>302</b>. If the authentication is successful, decryption key <b>303</b> is passed to installation program <b>221</b>, and control goes to the next step. If the authentication is not successful, an error message is given to installation program <b>221</b> to abort system installation.

[0077] At step <b>1305</b>, installation program <b>221</b> decrypts cryptographic system file <b>222</b> using decryption key <b>303</b>. At step <b>1306</b>, installation program <b>221</b> carries out system installation with reference to configuration file data contained in the decrypted cryptographic system file <b>222</b>. In an alternative arrangement, a system installation program may reside in cryptographic system file <b>222</b>. Thus, after decryption of cryptographic system file <b>222</b>, the system installation program contained therein can be used for carrying out system installation.

[0078] Installation program <b>221</b> creates partitions on hard disk <b>204</b> to be allocated as storage areas for OS1 and OS2. All the information including the data OS1 held on the hard disk before introduction of the system of the present invention is stored in area <b>204</b><i>a</i>, allocated to OS1, and OS2 is stored in area <b>204</b><i>b</i>, which is allocated to OS2. Multi-OS control program <b>8</b> may be written in either of the areas <b>204</b><i>a </i>and <b>204</b><i>b </i>allocated to OS1 and OS2, or multi-OS control program <b>8</b> may be written in a newly allocated storage area. When a PC having a plurality of hard disk drives is used, areas <b>204</b><i>a </i>and <b>204</b><i>b </i>may be allocated to different drives without further partitioning of the hard drive. To prevent illegal analysis and alteration by a user, multi-OS control program <b>8</b> and OS2 are preferably written in a wholly or partially encrypted form on the hard disk. Further, OS1 may also be written in an encrypted form on the hard disk. For normal startup of the system, installation program <b>221</b> writes boot program <b>4</b> in hardware module <b>3</b>. A program and other necessary startup information from hardware module <b>3</b> are written in a master boot record on the hard disk.

[0079] While installation of the system of the preferred embodiment is based on the condition that the OS1 has been installed in the PC in advance, it is also possible to introduce the system of the preferred embodiment even if the OS1 has not been installed in advance. Moreover, the above-mentioned installation method is not limited to installation of the system of the preferred embodiment, but is applicable to installation of an OS on each PC.

[0080] System Startup

[0081]FIG. 3 is a flowchart of system startup in the preferred embodiment. At steps <b>231</b> and <b>232</b>, when the user turns on power to the PC, the CPU of the PC calls up a program (initial program) in the master boot record on the hard disk. This program loads authentication program <b>5</b> held in hardware module <b>3</b> onto the internal memory of the PC. Then, authentication program <b>5</b> checks whether any unnecessary process is active on the internal memory of the PC. If an unnecessary process is active, the system startup is aborted. If no unnecessary process is active, authentication program <b>5</b> reads boot program <b>4</b> from hardware module <b>3</b> into the internal memory of the PC for execution of the boot program.

[0082] In particular authentication program <b>5</b> carries out a CPU register check on the PC for to determine whether an interrupt-disabled state (interrupt-inhibited state) is set. If an interrupt is disabled, authentication program <b>5</b> continues to run and reads boot program <b>4</b> from hardware module <b>3</b> into the internal memory of the PC for execution. If the interrupt-disabled state is not set, the startup is aborted.

[0083] Because authentication program <b>5</b> checks to ensure that no unnecessary process is active, i.e., determines whether an interrupt is disabled as mentioned above, it is possible to prevent a potential transgressor from altering the master boot record to call up authentication program <b>5</b>, for example, after executing a boot monitoring program or the like. Thus, theft of sensitive information (e.g., the decryption key) is prevented.

[0084] At steps <b>233</b> and <b>234</b>, boot program <b>4</b> loads the cryptographic system file from the hard disk into the internal memory of the PC, and then takes the decryption key <b>303</b> out of hardware module <b>3</b> to decrypt the cryptographic system file. At step <b>235</b>, multi-OS control program <b>8</b> allocates memory areas for OS1 and OS2 and places system files from OS1 and OS2 in their respective memory areas. The multi-OS control program then executes an OS-to-OS changeover. Each OS, after taking control, carries out initial setting and loads necessary programs and data into the internal memory. Thus, the system startup is complete, and the PC is ready for operation and user input on OS1.

[0085] Structure of Player Software before Installation

[0086] A part of the player software <b>10</b> used in the system of the preferred embodiment is encrypted in advance with a unique key. FIG. 6, shows an exemplary structure of player software <b>10</b> before installation. Player software <b>10</b> has an OS1 installer <b>311</b>, an OS2 installer <b>312</b>, cryptographic software <b>313</b>, and a digital signature <b>16</b>. OS1 installer <b>311</b>, which is run on OS1, has a function for issuing a request for installing player software <b>10</b>. OS2 installer <b>312</b>, which is run on OS2, has a function for extracting software key <b>18</b> from hardware module <b>3</b>. Cryptographic software <b>313</b> is used for installing player software <b>10</b> on OS2.

[0087] Each of OS1 installer <b>311</b>, OS2 installer <b>312</b> and cryptographic software <b>313</b> has a plurality of files including a program file, data file and configuration file. It is necessary to encrypt cryptographic software <b>313</b> wholly; i.e., only the sensitive part of the cryptographic software may be encrypted, or cryptographic software <b>313</b> may be partially encrypted for imposing limitations on usage and functionality. Further, it is not necessary to use a common encryption key; i.e., a different encryption key may be used for each file or each function included in player software <b>10</b>. Digital signature <b>16</b> is used for detecting an illegal alteration in player software <b>10</b>. In a situation where only player software <b>10</b> is to be protected against an illegal alteration, it is not necessary to encrypt the player software, and digital signal <b>16</b> is used for detecting an illegal alteration therein.

[0088] Player software <b>10</b> in the system of the preferred embodiment may be distributed through a network such as the Internet or by means of a removable storage medium, in the same manner as for other existent software.

[0089] Although the player software is used as an example in the preferred embodiment, it is to be understood that the present invention is applicable to any other software to be protected against illegal analysis and alteration.

[0090] Getting the Software Key

[0091]FIG. 7 shows a procedure for getting software key <b>18</b>. This procedure is performed when player software <b>10</b> is installed, or when it becomes necessary to decrypt an encrypted portion of player software <b>10</b>. At step <b>321</b>, player software <b>10</b> sends server <b>210</b> public key <b>302</b> (KP), which is unique to the hardware module <b>3</b>; public key certificate information, which may be stored together with the public key <b>302</b>; and the ID information for player software <b>10</b>.

[0092] Then, using the public key certificate information, server <b>201</b> verifies hardware module <b>3</b> for authentication. At step <b>322</b>, server <b>201</b> generates a temporary session key Ks<b>1</b> (symmetric key) and sends data encrypted using the received public key <b>302</b> (KP) to the PC of user <b>11</b>. On the PC of user <b>11</b>, player software <b>10</b> receives the encrypted data and delivers it to hardware module <b>3</b>.

[0093] At step <b>323</b>, the key management program <b>19</b> in hardware module <b>3</b> decrypts the encrypted data using private key <b>301</b> to obtain session key Ks<b>1</b>, generates a temporary session key Ks<b>2</b> (symmetric key), encrypts session key Ks<b>2</b> using session key Ks<b>1</b>, and sends encrypted session key Ks<b>2</b> to server <b>201</b>.

[0094] At step <b>324</b>, server <b>201</b> decrypts encrypted session key Ks<b>2</b> using session key Ks<b>1</b> to obtain session key Ks<b>2</b>, encrypts software key <b>18</b> (Ksoft) and additional information (such as the conditions for use) using session key Ks<b>2</b>, and sends encrypted software key <b>18</b> (Ksoft) and additional information to the PC of user <b>11</b>.

[0095] When server <b>201</b> is required to send only software key <b>18</b> (Ksoft), server <b>201</b> may encrypt software key <b>18</b> (Ksoft) using public key <b>302</b> (KP) and send the encrypted software key <b>18</b> (Ksoft) to the PC of user <b>11</b>. On the PC of user <b>11</b>, player software <b>10</b> writes the received data into hardware module <b>3</b> or onto the hard disk of the PC. When the received data is written into hardware module <b>3</b>, encryption is not necessary;, therefore in hardware module <b>3</b>, the received data may be decrypted using session key Ks<b>2</b> and stored in hardware module <b>3</b>.

[0096] In contrast, when the received data is written onto the hard disk of the PC, an encrypted form thereof is stored on the hard disk, while session key Ks<b>2</b> is stored in hardware module <b>3</b>. In this case, there may be provided an arrangement whereby encrypted software key <b>18</b> (Ksoft) and additional information are decrypted once using the session key Ks<b>2</b> and then a new key is generated for re-encrypting software key <b>18</b> (Ksoft) and additional information.

[0097] Installation of Player Software

[0098] A processing flow for installation of player software <b>10</b> is now described with reference to FIGS. 6 and 8. At step <b>331</b>, user <b>11</b> starts up OS1 installer <b>311</b>. Then, at step <b>332</b>, OS1 installer <b>311</b> writes a command for installing player software <b>10</b> into OS2 reference region <b>9</b> in the OS1 memory area. This installation command includes a file transfer/copy command function necessary for installing the player software residing in the OS1 memory area onto the OS2, and a command function for activating OS2 installer <b>312</b>.

[0099] At step <b>333</b>, communication control program <b>501</b> carries out the installation command with reference to OS2 reference region <b>9</b>. and player software <b>10</b> is installed onto the OS2 memory area. At step <b>334</b>, OS2 installer <b>312</b> asks hardware module <b>3</b> whether the hardware module has the software key <b>18</b> corresponding to the player software to be installed. At this step, hardware module <b>3</b> sends authentication program <b>5</b> to the PC's internal memory <b>12</b>, and authentication program <b>5</b> calculates a hash value of player software <b>10</b> and sends the calculated hash value to hardware module <b>3</b> together with digital signature <b>16</b>.

[0100] Using the calculated hash value, certification authority public key <b>310</b>, and digital signature <b>16</b>, key management program <b>19</b> authenticates the player software. If authentication is successful, the inquiry from OS2 installer <b>312</b> is accepted. If authentication is not successful, an error message is returned to the OS2 installer. In an alternative arrangement, authentication program <b>5</b> may be provided in the OS2 memory area in advance. Thus, when a request for access to hardware module <b>3</b> takes place, authentication program <b>5</b> can immediately perform authentication of player software <b>10</b>.

[0101] If the hardware module <b>3</b> does not have software key <b>18</b>, OS2 installer <b>312</b> gets the software key from server <b>201</b> and passes the software key to hardware module <b>3</b>. Thereafter, OS2 installer <b>312</b> sends a command for decryption to the hardware module.

[0102] If hardware module <b>3</b> has software key <b>18</b>, OS2 installer <b>312</b> sends a command for decryption to the hardware module without issuing an inquiry to server <b>201</b>. At step <b>335</b>, hardware module <b>3</b> sends the corresponding software key <b>18</b> to OS2 installer <b>312</b>, and then the OS2 installer carries out decryption. In the main part of the player software <b>10</b>, only data necessary for installation is decrypted while the remaining data is left in an encrypted form. There may also be provided an arrangement where decryption is performed once to generate a new key and then re-encryption is performed using the new key. In a situation where player software <b>10</b> is provided in non-encrypted form or when decryption is not required at the time of installation, authentication is made using digital signature <b>16</b> before installation of player software <b>10</b>. When it becomes necessary to perform decryption, hardware module <b>3</b> is asked whether the hardware module has software key <b>18</b>. If the hardware module does not have software key <b>18</b>, an inquiry is issued to the server <b>201</b> to obtain the key.

[0103] As shown in FIG. 9, through installation, the UI component program <b>504</b> is stored on hard disk <b>204</b><i>a </i>for OS1, and a system boot program <b>342</b>, cryptographic software <b>343</b> and digital signature <b>344</b> are stored on hard disk <b>204</b><i>b </i>for OS2. System boot program <b>342</b> has a function for decrypting cryptographic software <b>343</b> for execution thereof. The cryptographic software is arranged in an encrypted form in various files of player software <b>10</b>, including player control program <b>503</b>. Cryptographic software <b>343</b> and digital signature <b>344</b> may be written onto hard disk <b>204</b><i>a </i>for OS1. In addition, it is not required that these files be discrete, but they may be arranged in partitioned structures contained in one file.

[0104] If player software <b>10</b> is provided in a non-encrypted form, it is only necessary to write UI component program <b>504</b> onto hard disk <b>204</b><i>a </i>for OS1 and to write the plain text software proper and digital signature <b>344</b> onto hard disk <b>204</b><i>b </i>for OS2. Digital signature <b>344</b> may be incorporated in the installation software in advance according to one method; a new digital signature may be generated at the time of installation according to another method; or a combination of these methods may be applicable. For generating a new digital signature at the time of installation, a hash value is calculated after installation, and that value is sent to hardware module <b>3</b> for encryption using private key <b>301</b>, which resides in the hardware module. Thus, a new digital signature (corresponding to digital signature <b>344</b>) can be generated.

[0105] A one-to-one correspondence for files written in hard disks <b>204</b><i>a </i>and <b>204</b><i>b </i>for OS1 and OS2 is not required. That is, a one-to-one correspondence is not required for UI component program <b>504</b> and system boot program <b>342</b>/cryptographic software <b>343</b>. Since UI component program <b>504</b> is used to provide an interface with user <b>11</b>, security protection is not affected even if UI component program <b>504</b> is altered or replaced. Where the interface of the software running on OS2 is disclosed, each user is free to create a UI component program as required.

[0106] License Agreement on Player Software

[0107] The license agreement for player software <b>10</b> can be completed in different ways depending upon whether the player software is provided in an encrypted or non-encrypted form. When player software <b>10</b> is provided in encrypted form, it is possible to complete a license agreement at the time of receiving the decryption key corresponding to the player software. When player software <b>10</b> is provided in non-encrypted form and a license agreement is necessary, a digital signature is assigned when a license agreement has been completed for player software <b>10</b>.

[0108] Key control program <b>19</b> generates the digital signature using private key <b>301</b> in hardware module <b>3</b>, and writes the digital signature onto the hard disk or the hardware module. When a license agreement is arranged, the digital signature is also rewritten. The digital signature prevents illegal use of player software <b>10</b> by user <b>11</b>.

[0109] Startup of Player Software

[0110]FIG. 10 is a flowchart showing the startup process for of player software <b>10</b>. At step <b>401</b>, user <b>11</b> runs UI component program <b>504</b>. During execution of the UI component program, a command for activating system boot program <b>342</b> is written into OS2 reference region <b>9</b>. UI component program <b>504</b> can be activated by using file management software or by clicking an on-screen icon thereof.

[0111] At step <b>402</b>, communication control program <b>501</b> refers to OS2 reference region <b>9</b> to activate system boot program <b>342</b>. At step <b>403</b>, system boot program <b>342</b> extracts software key <b>18</b> from hardware module <b>3</b> for decrypting cryptographic software <b>343</b>. Thus, the cryptographic software <b>343</b> is decrypted and divided among player control program <b>503</b> and various configuration files. In the above sequence, hardware module <b>3</b> authenticates system boot program <b>342</b> using digital signature <b>344</b>, in the same manner as described in connection with step <b>1304</b>. If authentication is successful, software key <b>18</b> is passed to system boot program <b>342</b> according to the command concerned.

[0112] More specifically, before execution of the command, hardware module <b>3</b> sends authentication program <b>5</b> to the internal memory of the PC. Authentication program <b>5</b> calculates hash values for system boot program <b>342</b> and cryptographic software <b>343</b>, and sends the calculation results and digital signature <b>344</b> to hardware module <b>3</b>. Then, key management program <b>19</b> performs authentication using the results of calculation, digital signature <b>344</b>, and public key <b>302</b>. If authentication is successful, software key <b>18</b> is passed to system boot program <b>342</b>, and control goes to the next step. If the authentication is not successful, an error message is given to system boot program <b>342</b> to abort the startup.

[0113] Authentication of system boot program <b>342</b> may also be performed by a device driver of hardware module <b>3</b> or by an authentication program in OS2. Even if a part of cryptographic software <b>343</b> is encrypted, decryption of the encrypted part may not be required at the time of startup or a certain function may be unusable according to the conditions for use. In such a case, player software <b>10</b> is started up leaving the encrypted part intact, and the encrypted part is decrypted later, as required, if the conditions for use are satisfied.

[0114] At step <b>404</b>, player control program <b>503</b> reads the configuration files, and sends a message to UI component program <b>504</b> that startup of player software <b>10</b> has been completed. When the UI component program <b>504</b> receives this message, player software <b>10</b> is ready for operation by the user.

[0115] Control of Player Software

[0116] After startup of player software <b>10</b>, a command for controlling player control program <b>503</b> from OS1 is added to command list <b>502</b> by player control program <b>503</b>. The command added at this step is a temporary command written by the player control program <b>503</b>, and is removed from command list <b>502</b> at the end of execution. UI component program <b>504</b> receives an operational instruction (e.g., digital contents playback/stop, contents title selection) from user <b>11</b>, and writes a control command for player control program <b>503</b> into OS2 reference region <b>9</b>. The command written in OS2 reference region <b>9</b> is read out by communication control program <b>501</b>. If the command thus read out by communication control program <b>501</b> matches one of the commands contained in command list <b>502</b>, communication control program <b>501</b> passes the command to player control program <b>503</b>. If the command read out by control program <b>501</b> does not match any of the commands contained in command list <b>502</b>, communication control program <b>501</b> writes an error message into OS2 reference region <b>9</b>. Then, the error message is passed to UI component program <b>504</b>, which notifies user <b>11</b> of the error with a visual or audible indication using a function of OS1.

[0117] When player control program <b>503</b> receives the command from communication control program <b>501</b>, player control program carries out the command. If necessary, player control program <b>503</b> delivers screen or audio output as a result of the command execution. OS2 provides device control for screen or audio output.

[0118] Multi-OS control program <b>8</b> has exclusive control over OS1 and OS2, makes possible their access to the devices used for screen and audio output (e.g., sound board, video board). More specifically, multi-OS control program <b>8</b> manages the control of the devices, themselves. When it becomes necessary for each OS to use one of the devices, an interrupt is issued to multi-OS control program <b>8</b>, which performs a changeover of device control.

[0119] Distribution of Digital Content

[0120] Digital content may be distributed in a variety of ways using removable media, communication media, or broadcast media. When digital content is available on a billable basis or when any limitation is imposed on the playback of digital content, an encrypted form of the digital content is used for distribution. In distribution of encrypted digital content, encryption is made with a key unique to the digital content (content key <b>17</b>). The memory area managed by OS1 or OS2 or hardware module <b>3</b> may be used for storing digital content in the PC.

[0121] Digital content distributed through communication or broadcast media can be stored in the OS2 memory area or in hardware module <b>3</b> by downloading software having the same structure as that of the player software, and the digital content can be stored at the time of the download. In addition, the use of file management software having the same structure as that of the player software facilitates the transfer of digital content held in the OS1 memory area into the OS2 memory area or into hardware module <b>3</b> by enabling the digital content to be moved or copied to those storage locations content

[0122] Furthermore, through use of the above file management software, a file held in the OS2 memory area or in hardware module <b>3</b> can be managed from the OS1 side. More specifically, the content of a file held in the OS2 memory area or in hardware module <b>3</b> cannot be changed, but user <b>11</b> can select desired content for playback using player software <b>10</b> or can rename the file.

[0123] Obtaining the Contents Key

[0124]FIG. 11 shows a procedure for obtaining the contents key <b>17</b>. At step <b>411</b>, the player software <b>10</b>, which is used to play encrypted digital contents, sends the public key <b>302</b> (KP) unique to hardware module <b>3</b>, the public key certificate information (which may be stored with public key <b>302</b>), and the ID information for the digital contents to server <b>201</b>.

[0125] Then, using the public key certificate information, server <b>201</b> verifies the hardware module <b>3</b> for authentication. At step <b>412</b>, server <b>201</b> generates a temporary session key Ks<b>1</b> (symmetric key) and sends data encrypted using the received public key <b>302</b> (KP) to the PC of user <b>11</b>. On the PC of user <b>11</b>, player software <b>10</b> receives the encrypted data and supplies it to the hardware module <b>3</b>.

[0126] At step <b>413</b>, the key management program in hardware module <b>3</b> decrypts the encrypted data using private key <b>301</b> to attain the session key Ks<b>1</b>, generates a temporary session key Ks<b>2</b> (symmetric key), encrypts session key Ks<b>2</b> using session key Ks<b>1</b>, and sends the encrypted session key Ks<b>2</b> to the server <b>201</b>. At step <b>414</b>, server <b>201</b> decrypts the encrypted session key Ks<b>2</b> using session key Ks<b>1</b> to obtain session key Ks<b>2</b>, encrypts the contents key <b>17</b> (Kc) and additional information (such as conditions of use information) using session key Ks<b>2</b>, and sends the encrypted contents key <b>17</b> (Kc) and additional information to the PC of user <b>11</b>.

[0127] The conditions of use information includes information regarding the use period of the key. In a situation where it is required for server <b>201</b> to send only contents key <b>17</b> (Kc), the server <b>201</b> may encrypt the contents key using public key <b>302</b> (KP) and send the encrypted contents key <b>17</b> (Kc) to the PC of user <b>11</b>. On the PC of user <b>11</b>, player software <b>10</b> writes the received data into hardware module <b>3</b> or onto the hard disk of the PC. Where the received data is written into hardware module <b>3</b>, encryption is not necessary, and, therefore, the received data may be decrypted in the hardware module, using session key Ks<b>2</b>, and stored there.

[0128] In contrast, where the received data is written onto the hard disk of the PC, an encrypted form thereof is stored on the hard disk, whereas session key Ks<b>2</b> is stored in hardware module <b>3</b>. In this case, there may be an arrangement whereby encrypted contents key <b>17</b> (Kc) and additional information are decrypted once using session key Ks<b>2</b> and then a new key is generated for re-encrypting contents key <b>17</b> (Kc) and additional information.

[0129] Playback of Digital Contents

[0130]FIG. 12, shows a flow of operations for playing digital contents. At step <b>421</b>, in response to an instruction from user <b>11</b>, UI component program <b>504</b> writes a startup command to activate system boot program <b>342</b> in OS2 reference region <b>9</b>. At step <b>422</b>, communication program <b>501</b> reads the startup command from OS2 reference region <b>9</b> and starts up system boot program <b>342</b>, which decrypts cryptographic software <b>343</b> and starts up player control program <b>503</b>.

[0131] At step <b>423</b>, user <b>11</b> uses UI component program <b>504</b> to select the digital contents for playback. UI component program <b>504</b> then writes that information into OS2 reference region <b>9</b>. At step <b>424</b>, communication control program <b>501</b> receives the information regarding the selection and passes it to player control program <b>503</b>, which loads the digital contents corresponding to the selection from the hard disk into the internal memory of the PC.

[0132] At step <b>425</b>, if the digital contents are in an encrypted form, player control program <b>503</b> asks hardware module <b>3</b> whether the contents key that corresponds to the digital contents is stored in the module. If contents key <b>17</b> is not found, player control program <b>503</b> lets user <b>11</b> determine whether to abort playback or to obtain the key from the server.

[0133] When user <b>11</b> chooses to obtain contents key <b>17</b>, an inquiry is issued to server <b>201</b> to get contents key <b>17</b>. After contents key <b>17</b> is obtained, a request to extract the contents key is sent from player control program <b>503</b> to hardware module <b>3</b>. Key management program <b>19</b> in hardware module <b>3</b> checks an indicated condition for use in additional information file <b>305</b>. If the condition is satisfied, key management program <b>19</b> passes contents key <b>17</b> to player control program <b>503</b>. Using the contents key <b>17</b> thus received, player control program <b>503</b> decrypts the digital contents. If the digital contents are not in an encrypted form, control goes to step <b>427</b>.

[0134] At step <b>427</b>, player control program <b>503</b> plays the digital contents. When the digital contents are video images, player control program <b>503</b> outputs the video images onto display monitor <b>13</b>. Further, when sound is included in the digital contents, player control program <b>503</b> delivers sound output to a speaker (not shown). As described above, the present invention makes it possible to prevent illegal alteration and analysis of computer software.

[0135] Furthermore, according to the preferred embodiment, a semiconductor device and a physical device such as a CPU in a PC preferably has a private key and a public key stored in a tamper-resistant internal memory area thereof, and, at the time of data transmission/reception, a public key exchange and a session key transfer are performed and data is encrypted with a session key. In this way, the possibility that data running through a circuit bus may be illegally extracted can be eliminated. Thus, illegal alteration and analysis of software can be safely prevented.

[0136] Further, where the CPU or each device does not output its private key outside the user's system, and programs and data are stored on a hard disk, it is preferable to perform encryption using the public key in the CPU and decryption using the private key in the CPU at the time of a read operation. The present invention also provides application software and an operating environment resistant to illegal or unauthorized alteration, operation and analysis.

[0137] Because analysis and alteration of application software by an unauthorized user can be prevented, it is possible to protect a copyright on the digital contents which are played using the player software therefor. Thus, an author can provide high-quality digital contents without worrying about an infringement of a copyright such as illegal duplication. Each user can enjoy high-quality digital contents on a PC and can upgrade a software version economically. Therefore, the latest functions and services constantly become available to each user.

[0138] A hardware manufacturer can reduce production cost in comparison to the cost of providing dedicated hardware and can promptly supply new products and services to users. In addition, with the present invention, use of a removable type of storage medium such as an IC card, enables a user to play digital contents for which the right to playback has been granted on another PC or portable device. As described above and according to the present invention, a software product and a system for running the same can be provided in a tamper-resistant arrangement. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. Those skilled in the art will appreciate that various modifications and changes may be made to the exemplary embodiment without departing from the broader spirit and scope of the invention as set forth in the claims.