JP2005182774A - Data processor - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a data processor capable of reducing secure resource since a load on a protection mechanism for protecting the resource is increased when the secure resource is increased in a secure mode in the data processor executing a process while switching between the secure mode for accessing the secure resource to be protected and a normal mode disabled to access the secure resource. <P>SOLUTION: This date processor stores at least one processing procedure utilizing the secure resource and a secure program including a call instruction for calling a normal program executed in the normal mode, calls the normal program by the call instruction during execution of the secure program and operates according to the normal program called. <P>COPYRIGHT: (C)2005,JPO&NCIPI

Description

  The present invention switches between a secure mode in which a secure resource can be accessed and a normal mode in which only a normal resource other than the secure resource can be accessed to execute a program in a program executed in the secure mode and in the normal mode. The present invention relates to a technique for operating a program to be executed correspondingly.

In recent years, digital contents including music and video have been handled in various devices. These devices can copy and edit digital contents without degrading them. However, from the viewpoint of copyright, these digital contents need to be handled protected.
According to the prior art, a secure mode that allows access to secure data that needs to be protected and a secure application that needs to be protected, and a normal mode that cannot access these secure data and secure applications are monitored. Discloses a data processing apparatus that performs switching. According to this technique, an application that operates in the normal mode requests a process to the secure application via an operating system that operates in the normal mode. The operating system requests the monitor to switch the execution mode, and the monitor switches the execution mode. The secure application performs the requested processing, and returns the processing result to the application via the secure operating system that operates in the secure execution mode. The secure operating system requests the monitor to switch the execution mode, and the monitor switches the execution mode. With such a configuration, the secure mode and the secure application cannot be directly accessed from the application operating in the normal mode by switching between the secure mode and the normal mode. Therefore, secure data and secure applications can be protected.
A New Foundation for CPU Systems Security (searched on November 20, 2003, URL: http://www.arm.com/armtech.nsf/htmlall/FC4C07580E29428080256D1A004A2345/$File/TrustZone_WP.pdf?OpenElement)

  However, in the method shown by the prior art, it is necessary to secure a memory for storing data and programs used in the secure mode separately from the memory used in the normal mode. Memory used in secure mode requires a protection mechanism that protects the memory from unauthorized access. Therefore, when the memory used in the secure mode increases, the load related to the protection mechanism increases, and it is necessary to increase the scale of the protection mechanism. Therefore, there is a need for a data processing apparatus that can reduce the memory used in the secure mode.

  Therefore, the present invention has been made in view of such problems, and an object thereof is to provide a data processing device, a data processing method, a data processing program, and a recording medium that can be used in the secure mode and can reduce the memory. And

  To achieve the above object, the present invention executes a program by switching between a secure mode in which use of a secure resource to be protected is permitted and a normal mode in which only use of a normal resource that is not protected is permitted. A data processing apparatus, comprising a normal storage means for storing a normal program composed of one or more processing procedures using the normal resource, and one or more processing procedures using the secure resource. A secure storage unit storing a secure program including at least a call instruction for calling the normal program; a determination unit for determining whether an instruction to be executed next in the secure mode is the call instruction; In the secure mode, when it is determined that it is the call instruction, before being called by the call instruction An output unit that outputs identification information indicating a normal program; a switching unit that protects a secure resource and switches from a secure mode to a normal mode when the call instruction is determined; and the identification information in the normal mode. Receiving means, reading means for reading out the normal program indicated by the received identification information from the normal storage means in the normal mode, and processing means operating in accordance with the read normal program in the normal mode. Features.

  According to the above configuration, when the secure program includes the call instruction, and the instruction to be executed next is the call instruction, the switching unit switches from the secure mode to the normal mode, and in the normal mode, the reception unit Receives the identification information, the reading means reads the normal program indicated by the received identification information from the normal storage means, and the processing means operates according to the read normal program. Therefore, by executing the call instruction, the secure program can request the normal program operating in the normal mode for processing. That is, by causing a normal program to execute processing that does not use secure resources, the program size of the secure program itself is reduced. Furthermore, the memory used by the secure program can be reduced in the secure mode.

In the data processing device, the switching means switches from the secure mode to the normal mode by interrupting the secure operating system that controls the secure program and starting the normal operating system that controls the normal program.
According to this configuration, the switching unit starts the normal operating system after interrupting the secure operating system. For this reason, the data processing apparatus can completely realize the secure mode and the normal mode by completely disconnecting the access route to the secure resource while operating in the normal mode.

  The data processing apparatus includes a shared storage area that is allowed to be accessed in both the secure mode and the normal mode, and the output unit writes the identification information in the shared storage area in the secure mode, The identification information is output, and the receiving means receives the identification information by reading the identification information from the shared storage area in a normal mode.

According to this configuration, the shared storage area can be accessed in the normal mode and the secure mode. Therefore, the data processing apparatus of the present invention can implement the secure mode and the normal mode exclusively, and can securely exchange information between the secure mode and the normal mode while protecting the secure resources. .
The reading means stores the identification information and position information indicating the position of the normal program in the normal storage means in association with each other, and the presence indicated by the position information corresponding to the received identification information. The normal program is read from the position.

According to this configuration, since the reading unit stores the identification information and the position information indicating the location of the normal program in the normal storage unit in association with each other, the position information corresponding to the received identification information is used. Thus, the normal program can be read reliably and quickly.
In the data processing apparatus, one processing procedure constituting the normal program includes a plurality of functions constituting a library, and the other processing procedure calls one of the plurality of functions. When operating according to the other processing procedure, the operation is performed according to a function called by the other processing procedure.

  According to this configuration, one processing procedure constituting the normal program includes a plurality of functions constituting the library, and the other processing procedure calls one of the plurality of functions. Accordingly, the secure program can request the normal program to use a function that constitutes the library. For this reason, it is not necessary to hold the library on the memory in the secure mode.

  The data processing apparatus further includes: an instruction acquisition unit that receives a write instruction indicating writing of the secure program to the secure storage unit in the secure mode; and the data processing apparatus, when the write instruction is acquired in the secure mode, A secure load unit that writes the secure program to a secure storage unit and outputs write end information indicating that the write is completed, and the switching unit further outputs the write end information, Switching from the secure mode to the normal mode, the data processing device further includes normal load means for receiving the write end information and writing the normal program in the normal storage means in the normal mode.

  According to this configuration, when the instruction acquisition unit acquires the write instruction, the secure load unit receives the write instruction indicating the writing of the secure program to the secure storage unit in the secure mode. The secure program is written in the storage means, and the normal load means writes the normal program in the normal storage means. By doing so, the normal program is always stored in the normal storage means during execution of the secure program, and when the call instruction included in the secure program is executed, the normal program is promptly stored. You can move on to program execution.

In the normal mode, the reading means constituting the data processing apparatus further includes the identification information and the normal program in the normal storage means when the normal load means writes the normal program in the normal storage means. The position information indicating the existence position of each is stored in association with each other.
In this configuration, when the normal program is written in the normal storage unit, the reading unit stores the identification information and position information indicating the location of the normal program in the normal storage unit in association with each other. . In this way, immediately after loading the secure program, the reading unit stores the identification information and the location information indicating the location of the normal program in the normal storage unit in association with each other. Therefore, when the call instruction included in the secure program is executed, the normal program can be read quickly.

  In the secure mode, the data processing device further includes a deletion instruction acquisition means for acquiring a deletion instruction for instructing deletion of the secure program, and when the deletion instruction is acquired, the data processing apparatus executes the secure program in the secure mode. And a secure deletion unit that outputs deletion end information indicating that the deletion is completed, and the switching unit further switches from the secure mode to the normal mode when the deletion end information is output. In the normal mode, the data processing device further includes normal deletion means for acquiring the deletion end information and deleting the normal program from the normal storage means.

According to this configuration, when the deletion instruction acquisition unit acquires a deletion instruction for instructing deletion of the secure program, the secure deletion unit deletes the secure program from the secure storage unit, and the normal deletion unit performs the normal storage unit. The normal program is deleted from
Therefore, since the normal program does not need to be loaded while the secure program is not loaded, this prevents the normal program from wasting a memory area used in the normal mode. be able to.

In the data processing apparatus, the reading means stores the identification information and position information indicating the location of the normal program in the normal storage means in association with each other, and the position information corresponding to the received identification information The normal program is read from the existing position indicated by.
According to this configuration, since the reading unit stores the identification information and the position information indicating the location of the normal program in the normal storage unit in association with each other, the position information corresponding to the received identification information is used. Thus, the normal program can be read reliably and quickly.

  The data processing device further stores a boot program including an initialization procedure for initializing one or more devices included in the data processing device including the processing means and a startup procedure for starting the secure operating system. Program storage means and initialization means for reading the boot program from the boot program storage means, initializing the device according to the read boot program, and starting a secure operating system after the initialization is completed It is characterized by.

  According to this configuration, the initialization unit initializes the device in accordance with the boot program when power is turned on, and starts the secure operating system after the initialization is completed. As described above, the data processing device of the present invention starts the secure operating system before starting the program executed in the normal mode. Unauthorized use of programs and secure resources executed in secure mode can be prevented.

  The data processing device further includes normal output means for outputting a processing result by the processing means and secure identification information indicating the secure program in the normal mode, and the switching means further outputs the processing result. In the secure mode, the data processing device further switches, in the secure mode, secure receiving means for receiving the processing result and the secure identification information, and the secure processing corresponding to the received secure identification information. Secure reading means for reading the program from the normal storage means, and the processing means further operates in accordance with the secure program using the processing result in a secure mode.

  In this configuration, the normal output means outputs the processing result by the processing means and secure identification information indicating the secure program in the normal mode, and the secure receiving means outputs the processing result and the secure identification information in the secure mode. The secure reading means reads the secure program corresponding to the received secure identification information from the normal storage means, and the processing means further uses the processing result in the secure mode to Works according to. Therefore, in the data processing apparatus of the present invention, the processing unit executes the processing requested by the secure program executed in the secure mode according to the normal program in the normal mode, and the processing result is accurately transferred to the secure program. Can return.

In the data processing device, the switching unit disconnects the secure resource and the processing unit when switching from the secure mode to the normal mode.
According to this configuration, the switching unit disconnects the secure resource and the processing unit when switching from the secure mode to the normal mode. Therefore, in the normal mode, the processing unit can access the secure resource. Can not. Therefore, safety of the secure resource can be ensured.

The switching means encrypts secure information held in the secure resource when switching from the secure mode to the normal mode.
In this configuration, when the switching unit switches from the secure mode to the normal mode, the processing unit uses the secure data in the normal mode in order to encrypt the secure information held in the secure resource. I can't. Therefore, in the normal mode, it is possible to ensure the safety of the secure data held by the secure resource.

In the data processing device, the secure information held in the secure resource includes a program that is executed in a secure mode and includes an instruction code portion, a data portion, and a stack portion. When switching from the mode to the normal mode, the instruction code portion is encrypted.
The switching means encrypts the data portion when switching from the secure mode to the normal mode.

The switching means may encrypt the stack portion when switching from the secure mode to the normal mode.
According to this configuration, the switching unit encrypts the instruction code portion when switching from the secure mode to the normal mode. Alternatively, the switching unit encrypts the data portion when switching from the secure mode to the normal mode. Alternatively, the switching unit encrypts the stack portion when switching from the secure mode to the normal mode.

Thus, by encrypting only the part of the program that needs to be protected, the processing load related to encryption can be reduced.
The data processing device further includes a debug accepting unit that receives a debug operation signal from a debug device that monitors and operates an operation of the processing unit, and the switching unit performs the processing when switching from the secure mode to the normal mode. The processing means and the debug accepting means are disconnected when the means is connected to the debug accepting means and the mode is switched from the normal mode to the secure mode.

According to this configuration, the switching unit disconnects the processing unit and the debug receiving unit when switching from the normal mode to the secure mode. Therefore, the data processing apparatus of the present invention operates during the secure mode, Since the operation is not monitored and operated by an external debugging device, the secure resource can be protected from the debugging device.
In the data processing device of the present invention, the reading unit stores the identification information and position information indicating the location of the normal program in the normal storage unit in association with each other, and corresponds to the received identification information. The normal program may be read from the existing position indicated by the position information.

According to this configuration, since the reading unit stores the identification information and the position information indicating the location of the normal program in the normal storage unit in association with each other, the position information corresponding to the received identification information is used. Thus, the normal program can be read reliably and quickly.
The present invention relates to the data for executing and managing a process by switching between a first operating system and a second operating system, and transitioning a process generated in each operating system to an execution state, an execution wait state, or a sleep state. A processing apparatus, wherein the first operating system generates a first process in the first operating system, and the second operating system generates a second process corresponding to the first process in the second operating system; In the first operating system, first detection means for detecting a state transition of the first process; in the first operating system, first output means for outputting transition information indicating the detected state transition; The first operating system is changed to the second OS switching means for switching to a rating system, second acquisition means for acquiring the transition information in the second operating system, and second transition means for transitioning the state of the second process according to the acquired transition information. It is also a data processing device characterized by comprising.

  According to this configuration, in the first operating system, the first output unit outputs the transition information, and the OS switching unit switches to the second operating system that switches the first operating system to the second operating system. In the second operating system, the second transition means transitions the state of the second process according to the transition information. Therefore, in the data processing apparatus in which two operating systems executed exclusively are operating, the operating state of the first process controlled by the first operating system is changed to the second operating system via the second process. It can also be monitored in the system.

  The data processing apparatus further outputs second detection means for detecting a state transition of the second process in the second operating system and transition information indicating the detected state transition in the second operating system. A second output unit, wherein the OS switching unit further switches the second operating system to the first operating system, and the data processing device further acquires the transition information in the first operating system. And first transition means for transitioning the state of the first process according to the acquired transition information.

  According to this configuration, the second output unit outputs the transition information in the second operating system, and the first transition unit transitions the state of the first process according to the transition information. As a result, the operating state of the second process controlled by the second operating system can also be monitored in the first operating system via the first process. Accordingly, the first operating system and the second operating system can mutually monitor the operating states of the first process and the second process controlled by the first operating system and the second operating system, respectively.

  Further, the data processing device includes a shared storage area accessible in both the first operating system and the second operating system, and the first output means writes the transition information in the shared storage area, The transition information is output, and the second acquisition unit acquires the transition information by reading the transition information from the shared storage area.

  According to this configuration, the first output unit and the second acquisition unit pass the transition information via the accessible shared storage area in both the first operating system and the second operating system. Since the shared storage area is accessible in both the first operating system and the second operating system, the data processing apparatus of the present invention executes the first operating system and the second operating system exclusively. , Information can be passed from the first operating system to the second operating system.

The second output means constituting the data processing device outputs the transition information by writing the transition information to the shared storage area, and the first acquisition means outputs the transition information from the shared storage area. The transition information is acquired by reading.
Accordingly, information can be transferred from the second operating system to the first operating system while exclusively executing the second operating system and the first operating system.

The data processing apparatus includes a device that is managed and operated in the second operating system, the second process is a device driving program that controls driving of the device, and the second detection unit includes the device A state transition of the second process accompanying the operation of the device is detected.
According to this configuration, the second process is a device driving program that controls driving of the device, and the second detection unit detects a state transition of the second process accompanying the operation of the device. Therefore, the first process also invites and changes with the state transition of the device driving program, and the driving state of the device can be monitored also in the first operating system.

  In the first operating system, when the first process transitions from a dormant state to an execution state, the data processing apparatus operates according to the first process that performs exclusive processing to avoid duplication of processing requests to the device. In the first operating system, the first output means outputs the transition information after the exclusion process is completed.

  Normally, such exclusive processing is executed by a device driving program that controls the driving of the device. According to this configuration, in the data processing apparatus, the first process performs duplication of processing requests to the device. In the first operating system, the first output means outputs the transition information after performing an exclusion process that avoids the above. Based on the output transition information, the second process transitions to an execution state and starts controlling the driving of the device. Exclusive processing is assumed assuming that the memory space used by the first operating system and the second operating system is separately required, and particularly when the memory used by the second operating system needs to be protected from external access. Therefore, the second process does not need to perform exclusive processing. Therefore, the memory area used by the second process is reduced due to the exclusive process. For this reason, the memory which needs to be protected is reduced, and the load of the protection mechanism for protecting these memories from the outside can be reduced.

  The data processing apparatus further includes an interrupt detection means for detecting occurrence of an interrupt in the first operating system and the second operating system, and an interrupt is generated when an interrupt is detected in the first operating system. In the interrupt investigating means for investigating the factor and the first operating system, when the interrupt investigating means determines that the interrupt is caused by the device, the interrupt that causes the first process to transition from the sleep state to the execution state. And a transition means.

  Furthermore, the data processing device includes a notification unit that outputs interrupt notification information indicating detection of an interrupt when an interrupt is detected in the second operating system, and the OS switching unit includes the second switching unit. The operating system is switched to the first operating system, the first acquisition means further acquires the interrupt notification information in the first operating system, and the interrupt investigation means further in the first operating system When the interrupt notification information is acquired, an interrupt generation factor is investigated.

  According to this configuration, when an interrupt is detected in the first operating system, the interrupt investigating unit investigates an interrupt occurrence factor. Further, when an interrupt is detected in the second operating system, the notification means outputs interrupt notification information indicating the detection of the interrupt. In the first operating system, the interrupt investigation means generates an interrupt. Investigate the factors.

In this way, it is not necessary to provide an interrupt investigation means under the management of the second operating system. Therefore, the data processing apparatus of the present invention only needs to have one interrupt investigation means.
In the data processing device, when an interrupt is detected, the notification unit causes the interrupt detection unit to stop detecting the interrupt, and the first acquisition unit acquires the interrupt notification information. In this case, the stop is canceled with respect to the interrupt detection means.

  According to this configuration, when the interrupt is detected, the notification unit causes the interrupt detection unit to stop detecting the interrupt, and the first acquisition unit acquires the interrupt notification information. In the case, the stop is released to the interrupt detection means. Therefore, until the first acquisition unit acquires the interrupt notification information output from the notification unit, the interrupt detection unit performs the switching operation from the second operating system to the first operating system. It will not be disturbed. In addition, it is possible to prevent the interrupt detection unit from detecting the same interrupt repeatedly until switching from the second operating system to the first operating system.

  The present invention is the data processing apparatus that operates according to a program, wherein the storage unit stores a program composed of a plurality of processing procedures, and the program stored in the storage unit is illegal. It is also a data processing apparatus comprising: a validity determining unit that determines whether or not the program is invalid; and an invalidating unit that invalidates the program when it is determined to be illegal.

According to this configuration, the validity determination unit determines whether or not the program is illegal, and invalidates the program when it is determined that the invalidation unit is illegal. In the data processing apparatus of the present invention, it is possible to prevent an unauthorized program from being executed.
In the data processing device, the validity judgment unit acquires a program information acquisition unit that acquires program identification information indicating the program stored in the storage unit, and invalidation identification information that indicates a disabled program An invalidation information acquisition unit for determining whether or not the acquired program identification information matches the acquired invalidation identification information. It is determined that it is.

In the above configuration, whether or not the program is illegal is easily determined based on whether or not the program identification information acquired by the information acquisition unit matches the invalidation identification information acquired by the invalidation information acquisition unit. Can be determined.
The program information acquisition unit included in the data processing device of the present invention acquires an identification information storage unit that stores program identification information indicating the program, and reads the program identification information from the identification information storage unit. And the invalidation information acquisition unit includes an invalidation information storage unit storing invalidation identification information indicating the invalidated program, and the invalidation identification information from the invalidation information storage unit. And a reading unit that is acquired by reading.

  According to this configuration, the program information acquisition unit can quickly acquire the program identification information from the identification information storage unit that stores program identification information indicating the program in advance. Further, the invalidation information acquisition unit can quickly acquire the invalidation identification information from the invalidation information storage unit that stores invalidation identification information indicating the invalidated program in advance.

In the data processing device, the validity judgment unit judges whether or not the program is illegal based on a public key certificate that proves the validity of the public key assigned to the program. It is characterized by.
According to this configuration, the validity judgment unit performs the judgment based on the public key certificate that proves the validity of the public key assigned to the program. By using a public key certificate issued by a public third party, the validity of the program can be determined more reliably.

  In the data processing device, the validity judgment unit includes a certificate storage unit storing the public key certificate including public key identification information for identifying the public key, and the public key certificate to the public key Public key information acquisition unit that acquires identification information, invalidation information storage unit that stores invalidation identification information indicating a revoked public key, and invalidation that reads invalidation identification information from the invalidation information storage unit And a determination unit that determines whether or not the acquired public key identification information and the read invalidation identification information match, and the program is invalid if it is determined to match. It is characterized by determining that there exists.

According to the above configuration, the determination unit includes the public key identification information included in the public key certificate stored in the certificate storage unit and the invalidation identification stored in the invalidation information storage unit. By comparing with the information, it is possible to easily determine that the program is illegal.
In the data processing apparatus, the validity judgment unit further includes an update unit that obtains the latest invalidation identification information from the outside and writes the obtained invalidation identification information in the invalidation information storage unit. To do.

  According to this configuration, the update unit acquires the latest invalidation identification information from the outside, and writes the acquired invalidation identification information in the invalidation information storage unit. In general, a public key certificate issuing organization periodically updates the revocation identification information by adding information indicating a public key revoked later. By acquiring and using the latest invalidation identification information from this issuing organization, it is possible to deal with a program that has been found to be illegal after the data processing device is sold.

Further, the update unit acquires the latest invalidation identification information each time an access request to the storage unit is detected.
In the above configuration, each time the update unit detects an access request to the storage unit, the update unit acquires the latest invalidation identification information. Therefore, the determination unit always uses the latest invalidation identification information. Can be judged.

In the data processing device, the updating unit receives the invalidation identification information from a CRL (Certificate Revocation List) issuing device via a network, and receives the invalidation information from the CRL issuing device via the network and a server device. The information is acquired by receiving the invalidation identification information or reading the invalidation identification information from the recording medium.
In the above configuration, the update unit receives the invalidation identification information from the CRL issuing device via the network, and thus can obtain the latest invalidation identification information.

In addition, since the invalidation identification information is received from the CRL issuing device via the network and the server device, even if the data processing device itself does not have a communication function with an external network, The invalidation identification information can be updated.
In addition, by reading the invalidation identification information from the recording medium, the data processing apparatus can update the invalidation identification information even when there is no environment for communication with the CRL issuing apparatus.

The update unit further obtains signature data generated by applying a digital signature to the latest invalidation identification information from the outside, performs signature verification on the acquired signature data, and the signature verification is successful In addition, the acquired invalidation identification information is written in the invalidation information storage unit.
In this configuration, the update unit acquires the signature data, performs signature verification on the acquired signature data, and writes the acquired invalidation identification information in the invalidation information storage unit when the signature verification is successful. Therefore, invalidation identification information issued from a valid issuer of the invalidation identification information can be acquired.

  The validity judgment means constituting the data processing device includes a certificate storage unit storing at least the public key certificate including signature data generated by applying a digital signature to the public key; A public key certificate acquisition unit that acquires the public key certificate from a certificate storage unit, and signature verification is performed on signature data included in the acquired public key certificate so that the acquired public key certificate is A verification unit that verifies whether the program is correct, and determines that the program is invalid when it is determined that the public key certificate is not correct.

  In this configuration, the validity judgment unit verifies whether or not the acquired public key certificate is correct by performing signature verification on the signature data, and the public key certificate is correct. If it is determined that the program is not, the program is determined to be illegal. Therefore, the data processing apparatus can determine whether or not the public key certificate assigned to the program is illegally generated by an unauthorized third party. Only the programs that you have can be executed.

Further, in the data processing device, the validity judgment means uses the program stored in the storage means by using at least two public key certificates that respectively prove the validity of at least two public keys. It may be determined whether or not is illegal.
In this configuration, the validity judgment unit judges whether or not the program stored in the storage unit is illegal using at least two public key certificates. By making the determination using a plurality of public key certificates, it is possible to more accurately determine whether the program is illegal.

  The two public keys are a first public key assigned to the program and a second public key assigned to the data processing apparatus or an operating system that controls the operation of the program, and constitutes the data processing apparatus The legitimacy judging means, which uses a secret key of an authoritative certificate authority, and at least second signature data generated by applying a digital signature to the second public key, and the second public key Including a second public key certificate, a first signature data generated by applying a digital signature to at least the first public key using a secret key of the data processing device or the operating system, A certificate storage unit storing a first public key certificate including a first public key; and the first public key certificate and the second public key certificate are extracted from the certificate storage unit. The public key certificate acquisition unit to perform the signature verification on the second signature data included in the acquired second public key certificate using the public key of the certification authority, thereby acquiring the second public data It is verified whether or not the key certificate is correct. When it is determined that the key certificate is correct, the second public key is acquired from the second public key certificate, and the acquired first public key certificate is included in the acquired first public key certificate. A verification unit that verifies whether or not the acquired first public key certificate is correct by performing signature verification on the included first signature data using the acquired second public key; And determining that the program is invalid when it is determined that the second public key certificate is not correct and when it is determined that the first public key certificate is not correct. To do.

  According to this configuration, the validity judgment unit obtains the obtained signature by performing signature verification on the second signature data included in the obtained second public key certificate using the public key of the certification authority. It is verified whether the second public key certificate is correct, and when it is determined to be correct, the second public key is acquired from the second public key certificate, and the acquired first public key The first signature data included in the certificate is subjected to signature verification using the acquired second public key, thereby verifying whether the acquired first public key certificate is correct. In this way, by verifying using a plurality of public key certificates that form a hierarchical structure, even when the higher-level public key certificate is invalid, that is, when the operating system that controls the program is illegal The program is invalidated to prevent the program from being executed under an unauthorized operating system.

Or even when the data processing device is illegal, the execution of the program can be prevented.
The validity judgment means constituting the data processing apparatus makes the judgment every time an access request to the storage means is detected.
Further, the validity judgment means may make the judgment each time an access request to the program stored in the storage means is detected.

Further, the validity judgment unit may make the judgment immediately after power supply to the data processing apparatus is started.
According to the above configuration, the validity determination unit makes the determination every time an access request to the storage unit is detected. Alternatively, the determination is made each time an access request to the program stored in the storage unit is detected. Alternatively, the determination is made immediately after power supply to the data processing apparatus is started. Therefore, before executing the program, it can be determined whether or not the program is illegal.

  The present invention is also the data processing apparatus for decrypting and executing an encrypted program, wherein the storage means uses a program key instead of the program to apply an encryption algorithm to the program. The validity determination means includes an encryption key storage unit storing m encryption keys selected from p encryption keys, and the m number of encryption programs. A cipher that stores m pieces of encryption information generated by encrypting either the program key or the predetermined detection information using each of the encryption keys in association with the m pieces of encryption keys. A decryption unit that generates a decryption information by applying a decryption algorithm to the corresponding encryption information using each of the encrypted information storage unit, the m encryption keys, and the generated m decryption information Are all detected information A determination unit that determines whether or not the information is generated, and when all of the generated m pieces of decoding information are determined to be the detection information, the program is determined to be invalid. It is characterized by.

  Furthermore, the p encryption keys are arranged at each element position of the first matrix of n rows and m columns (p = n × m), and one encryption key is selected from each column of the first matrix. By doing so, m encryption keys are selected from the first matrix, and the encryption key storage unit constituting the data processing device, in the first matrix, the element position where each encryption key is arranged, Each encryption key is stored in association with each other, and the encryption information storage unit has the same element position as the element position where the encryption key corresponding to each encryption information is arranged in the second matrix of n rows and m columns. The decryption unit reads out the element position corresponding to the encryption key from the encryption key storage unit, and the read element position in the second matrix of the encryption information storage unit Read the encryption information arranged at the same element position as Using serial encryption key, and characterized by applying a decryption algorithm to the encrypted information read.

  According to the above configuration, the legitimacy determining unit performs decryption algorithm on the corresponding encryption information using each of the m encryption keys, generates m decryption information, and generates m pieces of decryption information. When it is determined that all of the decryption information is the detection information, the program is determined to be illegal. When the program is valid, the data processing apparatus generates an encryption key from the encrypted encryption key, decrypts the encrypted program with the generated encryption key, generates a program, and generates the program Execute. In this way, by applying double encryption, the program can be protected from unauthorized use.

  In addition, the p encryption keys are selected by selecting one encryption key from each column of the first matrix. Here, it is assumed that there are a plurality of encrypted programs encrypted with the same program key. Any one of the programs is illegal, and all the m pieces of decryption information generated using the m encryption keys assigned to the illegal program are the detection information. Even if any one of the m cryptographic keys assigned to another legitimate program matches the m cryptographic keys of the unauthorized program, the program key is generated using the other cryptographic key. be able to. By assigning m encryption keys in different combinations for each program, only an illegal program can be invalidated and a legitimate program can be used.

  Further, the present invention provides the data processing apparatus, comprising a memory means for storing data, a processor that operates according to a program composed of a plurality of processing procedures, and is arranged between the memory means and the processor. And determining whether or not the transfer data addressed to the memory means output from the processor satisfies a transfer restriction condition, and if it is determined that the transfer restriction condition is satisfied, the transfer data to the memory means And a monitoring unit that transfers the transfer data to the memory unit when it is determined that the transfer is suppressed and the transfer restriction condition is not satisfied.

  According to this configuration, the monitoring unit is arranged between the memory unit and the processor, and determines whether or not the transfer data addressed to the memory unit output from the processor satisfies a transfer restriction condition, When it is determined that the transfer restriction condition is satisfied, transfer of transfer data to the memory means is suppressed. In this way, unauthorized access to the memory that occurs during the operation of the program can be prevented.

In the data processing apparatus, the monitoring unit stores transfer restriction conditions for each of a plurality of application programs, selects a transfer restriction condition for each application program executed by the processor, and selects the selected transfer restriction condition. It is characterized by using.
In this configuration, the monitoring unit selects a transfer restriction condition for each application program executed by the processor, and uses the selected transfer restriction condition. In the data processing apparatus, when a plurality of application programs are executed, it is sufficiently conceivable that data and devices used for each application are different. Therefore, by using different transfer restriction conditions for each application program, the data processing apparatus can safely execute a plurality of application programs.

Further, the transfer restriction condition is address range information indicating a predetermined storage space in the memory means, and the data processing device extracts the address information extracted from the transfer data by the monitoring means. Is included in the address range information, the transfer of the transfer data is suppressed.
According to the above configuration, the monitoring unit suppresses transfer of the transfer data when the extracted address information is included in the address range information. Therefore, the processor can be prevented from accessing the predetermined storage space.

  The transfer restriction condition is a restriction number indicating an upper limit of the number of accesses to a predetermined storage space in the memory means, and the monitoring means constituting the data processing device is configured to accumulate the access to the storage space in the past. The number of times is stored, the address information is extracted from the transfer data, and when the extracted address information is included in the address range information, 1 is added to the cumulative number, and after the addition obtained by addition When the number of times exceeds the limit number, transfer of the transfer data is suppressed.

  According to this configuration, the monitoring unit suppresses transfer of the transfer data when the number of times after the addition exceeds the limit number. In this way, an unauthorized access that occurs accidentally for some reason during the execution of the program is overlooked. For example, unauthorized access to the predetermined storage space by unauthorized alteration of the program is illegal. Only when access occurs, transfer of transfer data accompanying execution of the program is suppressed.

In the present invention, the monitoring means determines whether or not the transfer data transferred on a bus connected to the processor satisfies a transfer restriction condition.
According to this configuration, the monitoring means determines whether or not the transfer data transferred on the bus connected to the processor satisfies a transfer restriction condition, so that each time transmission data is output from the processor. In addition, the determination can be performed reliably.

  The memory means constituting the data processing apparatus of the present invention is generated by encrypting a code part and a data part of an application program different from the current program being executed by the processor, using an encryption key. An encryption code and encrypted data are stored, and the transfer restriction condition is address range information indicating a storage space in which the encrypted data is stored in the memory means, and the monitoring means A decryption key for decrypting the encrypted code and the encrypted data, extracting address information from the transfer data, and the extracted address information indicating an address range indicating a storage space in which the encrypted code is stored An encryption code that exists in the storage space indicated by the transfer data using the decryption key. Decoded to generate a decoded code, the generated decrypted code is transferred to the processor, extracted address information, if included in the address range information, which comprises suppressing the transmission of the transfer data.

  According to this configuration, the monitoring unit stores a decryption key for decrypting the encrypted code and encrypted data, and the address information indicates an address indicating a storage space in which the encrypted code is stored. If it is within the range, the decryption key is used to decrypt the encrypted code present in the storage space indicated by the transfer data to generate a decrypted code, and the generated decrypted code is transferred to the processor for extraction. When the address information is included in the address range information, transfer of transfer data is suppressed. Thereby, the use of the data part of the application program can be limited to the application program.

The monitoring means further adds identification information for identifying the program being executed by the processor to the program invalidation list when determining that the transfer restriction condition is satisfied.
In this configuration, when the monitoring unit determines that the transfer restriction condition is satisfied, the processor adds the identification information for identifying the program being executed by the processor to the program invalidation list. Can be prevented from being executed again.

  The data processing apparatus according to the present invention includes a memory means for storing data, and a program counter that operates according to a program composed of a plurality of processing procedures and stores the address of an instruction to be executed next. It is determined whether or not an address stored in the processor and the program counter is included in a predetermined address range, and when it is determined that the address is included in a predetermined address range, a program is sent to the processor. Monitoring means for instructing the counter to store a predetermined value, and the processor stores the predetermined value in the program counter when receiving the instruction.

  According to this configuration, the monitoring unit determines whether the address stored in the program counter is included in a predetermined address range, and determines that the address is included in a predetermined address range. Instructs the processor to store a predetermined value in the program counter. In this way, the processor prevents the access to the storage area corresponding to the predetermined address range in advance, for example, by transferring the execution right of the processor to another program such as an operating system, The execution of the program can be interrupted.

Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.
1. Embodiment 1
Embodiments of the present invention will be described below.
FIG. 1 shows an example of use of the mobile phone 100 of the present invention. The mobile phone 100 is loaded with a memory card 300.

The memory card 300 stores encrypted music data, and the mobile phone 100 reads the music data from the memory card 300 and plays it back.
The mobile phone 100 is connected to a content distribution apparatus via the base station 15, the mobile phone network 10, and the Internet 20. The mobile phone 100 acquires various contents composed of music, video, and the like stored in the content distribution apparatus via the Internet and a mobile phone network.

1.1 Memory card 300
As illustrated in FIG. 2, the memory card 300 includes an input / output unit 301, a secure processing unit 302, a general area 303, and a secure area 306.
The general area 303 is a storage area that can be freely accessed by an external device, and stores encrypted music data 304. The secure area 306 is a storage area that can be accessed only by authorized external devices, and stores a content key 307.

The encrypted music data 304... Is generated by applying the encryption algorithm E1 to the music data for one song using the content key 307. Each encrypted music data is identified by a music ID.
As an example, the encryption algorithm E1 uses DES (Data Encryption Standard).

The input / output unit 301 inputs / outputs various data between the external device and the general area 303 and the secure processing unit 302.
The secure processing unit 302 performs mutual authentication with an external device based on a CPRM (Content Protection for Recordable Media) mechanism, and shares the key with the authenticated device when the authentication is successful. Use the shared key to safely input and output data with external devices.

Since CPRM is publicly known, description thereof is omitted. Moreover, you may authenticate with another authentication method.
1.2 Configuration of Mobile Phone 100 As shown in FIG. 2, the mobile phone 100 includes a debugger IF 101, a CPU 102, an MMU 103, a secondary storage unit 104, a switching control unit 106, an interrupt controller 107, an input unit 108, and a display unit 109. , Normal memory 111, shared memory 112, secure memory 113, memory protection unit 114, input / output unit 116, cryptographic processing device 117, wireless communication control unit 118, microphone 119, speaker 120, communication unit 121, antenna 122, buffer 123, The circuit includes a code processing unit 124 and a D / A conversion unit 126, and each circuit is connected to the bus 130.

The cellular phone 100 is specifically a computer system. Various computer programs are stored in the normal memory 111, the shared memory 112, the secure memory 113, and the secondary storage unit 104, and the CPU 102 operates according to these computer programs. As a result, the mobile phone 100 realizes a part of its functions.
(1) Secondary storage unit 104 and shared memory 112
The secondary storage unit 104 includes a ROM, and stores an encrypted music decryption program 141, a music decryption daemon 142, and the like as shown in FIG. 3 as an example.

The encrypted music decryption program 141 is generated by encrypting a music decryption program that is loaded onto the secure memory 113 and executed. The music decryption program is a program for decrypting the encrypted music data 304 stored in the memory card 300. This will be described in detail later.
The music decryption daemon 142 is a program that is loaded on the normal memory 111 and executed, and has a one-to-one correspondence with the music decryption program.

Of the music decryption processes, the music decryption program executes a process that requires high security and a process that handles data to be protected, and the music decryption daemon executes a process that does not require high security. Details will be described later.
The shared memory 112 is composed of a RAM, and is a memory that can be used by both the program on the normal memory 111 and the program on the secure storage.

Here, the secondary storage unit 104 is configured by a ROM, but may be configured by a hard disk unit.
(2) Normal memory 111 and secure memory 113
The normal memory 111 includes a RAM and a ROM, and stores various programs executed by the CPU 102. As an example, as shown in FIG. 4, a normal OS 151, a library 152, a music playback program 153, a music decryption daemon 156, a normal input / output device driver 157, a secure input / output entry device driver 158, a cryptographic entry device driver 159, a normal switching device The driver 160 and the normal interrupt handler 161 are stored.

The secure memory 113 is composed of a RAM, and stores various programs executed by the CPU 102. The secure memory 113 is connected to the bus 130 via the memory protection unit 114.
As an example, the secure memory 113 stores a secure OS 171, a music decryption program 176, a secure input / output device driver 178, an encryption device driver 179, a secure switching device driver 180, and a secure interrupt handler 181 as shown in FIG. Yes.

  FIG. 8 is a block diagram functionally showing the relationship between the programs stored in the normal memory 111 and the secure memory 113. Actually, communication between programs on the same memory is realized by outputting a system call to the normal OS 151 and the secure OS 171. Further, the normal switching device driver 160, the secure switching device driver 180, and the switching control unit 106 operate to switch between the normal OS 151 and the secure OS 171, but in FIG. 8, the mediation by the operating system and the normal OS 151 and the secure OS 171 are secured. A program for switching to the OS 171 is omitted.

In FIG. 8, the shared memory 112 is connected to the normal input / output device 132 and the cryptographic processing device 117, which shows a part of the role played by the shared memory 112. Also used by other programs.
<Normal OS 151>
The normal OS 151 is basic software that controls various programs that are loaded on the normal memory 111 and executed, and includes a control program and control data.

The control data includes an application management table 166 as shown in FIG. The application management table 166 includes a plurality of entries 167, 168... As shown in FIG. Each entry includes a handle value, a daemon address, and an application context address.
The handle value is an identifier assigned to a secure application loaded on the secure memory 113.

In the following description, an application loaded on the secure memory 113 and executing secure processing is referred to as a secure application. Here, the secure processing is processing that handles data to be protected and processing that needs to protect the algorithm itself.
The daemon address is a load address on the normal memory 111 of a program that operates corresponding to the secure application.

The application context address is an address on the normal memory 111 that stores the context of the application that requests secure processing to the secure application corresponding to the handle value. The context includes a register value of the CPU 102, a stack pointer, the contents of the MMU 103, and the like.
Specifically, the entry 167 is described. The handle value “1” is an identifier assigned to a music decryption program 176 (described later) requested by the music playback program 153 to perform secure processing. The daemon address “0000BBBB” is a load address on the normal memory 111 of the music decryption daemon 156 that operates corresponding to the music decryption program 176. The application context address “0000AAEE” is an address on the normal memory 111 that stores the context of the music playback program 153.

 The control data includes device ID_A, which is an identification information device indicating the normal input / output device driver 157, device ID_B, which is identification information identifying the secure input / output entry device driver 158, and identification information indicating the encryption entry device driver 159. Device ID_C is included. These are stored in association with the load addresses on the normal memory 111 of the normal input / output device driver 157, the secure input / output entry device driver 158, and the encryption entry device driver 159, respectively. The device ID_B is the same as the identification information indicating the secure input / output device driver 178 (described later), and the device ID_C is the same as the identification information indicating the encryption device driver 179.

  The normal OS 151 transmits and receives various commands to and from the secure OS 171 via a predetermined area (referred to as a command area) in the shared memory 112. Various commands are also transmitted to and received from the program on the normal memory 111. The shared memory 112 may be used for the transmission / reception of the program with the program on the normal memory 111, or the normal memory 111 may be used.

FIG. 9A shows an example of the data structure of a command handled by the normal OS 151. The command 1000 includes a command part 1011 and a data storage part 1012.
Commands stored in the command unit 1011 include a secure application registration request, a registration completion notification, an application return request, a secure application deletion command, a deletion completion notification, a system call, a response notification, a secure processing request, an external processing request, a sleep request, There is an interrupt notification.

In the data storage unit 1012, various data and commands 1016, identification information 1013 indicating programs to receive the data and commands 1016, and the like are stored according to the commands stored in the command unit 1011.
The secure application registration request is a command for requesting that an application operating on the normal memory 111 loads the secure application for which secure processing is requested onto the secure memory 113 and makes it usable. At this time, as shown in FIG. 9B, the data storage unit 1012 stores secure application information indicating a secure application and daemon information indicating a program operating in correspondence with the secure application. Taking the secure application registration request output from the music playback program 153 as an example, the secure application information is the address stored in the encrypted music decryption program 141 on the secondary storage unit 104, and the daemon information is the music decryption This is a stored address of the daemon 142. The secure application information and the daemon information may be identifiers corresponding to the encrypted music decryption program 141 and the music decryption daemon 142.

The registration completion notification notifies that a secure application is loaded on the secure memory 113 and registration in a secure application management table (described later) is completed. At this time, the data storage unit 1012 stores a handle value corresponding to the registered secure application.
The application return request is a command for requesting the return of the requesting application by the secure application that has completed the requested processing. At this time, identification information indicating a secure application is stored in the data storage unit.

The secure application deletion instruction is for instructing deletion of the secure application on the secure memory 113. At this time, the data storage unit 1012 stores a handle value that uniquely identifies the secure application to be deleted.
The deletion completion notification notifies that the secure application on the secure memory 113 has been deleted. At this time, the data storage unit 1012 stores a handle value that uniquely identifies the deleted secure application.

  The system call is a command in which an application on the normal memory 111 requests the normal OS 151 to send another command or data mediation to another program on the normal memory 111. At this time, in the data storage unit 1012, identification information indicating the application that requested the mediation, identification information indicating the program of the mediation destination, data and commands to mediate are written.

  As an example, FIG. 9C shows a data structure of a system call output by the music decryption daemon 156. The command unit 1011 stores a system call, and the data storage unit 1012 stores a handle value “1” indicating the music decryption daemon 156 that is the transmission source of the system call, and the encryption entry device that is the data reception destination. A device ID_C indicating the driver 159 and data “process result” to be mediated are stored.

  In response notification, a program that has received a command or data from an application through a system call performs processing according to the received command and data, and requests the normal OS 151 to notify the processing result to the application that has output the system call. is there. The data storage unit 1012 stores identification information indicating a program for which a notification is requested, identification information indicating a notification destination application, processing results, and the like.

  As an example, the cryptographic entry device driver 159 that has received the handle value “1”, the device ID_C, and the processing result by the system call shown in FIG. 9C cancels the exclusive control (details will be described later). 1 ”, the response notification including the device ID_C and the processing result is output to the normal OS 151, and the handle value“ 1 ”, the device ID_C, and the processing result are notified to the music decryption daemon 156 via the normal OS 151 (details will be described later). To do).

  The secure processing request is a command for requesting a command or data mediation from a program on the normal memory 111 to a program on the secure memory 113. At this time, the data storage unit 1012 stores identification information indicating the program that is the output source of the secure processing request, information indicating the program of the mediation destination, and data and commands to mediate. FIG. 9D shows the data structure of the secure processing request output from the music decryption daemon 156 as an example. In the data storage unit 1012, the handle value “1” indicating the music decryption daemon 156 that is the output source of the secure processing request, the device ID_C indicating the encryption device driver 179 that is the reception destination, and the intervening command “interrupt notification” And are stored.

  The external processing request is a request for mediation of a command and data from the program on the secure memory 113 to the program on the normal memory 111. At this time, the data storage unit 1012 stores identification information indicating the program that is the output source of the secure processing request, identification information indicating the broker program, and data and commands to be mediated. FIG. 9E shows the data structure of an external processing request output from the cryptographic device driver 179 as an example. The command unit stores an external processing request, and the data storage unit has a device ID_C corresponding to the encryption device driver 179 that is the output source of the external processing request and a handle corresponding to the music decryption daemon 156 that is the reception destination. The value “1” and the intervening command “sleep request” are stored.

The sleep request is a command for requesting the device driver of the device included in the mobile phone 100 and a program requested to process the device to transition to the sleep state. At this time, the data storage unit 1012 stores identification information indicating a device driver that requests a sleep request, and identification information corresponding to a program that requests the device to perform processing.
The interrupt occurrence notification notifies the occurrence of an interrupt.

The operation of the normal OS 151 will be described below using the flowchart of FIG. Note that the normal OS 151 executes various processes in addition to the processes described in this flowchart.
Here, regarding the secure application registration request, registration completion notification, application return request, secure application deletion command, and deletion completion notification, specifically, the application on the normal memory 111 is the music playback program 153, and the secure application is the music decryption program 176. A program that operates in a pair with the secure application will be described as a music decryption daemon 156.

When the normal OS 151 returns to the CPU 102 by the switching process, it reads the command from the command area of the shared memory 112 (step S1001). The switching process will be described in detail in the description of the normal switching device driver 160 and the secure switching device driver 180 below.
The read command is decoded (step S1002), and if the decoded command is a registration completion notification, the music decoding daemon 156 is loaded onto the normal memory 111 (step S1004), and the loaded address and registration completion notification data are stored. The handle value “1” received in the section is written in the entry 167 of the application management table 166 (step S1005), and the handle value “1” is output to the music playback program 153.

If the read command is an external processing request (step S1002), the program corresponding to the identification information indicating the mediation destination included in the data storage unit is called and received in the data storage unit of the external processing request to the called program. Information is output (step S1006).
If the read command is an interrupt generation notification (step S1002), the interrupt mask is canceled by deleting the dummy data written in the interrupt register of the CPU 102 (step S1007). The interrupt mask will be described later in the description of the secure interrupt handler 181.

If the read command is an application return request (step S1002), the context of the music playback program 153 is returned based on the handle value “1” included in the data storage unit and the application management table 166 (step S1009). ).
If the read command is a deletion completion notification (step S1002), the music decryption daemon 156 corresponding to the handle value “1” included in the data storage unit is deleted from the normal memory 111 (step S1011), and the application management table 166 is deleted. Entry 167 including the handle value “1” is deleted (step S1012).

Next, a command from each program on the normal memory 111 is accepted (step S1013).
When a system call is received (step S1013), a program corresponding to identification information indicating a mediation destination such as a handle value or a device ID written in the data storage unit is called and information included in the data storage unit is output (step S1013). S1014). For example, if the handle value “1” is included, the entry 167 including the handle value “1” is selected in the application management table 166, and the music decryption daemon 156 is called based on the daemon address of the selected entry 167, and the device If ID_C is included, the cryptographic entry device driver 159 is called.

Although not specifically shown, even when a response notification is received, the application corresponding to the identification information written in the data storage unit is called as in the case of receiving the system call, and the data storage unit The information contained in is output.
When the sleep request is received (step S1013), the program corresponding to the identification information such as the handle value or device ID written in the data storage unit is shifted to the sleep state (step S1016). The sleep state refers to a state in which no operation is performed.

  When a secure application registration request including secure application information and daemon information is received in the data storage unit as shown in FIG. 9B from the music decryption program 176 (step S1013), the context of the music playback program 153 is stored in the normal memory 111. Then, the storage destination address is written in the application context address, and the encrypted music decryption program 141 read from the secondary storage unit 104 based on the secure application information is written in the shared memory 112 (step S1017). Next, a secure application registration request is written on the shared memory 112 (step S1018), and the process proceeds to step S1028. The secure application registration request at this time includes the address of the write destination on the shared memory 112 of the encrypted music decryption program in the data storage unit.

When a secure application deletion command is received from the music playback program 153 (step S1013), the received secure application deletion command is written into the shared memory 112 (step S1019). Here, a handle value “1” indicating the music decryption program 176 to be deleted is stored in the data storage unit.
When a secure processing request is received (step S1013), the received secure processing request is written into the shared memory 112 (step S1021). Next, a switching process is performed (step S1028).

Further, when an interrupt occurs and an interrupt occurrence notification is received from the interrupt controller 107 (step S1023), the normal interrupt handler 161 is activated (step S1024). Based on the investigation result of the interrupt factor by the normal interrupt handler 161, the sleep of the sleeping program is canceled (step S1026). The process moves to step S1013.
In this embodiment, the normal OS 151 and the secure OS 171 exchange various commands via the shared memory 112, but a dedicated register may be used instead of the shared memory 112.
<Secure OS 171>
As shown in FIG. 6, the secure OS 171 includes an operating program 172, a debug invalidation program 173, and an encryption / decryption program 174.

The debug invalidation program 173 is a program for invalidating the debugger IF 101 by writing dummy data to the register of the debugger IF 101. Note that a switch may be provided between the debugger IF 101 and the CPU 102, and the debug invalidation program 173 may be configured to invalidate the debugger IF 101 by opening and closing this switch.
The encryption / decryption program 174 is previously coded with a decryption key, and decrypts the encrypted music decryption program to generate a music decryption program.

The operating program 172 is basic software that controls various programs loaded on the secure memory 113, and includes a control program and control data. As shown in FIG. 6, the control unit data includes a secure application management table 186.
As shown in FIG. 7, the secure application management table 186 includes a plurality of entries 187, 188. Each entry includes a handle value, a secure application address, and a secure application context address, and corresponds to a secure application loaded on the secure memory 113.

The handle value is an identifier assigned to each secure application.
The secure application address is an address on the secure memory 113 where the secure application is loaded. The secure application context address is an address on the secure memory 113 in which the context of the secure application is stored.

  As an example, the handle value “1” of the entry 187 is an identifier assigned to the music decryption program 176 by the operating program 172. The secure application address “1111EEEE” is an address on the secure memory 113 in which the music decryption program 176 is stored, and the secure application context address “11AADDDE” is on the secure memory 113 in which the context of the music decryption program 176 is stored. Address.

The control data includes device ID_B that is identification information corresponding to the secure input / output device driver 178 and device ID_C that is identification information corresponding to the encryption device driver 179. These are stored on the secure memory 113 in association with the load addresses on the secure memory 113 of the secure input / output device driver 178 and the encryption device driver 179, respectively.
Here, the device ID_B and the device ID_C are the same as the device ID_B and the device ID_C included in the control data of the normal OS 151.

The secure OS 171 exchanges various commands with the normal OS 151 via the command area of the shared memory 112. In addition, commands are transmitted to and received from each program on the secure memory 113 via the storage area of the operating program 172 on the secure memory 113.
In the following description, for the sake of convenience of explanation, processing performed by the operating program 172 is expressed as processing performed by the secure OS 171.

  The various commands handled by the secure OS 171 have the structure shown in FIG. 9A, like the commands handled by the normal OS 151. The commands stored in the command unit 1011 include secure application registration request, registration completion notification, application restoration request, secure application deletion command, deletion completion notification, system call, response notification, secure processing request, external processing request, and interrupt generation. There are notifications. The secure application registration request, registration completion notification, application return request, secure application deletion command, deletion completion notification, secure processing request, external processing request, and interrupt occurrence notification are as described above in the description of the normal OS 151. . The system call is a request for mediation of data and commands from an application on the secure memory 113 to another program on the secure memory 113, and the response notification is sent from the program that received the command and data by the system call. The secure OS 171 is requested to notify the processing result and the like.

  The operation of the secure OS 171 will be described below using the flowchart of FIG. Here, regarding the secure application registration request, registration completion notification, secure application deletion command, and deletion completion notification, specifically, the application operates as a pair with the music playback program 153, the secure application as the music decryption program 176, and the secure application. The program to be performed will be described as a music decryption daemon 156. The secure OS 171 performs various types of processing other than the processing shown in this flowchart, but is not described here because it is not related to the present invention.

Through the switching process, the secure OS 171 returns to the CPU 102 (step S1041). The secure OS 171 reads and decodes the command from the command area of the shared memory 112 (step S1042), and performs the following processing according to the decoded command.
If the read command is a secure application registration request (step S1042), the encryption / decryption program 174 decrypts the encrypted music decryption program on the shared memory 112 to generate the music decryption program 176 and loads it onto the secure memory 113. (Step S1043). The load address and the handle value “1” are written in the entry 187 of the secure application management table 186 (step S1044). Next, the registration completion notification is stored in the command portion, and the registration completion notification is generated with the handle value “1” stored in the data storage portion, and is written in the shared memory 112 (step S1046). Next, the process proceeds to a switching process (step S1062).

  If the decrypted command is a secure processing request (step S1042), a program corresponding to the identification information of the program to be received stored in the data storage unit is called (step S1047). For example, if the handle value “1” is stored, the music playback program 153 is called, and if the device ID_B is stored, the secure input / output device driver 178 is called. Next, the process proceeds to step S1052.

  If the read command is a secure application deletion command (step S1042), a handle value “1” indicating a program to be deleted stored in the data storage unit is extracted, and the extracted handle value “1” is set. The corresponding music decryption program 176 is deleted from the secure memory 113, and then the entry 187 is deleted from the secure application management table 186 (step S1049).

When the deletion is completed, a deletion completion notification is written in the shared memory 112 (step S1051). At this time, a deletion completion notification is stored in the command portion, and a handle value “1” is stored in the data storage portion. Next, the process proceeds to step S1062.
Next, the secure OS 171 receives a command from each program on the secure memory 113 (step S1052).

If the received command is an external processing request (step S1052), the received external processing request is written in the shared memory (step S1053), and the process proceeds to step S1062.
When an interrupt occurrence notification indicating that an interrupt has occurred in any device is received from the secure interrupt handler 181 (described later), the received interrupt occurrence notification is written to the shared memory 112 (step S1054). The process moves to step S1062.

If the received command is a system call (step S1052), the corresponding program is called by the identification information indicating the receiving destination program stored in the data storage unit (step S1056).
If the received command is an application return request (step S1052), the received application return request is written in the shared memory (step S1061), and the process proceeds to step S1062. Although not specifically shown, in the case of a response notification, an application corresponding to the identification information included in the data storage unit is similarly called.

In the middle of these processes, when an interrupt occurs and an interrupt occurrence notification is received from the interrupt controller 107 (step S1057), the secure interrupt handler 181 is activated (step S1059) and the process returns to step S1052.
<Library 152>
The library 152 includes functions that are commonly used by various programs. As an example, the library 152 includes an access function for accessing the memory card 300. The access function is a function for calling the normal input / output device driver 157 and instructing reading of data.
<Music playback program 153>
The music reproduction program 153 is an application that includes various image data to be displayed to the user and reproduces music stored in the memory card 300 in response to the user's operation. In the music playback program 153, secure application information and daemon information are coded in advance. The secure application information is information indicating a program for which the music playback program 153 requests secure processing, and specifically, an address on the secondary storage unit 104 in which the encrypted music decryption program 141 is stored. . The daemon information is information indicating a program that is paired with the program indicated by the secure application information. Specifically, the daemon information is an address on the secondary storage unit 104 in which the music decryption daemon 142 is stored.
<Music Decoding Program 176 and Music Decoding Daemon 156>
The music decryption program 176 and the music decryption daemon 156 operate in a pair to achieve decryption processing of the encrypted music data.

  The music decryption program 176 receives a decryption command from the music playback program 153 via the normal OS 151 and the secure OS 171 and, as shown in FIG. 8, undergoes a data read step, a content key read step, a decryption step, and a music data output step. Music data is generated, and in the music data output step, the music data write destination address on the buffer 123 is output as a processing result.

  Of these processes, the music decryption daemon 156 is requested to perform a process that does not require high security. Specifically, a data read command is output to the music decryption daemon 156 by outputting an external processing request to the secure OS 171. As a result of the processing, the write destination address of the encrypted music data on the shared memory 112 is received. Further, in response to an external processing request to the secure OS 171, a decryption command is output to the music decryption daemon 156, and a music data write destination address on the buffer 123 is acquired as a processing result.

  The music decryption daemon 156 receives a data read command and a decryption command from the music decryption program 176 via the secure OS 171 and the normal OS 151. Various commands and data are received from the normal input / output device driver 157, the secure input / output entry device driver 158, the cryptographic entry device driver 159, the secure input / output device driver 178, and the cryptographic device driver 179. Various processes are performed based on the received command and data. Processing performed by the music decryption daemon 156 will be described with reference to the flowchart of FIG. Although omitted in FIG. 9, all commands and data received by the music decryption daemon 156 include a handle value “1” as identification information indicating the music decryption daemon 156 that is the recipient. .

Various commands and data are received via the secure OS 171 (step S011). The received instruction is determined (step S012), and if it is a data read instruction, the access function of the library 152 is called (step S013).
When device ID_A and the processing result are received as identification information indicating the output source of the command, the received processing result is output to the music decoding program 176 by an external processing request (step S014). At this time, the processing result and the handle value “1” indicating the receiving destination are stored in the data storage unit.

  When the device ID_B indicating the command output source and the sleep request are received (step S012), the received sleep request is output to the secure input / output entry device driver 158 by a system call to the normal OS 151 (step S015). At this time, the data storage unit stores the received device ID_B as identification information indicating the receiving destination, and stores a handle value “1” indicating the music decoding daemon 156 itself as identification information indicating the output source of the system call. To do.

  When the device ID_B indicating the output source of the command and the interrupt notification are received (step S012), the handle value “indicating the received interrupt notification, the device ID_B, and the music decryption daemon 156 itself is stored in the secure processing request data storage unit. 1 "is stored and output to the normal OS, so that the received interrupt notification is output to the secure input / output device driver 178 (step S016).

When a decryption instruction is received from the music decryption program 176 via the secure OS 171 and the normal OS 151, the decryption instruction is output to the encryption entry device driver 159 by a system call (step S017).
When the device ID_C and the decryption command are received from the cryptographic entry device driver 159 by the response notification (step S012), the received decryption command is output to the cryptographic device driver 179 by the secure processing request. At this time, the decryption command, the received device ID_C, and the handle value “1” indicating the music decryption daemon 156 itself are stored in the data storage unit (step S018).

  When the device ID_C and the sleep request are received from the normal OS 151, the received sleep request is output to the cryptographic entry device driver 159 by a system call (step S019). At this time, the device ID_C received as identification information indicating the recipient, the handle value “1” indicating the music decryption daemon 156 itself, and the sleep request are stored in the data storage unit.

  When the device ID_C and the interrupt notification are received from the cryptographic entry device driver 159 by the response notification (step S012), the received interrupt notification is output to the cryptographic device driver 179 by the secure processing request (step S021). The data storage unit stores the received device ID_C, the interrupt notification, and the handle value “1” indicating the music decryption daemon 156 itself.

When the device ID_C and the processing result are received from the normal OS 151, the received processing result is output to the cryptographic entry device driver 159 by a system call (step S022).
When the device ID_C and the processing result are received from the encryption entry device driver 159 by the response notification, the processing result received by the secure processing request is output to the music decryption program 176 (step S023).
<Normal input / output device driver 157>
The normal input / output device driver 157 has a device ID_A as identification information indicating the normal input / output device driver 157 itself.

The normal input / output device driver 157 is a program that controls the normal input / output device 132 configuring the input / output unit 116.
The normal input / output device driver 157 stores an exclusive flag. The exclusive flag “1” is set when the normal input / output device 132 is operating, and the exclusive flag “0” is set when the normal input / output device 132 is not operating. If the exclusive flag is “1” when the input / output processing command is received, an error notification indicating that the normal input / output device 132 is operating and cannot accept the processing is output.
<Secure I / O Entry Device Driver 158 and Secure I / O Device Driver 178>
The secure input / output device driver 178 and the secure input / output entry device driver 158 have the same identification information and device ID_B in advance.

  The secure input / output device 133 operates normally when the secure input / output device driver 178 and the secure input / output entry device driver 158 control in pairs. The secure input / output device driver 178 requests an input / output process, which is a secure process, and acquires a processing result in the control of the secure input / output device 133. The secure input / output entry device driver 158 requires high security. Detect sleep and interrupt, which is a process that does not.

  In the present embodiment, the secure input / output device driver 178 receives a content key read command from the music decryption program 176 via the secure OS 171. When the content key read command is received, the cryptographic processing device 117 is instructed to read the content key. Next, by outputting an external processing request to the secure OS 171, a sleep request is output to the music decryption daemon 156. At this time, the command data storage unit stores the sleep request, the handle value “1” received from the music decryption program 176 as identification information indicating the recipient, and the secure input / output device driver as identification information indicating the output source of the command. The device ID_B indicating 178 itself is stored.

Next, the secure input / output device driver 178 receives an interrupt notification from the music decryption daemon 156 via the secure OS 171 and acquires the address where the content key is stored as the processing result from the secure input / output device 133. The acquired processing result is output to the music decryption program 176 by a response notification to the secure OS 171.
The secure input / output entry device driver 158 receives a sleep request from the music decryption daemon 156 via the normal OS 151. When the sleep request is received, a sleep request including the handle value “1” and the device ID_B is output to the data storage unit to the normal OS 151.

Next, when the sleep is canceled by the normal OS 151, the cure input / output entry device driver 158 outputs an interrupt notification to the music decryption daemon 156 via the normal OS 151 by a response notification. At this time, the “sleeping request”, the device ID_B, and the handle value “1” are stored in the data storage unit.
<Cryptographic device driver 179 and cryptographic entry device driver 159>
The cryptographic device driver 179 and the cryptographic entry device driver 159 have a device ID_C as identification information in advance.

  The cryptographic processing device 117 can operate normally by controlling the cryptographic device driver 179 and the cryptographic entry device driver 159 as a pair. Among the controls of the cryptographic processing device 117, the cryptographic device driver 179 performs a request for decryption processing and obtains a processing result, and the cryptographic entry device driver 159 performs exclusive control, sleep and interrupt notification.

  In the present embodiment, specifically, the encryption entry device driver 159 receives a decryption command from the music decryption daemon 156 by a system call. When a decryption instruction is received, exclusive control using an exclusive flag is performed. That is, if the exclusion flag is “1”, an error notification is output, and the following processing is stopped. If the exclusion flag is “0”, the exclusion flag is changed to “1”.

Next, a response notification including the received decryption instruction, the handle value “1”, and the device ID_C of the encryption entry device driver 159 itself in the data storage unit is output to the normal OS 151, whereby the decryption instruction is sent to the music decryption daemon 156. Output.
Next, a sleep request is received from the music decryption daemon 156 by a system call. Next, a sleep request is output to the normal OS 151. At this time, the handle value “1” and the device ID_C received in the system call are stored in the data storage unit of the sleep request.

Next, the sleep is canceled by the normal OS. The sleep is canceled and an interrupt notification is output to the music decryption daemon 156 by a response notification.
Next, the processing result is received from the music decryption daemon 156 via the normal OS 151. When the processing result is received, the exclusive control is canceled and the exclusive flag is returned to “0”. In response to the notification, the received processing result is output to the music decryption daemon 156.

  The cryptographic device driver 179 receives a decryption processing command from the music decryption daemon 156 via the secure OS 171 in response to a secure processing request, and requests the cryptographic processing device 117 to perform decryption. Next, the device ID_C possessed by the cryptographic device driver 179 itself, the handle value “1” received together with the decryption processing instruction, and the external processing request storing the sleep request in the data storage unit are output to the secure OS 171.

  Next, in response to a secure processing request to the secure OS 171, an interrupt notification is received from the music decryption daemon 156, and a write destination address on the buffer 123 is received from the cryptographic processing device 117 as a processing result. By outputting the received processing result, the handle value “1”, the device ID_C, and the external processing request included in the data storage unit to the secure OS 171, the processing result is output to the music decryption daemon 156.

<Normal switching device driver 160 and secure switching device driver 180>
Upon receiving the switching instruction from the normal OS 151 or the secure OS, the normal switching device driver 160 and the secure switching device driver 180 output the switching instruction to the switching control unit 106, and the right to use the CPU 102 is transferred from the normal OS 151 to the secure OS 171 or securely. This is a program for moving from the OS 171 to the normal OS 151.

(A) Switching process 1
Hereinafter, switching processing from the normal OS 151 to the secure OS 171 will be described with reference to FIG. This is the details of step S1028 in FIG. 10 and the switching process 1 in the flowcharts in FIG.
The normal switching device driver 160 is called from the normal OS 151 and receives a switching instruction (step S162). When the switching instruction is received, the context of the normal OS 151 is saved on the normal memory 111 (step S163). Next, a switching instruction is output to the switching control unit 106 (step S164).

After clearing the CPU 102 and the MMU 103, the switching control unit 106 outputs a connection instruction to the memory protection unit 114, and connects the secure memory 113 and the bus 130 (step S166). Next, the switching control unit 106 calls the secure switching device driver 180 on the secure memory 113 (step S167).
When called, the secure switching device driver 180 returns the context of the secure OS 171 to the CPU 102 (step S168).

The secure OS 171 invalidates the debugger IF 101 by the debug invalidation program 173 (step S169).
(B) Switching process 2
Hereinafter, switching processing from the secure OS 171 to the normal OS 151 will be described using the flowchart of FIG. This shows details of step S1062 in FIG. 11 and switching processing 2 in the flowcharts in FIG.

The secure OS 171 enables the debugger IF 101 by the debug invalidation program 173 (step S176), calls the secure switching device driver 180, and outputs a switching instruction (step S177).
The secure switching device driver 180 saves the context of the secure OS 171 (step S178) and outputs a switching instruction to the switching control unit 106.

The switching control unit 106 receives the switching instruction, clears the CPU 102 and the MMU 103, outputs a disconnection instruction to the memory protection unit 114, and disconnects the secure memory 113 and the bus 130 (step S181). Next, the normal switching device driver 160 on the normal memory 111 is called (step S182).
The normal switching device driver 160 restores the context of the normal OS 151 to the CPU 102 (step S183).

  Although the debugger IF 101 is enabled here when switching from the secure OS 171 to the normal OS 151, it may not be enabled. In this case, when the mobile phone 100 is turned on and first switched from the normal OS 151 to the secure OS 171, the debugger invalidation program 173 disables the debugger IF 101 and then switches from the secure OS 171 to the normal OS 151. Even in the switching process from the normal OS 151 to the secure OS 171, the debug module IF 101 is left invalid.

  In the present embodiment, the debugger IF 101 is invalidated and validated by the debug invalidation program 173 included in the secure OS 171. However, the normal OS 151 may include a debug invalidation program. The debug invalidation program may be an independent program loaded on the normal memory 111 and managed by the normal OS 151.

  Further, the normal OS 151 and the secure OS 171 may each have a debug invalidation program. In this case, the debug invalidation program of the normal OS 151 invalidates the debugger IF 101, and the debug invalidation program of the secure OS 171 validates the debugger IF. Conversely, the debug invalidation program that the secure OS 171 has may invalidate the debugger IF 101, and the debug invalidation program that the normal OS 151 has may validate the debugger IF.

These debug invalidation programs may be loaded into the normal memory 111 and the secure memory 113 as independent programs.
<Normal interrupt handler 161 and secure interrupt handler 181>
The normal interrupt handler 161 is called by the normal OS 151 when an interrupt occurs during execution of the normal OS 151 and the program controlled by the normal OS 151. When called from the normal OS 151 and receiving an interrupt occurrence notification, the interrupt controller 107 is controlled to investigate the factor causing the interrupt. Next, identification information indicating the device causing the interrupt and an interrupt notification are output to the normal OS 151.

  The secure interrupt handler 181 is called by the secure OS 171 when an interrupt occurs during execution of the secure OS 171 and the program controlled by the secure OS 171. When called from the secure OS 171 and receiving an interrupt occurrence notification, the dummy mask is written into the interrupt detection register of the CPU 102 to perform an interrupt mask process and output an interrupt occurrence notification to the secure OS 171.

(3) Input / output unit 116
The input / output unit 116 includes an access unit 131, a normal input / output device 132, and a secure input / output device 133 as shown in FIG.
The access unit 131 is connected to the memory card 300 and inputs / outputs information between the memory card 300 and the normal input / output device 132 and the secure input / output device 133.

  The normal input / output device 132 reads and writes data to the general area 303 of the memory card 300 under the control of the normal input / output device driver 157. As an example, when a music ID is received as an argument and a read request is received, the encrypted music data corresponding to the received music ID is read from the general area 303 and the read encrypted music data is written to the shared memory 112.

When the result request is received from the normal input / output device driver 157 after the writing is completed, the address on the shared memory 112 where the encrypted music data is written is output as the processing result.
The secure input / output device 133 performs mutual authentication with the secure processing unit 302 of the memory card 300 based on the CPRM mechanism under the control of the secure input / output device driver 178. Only when mutual authentication is successful, the key is shared, and the shared key is used to safely write and read data to and from the secure area 306.

If authentication fails, a card error notification indicating that the memory card 300 cannot be accessed is output to the secure input / output device driver 178.
Here, the secure input / output device 133 is a device that is used only when accessing the secure area 306 of the memory card 300, and the program for accessing the secure area 306 of the memory card 300 is limited. Therefore, it is not possible to request processing from a plurality of applications at the same time, so there is no need to perform exclusive control.

(4) Cryptographic processing device 117
The cryptographic processing device 117 performs cryptographic processing of various data under the control of the cryptographic device driver 179. In the present embodiment, the encrypted device driver 179 receives the address on the shared memory 112 where the encrypted music data is stored and the address on the secure memory 113 where the content key is stored. Is decrypted. Using the content key, the decrypted algorithm D1 is applied to the encrypted music data to generate music data, and the generated music data is written into the buffer 123. The write destination address is output to the cryptographic device driver 179 as the processing result. The decryption algorithm D1 is for decrypting the ciphertext generated by the encryption algorithm E1.

Here, the cryptographic processing device 117 is a device that decrypts various encrypted data, and also decrypts encrypted content transmitted from the content distribution server. Therefore, the cryptographic processing device 117 may be requested to perform decryption processing from a plurality of different programs, and requires exclusive control.
(5) CPU102
The CPU 102 includes an instruction fetch unit, an instruction decoder, an arithmetic unit, a program counter, a register, and the like, fetches an instruction from a program on the normal memory 111 or the secure memory 113, decodes the fetched instruction, and executes the decoded instruction .

(6) MMU103
The MMU 103 realizes a virtual storage function by converting a logical address into a physical address.
(7) Debugger IF 101 and interrupt controller 107
The debugger IF 101 is an interface for connecting the mobile phone 100 and an external debugger.

The interrupt controller 107 detects various interrupts and outputs an interrupt generation notification to the interrupt detection register of the CPU 102.
(8) Switching control unit 106 and memory protection unit 114
The switching control unit 106 receives a switching instruction from the normal switching device driver 160 on the normal memory 111 or the secure switching device driver 180 on the secure memory 113, and connects or disconnects the bus 130 and the secure memory 113 by the memory protection unit 114. To do. Detailed operations of the switching control unit 106 and the memory protection unit 114 are as described in the above (a) switching process 1 and (b) switching process 2.

(9) Wireless communication control unit 118, communication unit 121, and antenna 122
The communication unit 121 transmits and receives information between the wireless communication control unit 118 and an external device connected to the mobile phone network 10 and the Internet 20 via the antenna 122.
The wireless communication control unit 118 includes a baseband unit, a modulation / demodulation unit, an amplifier, and the like, and performs signal processing of various types of information transmitted and received via the communication unit 121 and the antenna 122.

(10) Buffer 123, code processor 124, D / A converter 126
The buffer 123 temporarily stores music data.
The code processing unit 124 performs a decoding process on the music data stored in the buffer 123 according to an encoding technique such as MP3 and outputs the result to the D / A conversion unit 126.
The D / A conversion unit 126 converts the music data decoded by the code processing unit 124 into an analog audio signal and outputs the analog audio signal to the speaker 120.

(11) Input unit 108, display unit 109, microphone 119 speaker 120
The input unit 108 includes various buttons such as a numeric keypad and an enter button, and accepts these operations by the user.
The display unit 109 includes a VRAM and a liquid crystal screen, and displays various screens.
The microphone 119 detects sound and outputs the detected sound to the wireless communication control unit 118.

The speaker 120 receives an analog audio signal from the wireless communication control unit 118 and the D / A conversion unit 126, and outputs audio based on the received audio signal.
1.3 Operations of Mobile Phone 100 and Memory Card 300 The flowcharts shown in FIGS. 15 to 35 are flowcharts showing the operation of the mobile phone 100. 36 to 40 are sequence diagrams showing exchange of commands between the programs in the operation of the mobile phone 100. FIG. The operation of the mobile phone 100 will be described using these flowcharts and sequence diagrams.

  In addition, the same step number is attached | subjected to the corresponding process of a sequence diagram and a flowchart. In addition, as described in the description of the normal OS 151 and the secure OS 171, each program on the normal memory 111 and the secure memory 113 can execute commands to other programs by system calls, response notifications, external processing requests, and secure processing requests. In addition, the normal OS 151 and the secure OS 171 are requested to mediate data. In FIG. 15 to FIG. 40 and the following description, description of system calls, response notifications, external processing requests, and secure processing requests is omitted, and identification information that each program stores and outputs in the data storage unit of these commands Only the data and commands are listed.

(1) Operation of Mobile Phone 100 The operation of the mobile phone 100 will be described using the flowchart shown in FIG.
The cellular phone 100 receives a button operation by the user through the input unit 108 (step S101). When the received operation indicates music reproduction, the music reproduction program 153 is activated (step S102). If the received button operation indicates other processing, other processing is performed (step S103).

  Next, a music decryption program registration process is performed (step S104). Next, the music decoding program 176 is requested to perform a decoding process (step S106). When the decoding by the music decoding program 176 is completed, the generated music data is expanded by a method according to MP3, converted into analog data to generate analog music data, and the generated analog music data is output from the speaker 120 ( Step S107). Steps S106 to S108 are repeated until a button operation indicating the end of music playback is received by the input unit 108 (step S108).

When a button operation indicating the end of music playback is received (YES in step S108), a music decryption program deletion process is performed (step S109).
(2) Music Decoding Program Registration FIGS. 16 to 17 are flowcharts showing in detail the operation of each program in the music decoding program registration process. This corresponds to the sequence of steps S132 to S153 in FIG. The music decoding program registration process will be described with reference to the flowcharts shown in FIGS. 16 to 17 and the sequence diagram of FIG.

The music playback program 153 reads out the pre-coded daemon information and secure application information (step S131). The secure application registration request and the read daemon information and secure application information are output to the normal OS 151 (step S132).
When the normal OS 151 receives the secure application registration request, the normal OS 151 stores the context of the music playback program 153 and writes the storage destination address to the application context address of the entry 167 of the application management table (step S133). Next, the encrypted music decryption program 141 corresponding to the received secure application information is read from the secondary storage unit 104 and written to the shared memory 112 (step S134). Next, the secure application registration request is written in the command area of the shared memory 112 (step S136), and the process proceeds to the switching process 1 (step S137).

  When the switching process 1 ends, the secure OS 171 reads a secure application registration request from the shared memory 112 (step S138). Next, the encrypted music decryption program on the shared memory 112 is decrypted by the encryption / decryption program to generate a music decryption program, and the generated music decryption program is written on the secure memory 113 (step S139). A handle value “1” is set for the music decryption program, “1” is written in the handle value of the entry 187 of the secure application management table 186, and the music decryption program 176 is written in the secure application address. The address is written (step S141).

Next, the registration completion notification and the handle value “1” are written in the shared memory 112 (step S143), and the process proceeds to the switching process 2 (step S144).
The normal OS 151 reads the registration completion notification and the handle value “1” from the shared memory 112 (step S146). The read handle value “1” is written to the entry 167 of the application management table 166 (step S147). Based on the daemon information, the music decryption daemon 142 is read from the secondary storage unit 104 and written to the normal memory 111 (step S149). The write destination address of the music decryption daemon 156 on the normal memory 111 is written to the entry 167 of the application management table 166 (step S151).

Next, based on the application context address of the entry 167, the context of the music playback program 153 is returned to the CPU 102 (step S152), and the received handle value “1” is output to the music playback program 153 (step S153).
The music playback program 153 writes the received handle value “1” in the storage area of the music playback program 153 itself in the normal memory 111 (step S154).

(3) Processing Request to Music Decryption Program The flowcharts of FIGS. 18 to 27 show the operation of each program when the music decryption program 176 decrypts the encrypted music data in response to a request from the music playback program 153. This corresponds to step S193 in FIG. 36 to step S347 in FIG.
The music playback program 153 displays a selection screen including a music list and accepts the user's music selection (step S191). The music ID indicating the received music and the handle value “1” are read (step S192). Using the read music ID as an argument, the argument, the handle value “1”, and the decryption processing instruction are output to the normal OS 151 (step S193).

  The normal OS 151 stores the context of the music playback program 153 in the normal memory 111 (step S196), and writes the storage destination address in the entry 167 including the handle value “1” in the application management table 166 (step S197). Next, the received argument, handle value “1”, and decryption processing instruction are written in the shared memory 112 (step S198), and switching processing 1 is performed (step S199).

  When the switching process 1 ends (step S199), the secure OS 171 reads the argument, the handle value “1”, and the decryption process instruction from the shared memory 112 (step S201). On the secure application management table 186, the music decryption program 176 is started based on the secure application address of the entry 187 including the read handle value “1” (step S202), and the read argument and handle value “1” are decrypted. The processing instruction is output to the music decoding program 176 (step S203).

  The music decryption program 176 receives the argument and the decryption processing instruction from the secure OS 171 and stores the received argument (music ID). Next, the CPU 102 executes the music decryption program 176 (data reading step) (step S204). The music decryption program 176 reads the music ID (step S206), and outputs the data read command, the argument, and the handle value “1” to the secure OS 171 using the read music ID as an argument (step S208).

  The secure OS 171 receives the data read command, the argument, and the handle value “1” from the music decryption program 176, stores the context of the music decryption program 176 on the secure memory 113, and stores the storage destination address in the secure application management table 186. Write to the entry 187 (step S209). Next, the received data read command, argument, and handle value “1” are written to the shared memory 112 (step S211), and the process proceeds to the switching process 2 (step S216).

  When the switching process 2 ends (step S216), the normal OS 151 reads the data read command, the argument, and the handle value “1” from the shared memory 112 (step S217). The entry 167 including the handle value “1” in the application management table 166 is selected, and the music decryption daemon 156 is activated with the daemon address included in the selected entry 167 (step S218). The read data read command, argument, and handle value “1” are output to the music decryption daemon 156 (step S219).

  The music decryption daemon 156 receives the data read command, the argument, and the handle value “1”. When the data read command is received, the access function stored in the library 152 is called, and the argument and the handle value “1” are output (step S221). The access function called by the music decryption daemon 156 outputs the read request, the argument, the device ID_A, and the received handle value “1” to the normal OS 151 (step S222). The normal OS 151 outputs the read request, the argument, the device ID_A, and the handle value “1” to the normal input / output device driver 157 corresponding to the received device ID_A (step S223).

  The normal input / output device driver 157 receives the read request, the argument, and the handle value “1”. Next, it is determined whether or not the exclusive flag is “0” (step S224). If the exclusive flag is “1” (NO in step S224), the normal input / output device driver 157 notifies the error that the normal input / output device 132 is operating and cannot accept a new read request. Is output.

The music decryption daemon 156 receives the error notification via the normal OS 151 and the access function, and outputs a read request again after a predetermined time has elapsed. Alternatively, the received error notification may be output to the music decryption program 176 via the normal OS 151 and the secure OS 171 to stop the decryption process.
If it is determined that the exclusion flag is “0” (YES in step S224), the exclusion flag is changed to “1” (step S227), the received argument is output to the normal input / output device 132, and data read is instructed. (Step S231).

The normal input / output device 132 receives an argument (music ID) and a read request, reads out the encrypted music data 304 corresponding to the received music ID from the general area 303 of the memory card 300, and reads out the read encrypted music data 304. Is started to be written to the shared memory 112 (step S236).
When the normal input / output device driver 157 outputs a read request to the normal input / output device 132 (step S231), the normal input / output device driver 157 sleeps including the device ID_A of the normal input / output device driver 157 itself and the received handle value “1” to the normal OS 151. A request is output (step S232).

Upon receiving the sleep request, the normal OS 151 puts the music decryption daemon 156 corresponding to the handle value “1” and the normal input / output device driver 157 corresponding to the device ID_A into a sleep state (steps S233 and S234). Next, the CPU 102 is assigned to another program in an executable state by task scheduling (step S238).
When the processing in the normal input / output device 132 ends, an interrupt occurs, and the music decryption daemon 156 acquires the processing result (step S239). Processing 1 at the time of occurrence of an interrupt in step S239 will be described later. Further, the processing in step S239 corresponds to the sequence in steps S463 to 478 in FIG.

  In process 1 (step S239) when an interrupt occurs, the music decryption daemon 156 acquires the write destination address of the encrypted music data on the shared memory 112 as the processing result of the normal input / output device 132. The acquired processing result and the handle value “1” are output to the normal OS 151 (step S241). The normal OS 151 writes the received processing result and the handle value “1” into the shared memory 112 (step S242), and performs the switching process 1 (step S244).

  When the switching process 1 (step S244) ends, the secure OS 171 reads the handle value “1” and the processing result from the shared memory 112 (step S251). The entry 187 including the read handle value “1” is selected from the secure application management table 186, and the context of the music decryption program 176 is returned to the CPU 102 by the secure application context address of the entry 187 (step S252). Next, the read processing result and the handle value “1” are output to the music decoding program 176 (step S254).

The music decryption program 176 receives the write destination address of the encrypted music data as a processing result, and stores the received write destination address in its own storage area.
Next, the CPU 102 executes the music decryption program 176 (content key reading step) (step S256). The music decryption program 176 outputs a system call including the content key read command, the device ID_B, and the handle value “1” indicating the music decryption program 176 itself to the secure OS 171 (step S257).

The secure OS 171 receives the content key read command, the device ID_B, and the handle value “1”, and sends the received content key read command, the device ID_B, and the handle value “1” to the secure input / output device driver 178 corresponding to the received device ID_B. Is output (step S258).
The secure input / output device driver 178 receives the content key read command, the device ID_B, and the handle value “1”, and outputs the content key read command to the secure input / output device 133 (step S259).

The secure input / output device 133 receives the content key read command, and then performs mutual authentication with the secure processing unit 302 of the memory card 300 (step S262). If the authentication is successful (YES in step S263), acquisition of the content key is started (step S266).
If the authentication is unsuccessful, a card error notification is output and the acquisition of the content key is stopped (step S264). In this case, the music decryption daemon 156 and the music decryption program 176 stop the decryption process, and the music playback program 153 displays a screen for notifying that the memory card 300 cannot be read.

  Next, the secure input / output device driver 178 outputs a sleep request, the received handle value “1”, and the device ID_B indicating the secure input / output device driver 178 itself to the secure OS 171 (step S271). The sleep request output here is not a request for sleep processing to the secure OS 171 but is a command stored in the data storage unit of the external processing request and mediated to the music decryption daemon 156.

The secure OS 171 receives the sleep request, the handle value “1”, and the device ID_B from the secure input / output device driver 178, and writes the received sleep request, the handle value “1”, and the device ID_B to the shared memory 112 (Step S1). S272). Next, the process proceeds to the switching process 2 (step S273).
When the switching process ends (step S273), the normal OS 151 reads the sleep request, the handle value “1”, and the device ID_B from the shared memory 112 (step S274). The music decryption daemon 156 is activated based on the entry 168 including the read handle value “1” (step S276), and the read sleep request, device ID_B, and handle value “1” are output (step S277).

The music decryption daemon 156 receives the sleep request, the device ID_B, and the handle value “1” from the normal OS 151. When the sleep request is received, a system call including the sleep request, the device ID_B, and the handle value “1” is output to the normal OS 151 (step S278).
The secure OS 171 outputs the received sleep request, device ID_B, and handle value “1” to the secure input / output entry device driver 158 corresponding to the received device ID_B (step S281).

When the secure input / output entry device driver 158 receives the sleep request from the music decryption daemon 156 via the normal OS 151, the secure input / output entry device driver 158 outputs a sleep request including the device ID_B and the handle value “1” to the normal OS 151 (step S282).
The normal OS 151 receives the sleep request, the device ID_B, and the handle value “1”. When the sleep request is received, the secure input / output entry device driver 158 corresponding to the received device ID_B and the music decryption daemon 156 corresponding to the received handle value “1” are subjected to sleep processing (steps S283 and S284).

Next, the normal OS 151 performs task scheduling and assigns a CPU to another program in an executable state (step S286).
The acquisition of the content key by the secure input / output device 133 is completed, and the music decryption program 176 acquires the processing result by processing 2 (step S287) when an interrupt occurs. Processing 2 at the time of occurrence of an interrupt in step S287 will be described later. The processing in step S287 corresponds to step S512 in FIG. 38 to step S541 in FIG.

  In step S287, the music decryption program 176 obtains an address on the secure memory 113 where the content key is stored as a processing result. Next, the CPU 102 executes the music decoding program 176 (decoding step) (step S291). The music decryption program 176 uses the decryption instruction, the argument, and the handle value “1”, with the address of the content key stored in the secure memory 113 and the address of the encrypted music data stored in the shared memory 112 as arguments. Are output to the secure OS 171 (step S292).

The secure OS 171 receives a decryption command, an argument, and a handle value “1” from the music decryption program 176. Next, the received decryption instruction, argument, and handle value “1” are written to the shared memory 112 (step S293), and a switching process 2 is performed (step S294).
When the switching process 2 ends (step S294), the normal OS 151 reads the decryption command, the argument, and the handle value “1” from the shared memory 112 (step S296). Using the read handle value “1” and the application management table 166, the music decryption daemon 156 is activated, and the decryption instruction, the argument, and the handle value “1” are output to the music decryption daemon 156 (step S297). .

The music decryption daemon 156 receives a decryption command, an argument, and a handle value “1” from the normal OS 151. When the decryption command is received, the received decryption command and argument, device ID_C, and handle value “1” are output to the normal OS 151 (step S298).
The normal OS 151 receives a decryption command, an argument, a device ID_C, and a handle value “1” from the music decryption daemon 156, and sends the received decryption command, argument, device ID_C, and handle to the encryption entry device driver 159 corresponding to the received device ID_C. The value “1” is output (step S301).

  The cryptographic entry device driver 159 receives an argument, a decryption command, a device ID_C, and a handle value “1” from the music decryption daemon 156 via the normal OS 151. When the decryption instruction is received, if the exclusion flag is “1” (NO in step S303), an error notification indicating that the cryptographic processing device 117 is already operating and cannot accept a new processing request is issued. Output (step S304). At this time, the music decryption daemon 156 that has received the error notification again outputs a decryption command after a predetermined time has elapsed.

If the exclusion flag is “0” (YES in step S303), the exclusion flag is changed to “1” (step S306), and the received argument, decryption instruction, handle value “1”, and device ID_C are output to the normal OS 151. (Step S307)
The normal OS calls the music decryption daemon 156 corresponding to the received handle value “1”, and outputs the received decryption command, argument, handle value “1”, and device ID_C (step S308).

The music decryption daemon 156 receives the decryption command, the argument, the handle value “1”, and the device ID_C from the encryption entry device driver 159 via the normal OS 151. Next, the received decryption command, argument, device ID_C, and handle value “1” are output to the normal OS 151 (step S309).
The normal OS 151 receives the decryption command, argument, device ID_C, and handle value “1” from the music decryption daemon 156, and writes the received decryption command, argument, device ID_C, and handle value “1” to the shared memory 112 ( Step S312) and switching process 2 are performed (step S313).

  When the switching process 2 ends (step S313), the secure OS 171 reads the decryption command, the argument, the device ID_C, and the handle value “1” from the shared memory 112 (step S314). Based on the read device ID_C, the cryptographic device driver 179 is activated (step S315), and the read decryption command, argument, and handle value “1” are output to the cryptographic device driver 179 (step S316).

The cryptographic device driver 179 receives the decryption command, the argument, the device ID_C, and the handle value “1” from the secure OS 171, outputs the received argument to the cryptographic processing device 117, and instructs decryption (step S 317).
When the encryption processing device 117 is instructed to decrypt by the encryption device driver 179, the encryption processing device 117 reads the content key from the secure memory 113, and applies the decryption algorithm D1 to the encrypted music data on the shared memory 112 using the read content key. The music data is generated, and the generated music data is output to the buffer 123 (step S318).

  The cryptographic device driver 179 instructs the cryptographic processing device 117 to decrypt, and then outputs a sleep request, the handle value “1” received from the secure OS 171, and the device ID_C indicating the cryptographic device driver 179 itself to the secure OS 171 ( Step S321). The sleep request output here is not a request for sleep processing to the secure OS 171 but is a command stored in the data storage unit of the external processing request and mediated to the music decryption daemon 156.

The secure OS 171 receives the sleep request, handle value “1”, and device ID_C from the cryptographic device driver 179, and writes the received sleep request, handle value “1”, and device ID_C to the shared memory 112 (step S322). Next, the switching process 2 is performed (step S323).
When the switching process 2 ends (step S323), the normal OS 151 reads the handle value “1”, the device ID_C, and the sleep request from the shared memory 112 (step S326). The music decryption daemon 156 is activated based on the read handle value “1” and the application management table 166, and the read sleep request, the handle value “1”, and the device ID_C are output to the music decryption daemon 156 (step S327). ).

  The music decryption daemon 156 receives the sleep request, the handle value “1”, and the device ID_C from the normal OS 151. The received sleep request, device ID_C, and handle value “1” indicating the music decryption daemon 156 itself are output to the normal OS 151 (step S328). The normal OS 151 outputs the received sleep request, device ID_C, and handle value “1” to the encryption entry device driver 159 corresponding to the received device ID_C (step S329).

The cryptographic entry device driver 159 receives the sleep request, device ID_C, and handle value “1” from the music decryption daemon 156 via the normal OS 151. Next, the sleep process, the received handle value “1”, and the device ID_C of the encryption entry device driver 159 itself are output to the normal OS 151 (step S332).
The normal OS 151 receives the sleep request, the handle value “1”, and the device ID_C from the encryption entry device driver 159, and puts the music decryption daemon 156 corresponding to the received handle value “1” into the sleep state (step S333). Next, the encryption entry device driver 159 corresponding to the received device ID_C is put into a sleep state (step S334). Next, task scheduling is performed and a CPU is assigned to a program in an executable state (step S336).

When the decryption process by the cryptographic processing device 117 is completed and the interrupt 3 is generated, the music decryption program 176 receives the processing result by the cryptographic processing device 117 (step S337). Step S337 will be described later. Note that step S337 corresponds to step S552 in FIG. 37 to step S606 in FIG.
The music decryption program 176 acquires the write destination address on the music data buffer 123 as a processing result by the cryptographic processing device 117. Next, the CPU 102 executes the music decryption program 176 (music data output step) (step S338). The music decryption program 176 outputs the processing result, the application return request, and the handle value “1” to the secure OS 171 using the write destination address of the music data as the processing result (step S339).

The secure OS 171 receives the application return request, the processing result, and the handle value “1”, and writes the received application return request, the processing result, and the handle value “1” in the shared memory 112 (step S341). Next, the switching process 2 is performed (step S342).
When the switching process 2 ends (step S342), the normal OS 151 reads the application return request, the processing result, and the handle value “1” from the shared memory 112 (step S344). Based on the entry 167 including the handle value “1” in the application management table 166, the context of the music decryption program 176 is returned (step S346). Next, the read processing result is output to the music decoding program 176 (step S347).

(4) Processing 1 when an interrupt occurs
Processing 1 when an interrupt occurs will be described using the flowchart shown in FIG. This is the detail of step S239 in FIG. Also, this corresponds to the sequence of steps S463 to 478 in FIG.
When the reading of the encrypted music data is completed (step S462), the normal input / output device 132 generates an interrupt (step S463).

The interrupt controller 107 detects the occurrence of an interrupt and outputs an interrupt occurrence notification to the normal OS 151 (step S464). The normal OS 151 receives the interrupt occurrence notification and activates the normal interrupt handler 161 based on the interrupt table (step S466). Next, an interrupt generation notification is output to the normal interrupt handler 161 (step S467).
The normal interrupt handler 161 controls the interrupt controller 107 and investigates the cause of the interrupt (step S468). Next, the device ID_A corresponding to the normal input / output device generating the interrupt and the interrupt notification are output to the normal OS 151 (step S469).

  The normal OS 151 receives an interrupt notification and device ID_A from the normal interrupt handler 161. The normal input / output device driver 157 corresponding to the received device ID_A and the music decoding daemon 156 that has performed the sleep processing together with the normal input / output device driver 157 are released from sleep (step S471, step S472), and the CPU 102 is set to the normal input / output device. Assign to the driver 157.

  The normal input / output device driver 157 is released from sleep and outputs a result request to the normal input / output device 132 (step S473). As a processing result from the normal input / output device 132, the encrypted music data on the shared memory 112 is output. A write destination address is acquired (step S474). When the processing result is acquired, the exclusive flag is set to “0” (step S476), the acquired processing result, the handle value “1” received as the identification information indicating the output source of the read request, and the normal input / output device driver 157 itself is output to the normal OS 151 (step S477), and the normal OS 151 sends the received processing result, the handle value “1”, the device ID_A, and the music decoding daemon 156 corresponding to the handle value “1”. Is output (step S478).

(5) Processing when an interrupt occurs 1-2
The above processing 1 when an interrupt occurs indicates an operation when an interrupt occurs during execution of the normal OS 151 or a program on the normal memory 111 managed by the normal OS 151. Here, the operation when an interrupt occurs during execution of the secure OS 171 or a program managed by the secure OS 171 will be described using the flowchart of FIG.

When the reading of the encrypted music data is completed (step S491), the normal input / output device 132 generates an interrupt (step S492).
The interrupt controller 107 detects an interrupt and outputs an interrupt occurrence notification to the secure OS 171 (step S493).
The secure OS 171 receives an interrupt occurrence notification from the interrupt controller 107. When the interrupt occurrence notification is received, the secure interrupt handler 181 is activated (step S494), and the interrupt occurrence notification is output (step S496).

The secure interrupt handler 181 receives the interrupt occurrence notification, performs an interrupt mask process to the CPU 102 (step S497), and outputs an interrupt occurrence notification to the secure OS 171 (step S498).
The secure OS 171 receives the interrupt occurrence notification from the secure interrupt handler 181 and writes the received interrupt occurrence notification to the shared memory 112 (step S499). Next, the secure OS 171 and the normal OS 151 perform the switching process 2 (step S501).

When the switching process 2 is completed (step S501), the interrupt occurrence notification is read from the shared memory 112, and the CPU interrupt mask is released (step S502).
Here, since the interrupt controller 107 has not been cleared, it continues to output the interrupt occurrence notification, and the processing after step S502 is the same as the processing after step S464 in FIG.

(6) Processing 2 when an interrupt occurs
Below, the process 2 at the time of interruption generation | occurrence | production is demonstrated using the flowchart of FIGS. This is a detail of step S287 in FIG. This corresponds to the sequence from step S512 in FIG. 38 to step S541 in FIG.
When the secure input / output device 133 finishes reading the content key (step S511), the secure input / output device 133 generates an interrupt (step S512).

The interrupt controller 107 detects the occurrence of an interrupt and outputs an interrupt occurrence notification to the normal OS 151 (step S513).
The normal OS 151 receives an interrupt occurrence notification from the interrupt controller 107 and activates the normal interrupt handler 161 (step S514). Next, an interrupt generation notification is output to the normal interrupt handler 161 (step S516).

The normal interrupt handler 161 receives the interrupt occurrence notification and investigates the factor causing the interrupt (step S517). It detects that the secure input / output device 133 has generated an interrupt, and outputs a device ID_B corresponding to the secure input / output device 133 and an interrupt notification to the normal OS 151 (step S518).
The normal OS 151 receives an interrupt notification and a device ID_B from the normal interrupt handler 161. Next, the sleep of the secure input / output entry device driver 158 corresponding to the received device ID_B and the music decryption daemon 156 that has performed the sleep processing together with the secure input / output entry device driver 158 is released (steps S519 and S521). The CPU 102 is assigned to the secure input / output entry device driver 158.

The secure input / output entry device driver 158 is released from sleep, receives the interrupt notification, the handle value “1” received as identification information indicating the output source of the sleep request, and the device ID_B possessed by the secure input / output entry device driver 158 itself. Are output to the normal OS 151 (step S523).
The normal OS 151 outputs the received interrupt notification, the handle value “1”, and the device ID_B to the music decryption daemon 156 corresponding to the received handle value “1” (step S524).

The music decryption daemon 156 receives the interrupt notification, the handle value “1”, and the device ID_B. The received interrupt notification, device ID_B, and handle value “1” indicating the music decryption daemon 156 itself are output to the normal OS 151 (step S527).
The normal OS 151 receives an interrupt notification, device ID_B, and handle value “1” from the music decryption daemon 156. The received interrupt notification, device ID_B, and handle value “1” are written to the shared memory 112 (step S529), and the process proceeds to the switching process 1 (step S531).

  When the switching process 1 ends, the secure OS 171 reads the interrupt notification, the device ID_B, and the handle value “1” from the shared memory 112 (step S532), and starts the secure input / output device driver 178 based on the read device ID_B. (Step S533). Next, the read interrupt notification, device ID_B, and handle value “1” are output to the secure input / output device driver 178 (step S534).

  The secure input / output device driver 178 receives the interrupt notification, the device ID_B, and the handle value “1”, and requests the secure input / output device 133 for the processing result (step S536). The content key storage address on the secure memory 113 is received as a processing result from the secure input / output device 133 (step S537). A response notification including the received processing result, handle value “1”, and device ID_B is output to the secure OS 171 (step S539).

The secure OS 171 outputs the received processing result, the handle value “1”, and the device ID_B to the music decryption program 176 corresponding to the received handle value “1” (step S541).
So far, in the description using FIGS. 30 to 31, the operation at the time of occurrence of an interrupt during execution of the normal OS 151 or the program on the normal memory 111 managed by the normal OS 151 has been described. However, the secure OS 171 and the secure OS 171 are described. The operation at the time of occurrence of an interrupt during execution of the program managed by the program is almost the same as the above-described process 1-2 at the time of occurrence of the interrupt, and the normal input / output device in FIG. 26 is changed to a secure input / output device. do it. The processing after step S502 continues to step S513 in FIG.

(7) Processing 3 when an interrupt occurs
Below, the process 3 at the time of interruption generation | occurrence | production is demonstrated using the flowchart of FIGS. This is the detail of step S337 in FIG. Further, the process 3 at the time of occurrence of an interrupt corresponds to the sequence from step S552 in FIG. 40 to step S606 in FIG.
When the decryption of the encrypted music data ends, the cryptographic processing device 117 generates an interrupt (step S552).

The interrupt controller 107 detects the occurrence of an interrupt and outputs an interrupt occurrence notification to the normal OS 151 (step S553).
The normal OS 151 receives the interrupt occurrence notification from the interrupt controller 107 and activates the normal interrupt handler 161 (step S556). An interrupt generation notification is output to the normal interrupt handler 161 (step S557).

When receiving the interrupt occurrence notification, the normal interrupt handler 161 investigates the factor causing the interrupt (step S558). It detects that the cryptographic processing device 117 has generated an interrupt, and outputs a device ID_C and an interrupt notification to the normal OS 151 (step S561).
The normal OS 151 receives an interrupt notification and a device ID_C from the normal interrupt handler 161. The sleep of the encryption entry device driver 159 corresponding to the received device ID_C and the music decryption daemon 156 that has performed sleep processing together with the encryption entry device driver 159 is released (steps S562 and S563), and the CPU 102 is transferred to the encryption entry device driver 159. assign.

When the sleep is canceled, the cryptographic entry device driver 159 outputs the interrupt notification, the handle value “1”, and the device ID_C indicating itself to the normal OS 151 (step S564).
The normal OS 151 receives the interrupt notification, the handle value “1”, and the device ID_C, and sends the interrupt notification, the handle value “1”, and the device ID_C to the music decryption daemon 156 corresponding to the received handle value “1”. Output (step S567).

The music decryption daemon 156 receives the device ID_C and the interrupt notification from the encryption entry device driver 159 via the normal OS 151. Next, the received interrupt notification and device ID_C and the handle value “1” corresponding to the music decryption daemon 156 itself are output to the normal OS 151 (step S568).
The normal OS 151 receives the interrupt notification, device ID_C, and handle value “1” from the music decryption daemon 156, and writes the received interrupt notification, device ID_C, and handle value “1” to the shared memory 112 (step S571). .

Next, the normal OS 151 and the secure OS 171 perform the switching process 1 (step S572).
When the switching process 1 ends, the secure OS 171 reads the interrupt notification, the device ID_C, and the handle value “1” from the shared memory 112 (step S576). Based on the read device ID_C, the cryptographic device driver 179 is activated, and the read interrupt notification, device ID_C, and handle value “1” are output (step S577).

The cryptographic device driver 179 receives the interrupt notification and the device ID_C handle value “1”, and requests the cryptographic processing device 117 for a processing result (step S578). From the cryptographic processing device 117, the write destination address of the music data on the buffer 123 is acquired as a processing result (step S579).
The cryptographic device driver 179 outputs the acquired processing result, the received handle value “1”, and the device ID_C indicating the cryptographic device driver 179 itself to the secure OS 171 (step S582).

The secure OS 171 receives the processing result, the handle value “1”, and the device ID_C from the cryptographic device driver 179, and writes the received processing result, the handle value “1”, and the device ID_C to the shared memory 112 (step S583).
Next, the secure OS 171 and the normal OS 151 perform the switching process 2 (step S584).

When the switching process 2 ends, the normal OS 151 reads the handle value “1”, the processing result, and the device ID_C from the shared memory 112 (step S586). Based on the read handle value “1”, the music decryption daemon 156 is activated, and the read processing result, the handle value “1”, and the device ID_C are output to the music decryption daemon 156 (step S587).
The music decryption daemon 156 receives the processing result, the handle value “1”, and the device ID_C from the normal OS 151. A system call including the received processing result, device ID_C, and handle value “1” indicating the music decryption daemon 156 itself is output to the normal OS 151 (step S588).

The normal OS 151 outputs the received processing result, the device ID_C, and the handle value “1” to the encryption entry device driver 159 corresponding to the device ID_C (step S589).
The cryptographic entry device driver 159 receives the processing result, the device ID_C, and the handle value “1” from the music decryption daemon 156 via the normal OS 151, and changes the exclusive flag to “0” (step S592). Next, the encryption entry device driver 159 outputs the received processing result, the handle value “1”, and the device ID_C to the music decryption daemon 156 by a response notification to the normal OS 151 (step S596) (step S597).

The music decryption daemon 156 receives the processing result, the handle value “1”, and the device ID_C from the music decryption daemon 156 via the secure OS 171. Next, the received processing result and the handle value “1” are output to the normal OS 151 (step S598).
The normal OS 151 receives the processing result and the handle value “1” from the music decryption daemon 156, and writes the received processing result and the handle value “1” to the shared memory 112 (step S601).

Next, the normal OS 151 and the secure OS 171 perform the switching process 1 (step S602).
When the switching process 1 ends, the secure OS 171 reads the handle value “1” and the treatment result from the shared memory 112 (step S603). Based on the entry 187 including the handle value “1” on the secure application management table 186, the context of the music decryption program 176 is restored (step S604), and the read processing result is output to the music decryption program 176 (step S606). ).

  So far, in the description using FIGS. 32 to 34, the operation at the time of occurrence of an interrupt during execution of the normal OS 151 or the program on the normal memory 111 managed by the normal OS 151 has been described. However, the secure OS 171 and the secure OS 171 The operation at the time of occurrence of an interrupt during the execution of the program managed by the above is substantially the same as the above-described process 1-2 at the time of occurrence of the interrupt, and the normal input / output device in FIG. 29 is changed to a cryptographic processing device. That's fine. Processing subsequent to step S502 continues to step S553 in FIG.

(7) Delete music decryption program
The music decryption program deletion process will be described with reference to the flowchart shown in FIG. This is the detail of step S109 in FIG. The music decryption program deletion process corresponds to the sequence of steps S611 to 618 in FIG.
The music decryption program 176 outputs the secure application deletion command and the handle value “1” to the normal OS 151 (step S611).

The normal OS 151 receives the handle value “1” and the secure application deletion command from the music decryption program 176, and writes the received handle value “1” and the secure application deletion command to the shared memory 112 (step S612).
Next, the normal OS 151 and the secure OS 171 perform the switching process 1 (step S613).

  When the switching process 1 ends, the secure OS 171 reads the secure application deletion command and the handle value “1” from the shared memory 112 (step S614). The music decryption program 176 is deleted from the secure memory 113 based on the secure application address of the entry including the handle value “1” on the secure application management table 186 (step S616), and the entry 187 including the handle value “1” is secured. Delete from the application management table 186 (step S617).

Next, the handle value “1” and the deletion completion notification are written in the shared memory 112 (step S618).
Next, the secure OS 171 and the normal OS 151 perform the switching process 2 (step S619).
When the switching process 2 ends, the normal OS 151 reads the deletion process completion notification and the handle value “1” from the shared memory 112 (step S621). The music decryption daemon 156 is deleted from the normal memory 111 based on the handle value “1” and the application management table 166 (step S622). Next, a deletion completion notification is output to the music playback program 153 (step S623), and the entry 167 including the handle value “1” is deleted from the application management table 166 (step S624).

1.3 Summary / Effects As described above, in the mobile phone 100 of the present invention, the music playback program 153 loaded and executed on the normal memory 111 is a process to be protected, specifically, encryption. The music decryption program 176 loaded on the secure memory 113 and executed is requested to decrypt the music data.

The music decryption program 176 and the music decryption daemon 156 on the normal memory 111 operate as a pair, and the music decryption program 176 shares the processing to be protected among the series of processing related to decryption of the encrypted music data. However, the music decryption daemon 156 performs processing that does not need to be protected.
By sharing the processing in this way, the program size of the music decoding program 176 itself is reduced, and the data, variables, etc. held by the music decoding program 176 are also reduced. Further, in response to a request from the music decryption program 176, the music decryption daemon 156 uses a function stored in the library on the normal memory 111. This eliminates the need for having a library on the secure memory 113.

Therefore, the capacity of the secure memory 113 to be secured is reduced in a series of decryption processes by the music decryption program 176 and the music decryption daemon 156, and the load of the protection mechanism for protecting the secure memory 113 can be reduced.
Regarding the processing related to the control of the cryptographic processing device 117, which is the device to be protected, managed by the secure OS 171, the notification of exclusive control, sleep, and interrupt that do not need to be protected is loaded into the normal memory 111 and executed. The encryption entry device driver 159 is executed.

  Considering this operation over time, the normal OS 151 causes the cryptographic entry device driver 159 to transition to the execution state by a system call from the music decryption daemon 156. The encryption entry device driver 159 performs exclusive control and calls the music decryption daemon 156. The music decryption daemon 156 calls the encryption device driver 179 via the normal OS 151 and the secure OS 171. The secure OS 171 causes the cryptographic device driver 179 to transition to the execution state. The encryption device driver 179 outputs a sleep request after instructing the encryption processing device 117 to perform a decryption process. When the cryptographic entry device driver 159 receives a sleep request via the secure OS 171, the normal OS 151, and the music decryption daemon 156, the cryptographic entry device driver 159 requests the normal OS 151 to perform a sleep process, and the normal OS 151 shifts the cryptographic entry device driver 159 to the sleep state. Let

  Next, the processing by the cryptographic processing device 117 ends, an interrupt occurs, and the normal OS 151 cancels the sleep of the music decryption daemon 156 and shifts to the execution state. The cryptographic entry device driver 159 outputs an interrupt notification, and the music decryption daemon 156 outputs an interrupt notification to the cryptographic device driver 179 via the normal OS 151 and the secure OS 171. The normal OS 151 assigns the CPU 102 to the encryption device driver 179 and puts it into an execution state.

In this way, the cryptographic device driver 179 and the cryptographic entry device driver 159 make a corresponding state transition. Therefore, the normal OS 151 can manage the usage state of the cryptographic processing device 117 managed by the secure OS 171 via the cryptographic entry device driver 159.
Similarly, the secure input / output device 133, which is a device managed by the secure OS 171, similarly controls the secure input / output entry device driver 158 so that the normal OS 151 monitors and controls the operation of the secure input / output device 133. It became possible.

1.4 Other Operations of the Mobile Phone 100 The initial operation of the mobile phone 100 and the construction of the virtual memory space will be described below.
(1) Boot Program FIG. 43 shows an example of data stored in the normal memory 111. This shows a state in the normal memory 111 immediately after the mobile phone 100 is activated.

The normal OS 151, library 152, normal input / output device driver 157, secure input / output entry device driver 158, encryption entry device driver 159, normal switching device driver 160, and normal interrupt handler 161 are as described above.
The boot program 162 is stored in advance in the ROM constituting the normal memory 111, and the boot program 162 is not specifically illustrated, but is a program that is read and executed by the activation unit included in the mobile phone 100. It is.

The activation unit reads the boot program 162 from the normal memory 111 immediately after the mobile phone 100 is turned on, and operates according to the read boot program 162. Hereinafter, the boot program will be described by the operation of the activation unit according to the boot program 162.
First, the boot program 162 clears the register of the CPU 102 and the MMU 103 and outputs an initialization request to the switching control unit 106. An initialization end notification for notifying that the initialization of the program on the secure memory 113 is completed is received from the switching control unit 106. Next, the normal OS 151, the normal switching device driver 160, etc. are loaded onto the normal memory 111. ,initialize.

(2) Initial operation of the mobile phone 100 The mobile phone 100 is initialized by the switching control unit 106 and the boot program at startup. The operation when the mobile phone 100 is activated will be described with reference to the flowchart shown in FIG.
When the mobile phone 100 is turned on and power supply is started (step S651), the activation unit activates the boot program 162 (step S652). First, the boot program 162 is initialized by clearing the registers of the CPU 102 and the MMU 103 (step S653). Next, an initialization request is output to the switching control unit 106 (step S654).

  The switching control unit 106 receives the initialization request and reads the encrypted secure OS from the secondary storage unit 104 (step S656). The read encrypted secure OS is decrypted to generate a secure OS (step S657). Next, the memory protection unit 114 connects the bus 130 and the secure memory 113 (step S658). The generated secure OS is written on the secure memory 113 and initialized (step S659). Subsequently, the secure switching device driver is read from the secondary storage unit 104 and loaded onto the secure memory 113 (step S661).

Next, the memory protection unit 114 disconnects the secure memory 113 and the bus 130 (step S662), and outputs an initialization end notification to the boot program 162 (step S663).
The boot program 162 receives the initialization end notification from the switching control unit 106, and then loads programs such as the normal OS 151 and the normal switching device driver 160 onto the normal memory and initializes them (step S664).

In the above description, the encrypted secure OS and the secure switching device driver have been described as being stored on the secondary storage unit 104, but may be stored on an external recording medium or the like.
(3) Initialization Operation by Normal OS 151 and Secure OS 171 Normal I / O device driver 157, secure I / O entry device driver 158, and cryptographic entry device driver 159 are programs that reside on normal memory 111 under the control of normal OS 151. is there.

The secure input / output device driver 178 and the encryption device driver 179 are programs that reside on the secure memory 113 under the management of the secure OS 171.
The boot program 162 loads the normal OS 151, the normal switching device driver 160, and the like onto the normal memory 111, and starts the normal OS 151 when initialization is completed.
When the normal OS 151 is started, it first searches for a program loaded on the normal memory 111, and whether or not the normal input / output device driver 157, secure input / output entry device driver 158, and encryption entry device driver 159 are loaded. If it is not loaded, it is read from the secondary storage unit 104 and loaded.

When the normal OS 151 loads the secure input / output entry device driver 158 and the cryptographic entry device driver 159, the secure input / output device driver 178 and the cryptographic device driver 179 are also loaded onto the secure memory 113 by the secure OS 171.
This operation by the normal OS 151 and the secure OS 171 is similar to the music decryption program registration process already described, and will be described briefly here. It is assumed that the secondary storage unit 104 stores in advance each device driver and an encrypted entry device driver generated by encrypting the entry device driver.

  When determining that the secure input / output entry device driver is not loaded, the normal OS 151 reads the secure input / output entry device driver from the secondary storage unit 104 and writes it in the normal memory 111. The write destination address and the secure input / output entry device driver 158 are stored in association with each other. Next, a device registration request for instructing loading of the device driver and a device ID_B indicating the secure input / output device driver are written into the shared memory 112. Next, a switching instruction is output to the normal switching device driver 160.

  The switching process ends, and the secure OS 171 returns to the CPU 102. The device registration request and device ID_B are read from the shared memory 112. The encrypted secure input / output entry device driver corresponding to the device ID_B is read out, and the encrypted entry device driver read out is decrypted by the encryption / decryption program 174 to generate a secure input / output entry device driver and write it into the secure memory 113. The write destination address and the device ID_B are stored in association with each other.

Next, a notification of registration completion registration is written in the shared memory 112 and a switching instruction is output to the secure switching device driver 180.
When the switching process ends and returns to the CPU 102, the normal OS 151 reads a notification of completion of registration of the devdora from the shared memory 112.
Subsequently, the encryption entry device driver is loaded in the same manner.

(4) Virtual Storage Space by MMU Control Program 184 Although not mentioned so far, the secure OS 171 includes an MMU control program 184 as shown in FIG. The MMU control program 184 is a program executed by the MMU 103, and constructs a virtual storage space by converting physical addresses and logical addresses of the secure memory 113, the shared memory 112, and the secondary storage unit 104.

FIG. 46 shows an example of a virtual storage space realized by the MMU control program 184. As shown in FIG. 45, it is assumed that a music decryption program 176 and a communication key generation program 185 are loaded on the secure memory 113. The music decryption program 176 and the communication key generation program 185 are secure applications.
The music decryption program 176 and the communication key generation program 185 are loaded in the virtual space 201 and the virtual space 204, respectively. A normal shared space 202 and a normal shared space 206 are individually assigned to each program. The normal shared space 202 and the normal shared space 206 are virtual spaces that are shared by the programs on the normal memory 111.

The music decryption program 176 cannot access the virtual space 204 and the normal shared space 206. Further, the communication key generation program 185 cannot access the virtual space 201 and the normal shared space 202.
The secure shared space 207 is a virtual space that can be accessed from both the music decryption program 176 and the communication key generation program 185, but cannot be accessed from programs that normally operate under the management of the OS 151.

The secure OS 171 is loaded in the virtual space 208. The secure OS 171 can access the virtual spaces 201 and 204, but cannot access the virtual space 208 from the music decryption program 176 and the communication key generation program 185.
In this way, the MMU control program 184 assigns an individual virtual space for each application and performs control so that they cannot access each other.

  The MMU control program 184 realizes the above-described virtual storage space on the secure memory 113, the shared memory 112, and the secondary storage unit 104. The MMU control program 184 includes an encryption processing program. When data stored in the secure memory 113 is paged out to the secondary storage unit 104, the data is encrypted, and the data is stored in the secondary storage unit 104. When page-in is performed on the secure memory 113, decryption may be performed.

Further, the music decryption program 176 and the communication key generation program 185 may be able to access each normal shared space.
1.5 Modification of Embodiment 1 (1) In Embodiment 1, the music decryption program 176 and the music decryption daemon 156 operate as a pair, thereby achieving the decryption processing of the encrypted music data. Although described, a configuration as shown in FIG. 47 may be used.

  In this configuration, a music playback program 153 b is loaded on the normal memory 111 instead of the music playback program 153. The music playback program 153b is configured to include an external processing manager 156b. The external processing manager 156b performs processing that does not need to be protected among the decryption processing of the encrypted music data, like the above-described music decryption daemon 156. to share the load. Various information and commands are input / output between the music decryption program 176 and the normal OS 151.

  In the case of this configuration, each entry of the application management table 166 includes a handle value and an application context address. When the normal OS 151 receives a command including the handle value “1” as identification information indicating the receiving destination, the OS 151 returns the context of the music playback program 153 based on the application management table 166 and assigns the CPU 102 to the external processing manager threat. .

According to such a configuration, since the music playback program 153 includes the external processing manager 156b, it is not necessary to load the music decryption daemon 156 on the normal memory during the music decryption program registration process. The registration process described in the first embodiment can be shortened.
(2) In this embodiment, the secure input / output entry device driver 158 and the secure input / output device driver 178 are identified by the same identification information device ID_B, but may be identified by different identification information. . The same applies to the encryption entry device driver 159 and the encryption device driver 179.

Specifically, the normal OS 151 and the secure OS 171 have a secure device driver management table 231 shown in FIG. 48 in their storage areas as control data.
The secure device driver management table 231 shown in FIG. 48 includes two secure device driver management information 232 and 234. Each secure device driver management information includes an entry device driver identifier and a secure device driver identifier. The secure device driver identifier is identification information indicating a device driver that controls a device managed by the secure OS 171, and the entry device driver identifier is an identification indicating a program on the normal memory 111 that operates as a pair with the device driver. Information. Specifically, the secure device driver management information 232 includes a device ID_B that is information for identifying the secure input / output entry device driver 158 and a secure input / output device driver 178 that operates in combination with the secure input / output entry device driver 158. It is composed of “100” which is information for identifying. The secure device driver management information 234 includes a device ID_C that is an identification information device indicating the cryptographic entry device driver 159, and identification information “101” that indicates the cryptographic device driver 179 that operates as a pair with the cryptographic entry device driver 159.

  The secure device driver management table 231 is generated when the normal OS 151 and the secure OS 171 are activated, and the normal OS 151 indicates the secure input / output entry device driver when the secure input / output entry device driver is loaded on the normal memory 111. The device ID_B, which is identification information, is written in the shared memory 112, and the process proceeds to the switching process.

  When the switching process is completed, the secure OS 171 reads the device ID_B from the shared memory 112, then reads the encrypted secure device driver from the secondary storage unit 104, decrypts it, and loads it onto the secure memory 113. Here, secure device driver management information 232 including identification information “100” indicating the loaded secure input / output device driver and the received device ID_B is generated and written on the secure memory 113. Next, the identification information “100” is written in the shared memory 112 and the process proceeds to the switching process.

When the switching process ends, the normal OS 151 reads the identification information “100” from the shared memory 112, and secure device driver management information including the read identification information “100” and the device ID_B indicating the secure input / output entry device driver 158. Is written in the normal memory 111.
The same applies to the secure device driver information 234.

  The normal OS 151 manages the secure input / output entry device driver 158 and the encryption entry device driver 159 using the secure device driver management table 231 generated as described above. In addition, the secure OS 171 manages the secure input / output device driver 178 and the cryptographic device driver 179 using the secure device driver management table 231.

(3) In the above embodiment, the secure OS 171 includes the debug invalidation program, but the secure switching device driver 180 may have this function.
In this configuration, each time the secure switching device driver 180 is called from the switching control unit 106, the secure switching device driver 180 first invalidates the debugger IF 101 and then restores the context of the secure OS 171.

When receiving a switching instruction from the secure OS 171, after saving the context of the secure OS 171, the debugger IF 101 is enabled and the switching instruction is output to the switching control unit 106.
In this way, by disabling the debugger IF 101 before the secure OS 171 returns to the CPU 102, the operation of the secure OS 171 can be more reliably prevented from being detected and operated by an external debug device. .

Further, instead of the program on the secure memory 113, the switching control unit 106 may invalidate and validate the debugger IF 101.
(4) In the first embodiment, the normal input / output device driver 157 and the encryption entry device driver 159 perform exclusive control using the exclusive flag. If the exclusive flag is “1”, an error notification is sent. It is supposed to output. However, processing requests received while each driver is operating may be stocked.

In this case, the normal input / output device driver 157 and the encryption entry device driver 159 include a QUEUE that stores the received processing request, and when receiving the processing request, instead of checking the exclusive flag, the received processing request Is stored in QUEUE.
The normal input / output device driver 157 acquires the processing result when the normal input / output device 132 finishes processing. Next, the next processing request is read from the QUEUE and output to the normal input / output device 132.

When the cryptographic entry device driver 159 receives the processing result and outputs the received processing result, the cryptographic entry device driver 159 reads the next processing request from the QUEUE. The read processing request is output to the encryption device driver 179.
Instead of QUEUE, a buffer area dedicated to the encryption entry device driver 159 may be provided, and the received processing request and the priority of the received processing request may be written in association with each other.

In this case, when the processing by the cryptographic processing device 117 is completed and a processing result is received, the cryptographic device driver 179 reads a processing request with a high priority and outputs it to the cryptographic processing device 117.
(5) In the above embodiment, the secure switching device driver 180 stores and restores the context of the secure OS 171. However, the normal switching device driver 160 may perform this.

  In this case, during the switching process 2 from the secure OS 171 to the normal OS 151, the secure OS 171 outputs a switching instruction to the switching control unit 106. The switching control unit 106 outputs a disconnection instruction to the memory protection unit 114 and disconnects the secure memory 113 and the bus 130. Next, the normal switching device driver 160 is called. The normal switching device driver 160 saves the context of the secure OS 171 including the registers of the CPU 102 and the contents of the MMU 103 on the normal memory 111, clears the CPU 102 and the MMU 103, and restores the context of the normal OS 151.

In the switching process 1 from the normal OS 151 to the secure OS 171, when receiving a switching instruction from the normal OS 151, the normal switching device driver 160 saves the context of the normal OS 151 and clears the CPU 102 and the MMU 103. Next, the context of the secure OS 171 is restored, and a switching instruction is output to the switching control unit 106.
In this way, the normal switching device driver 160 on the normal memory 111 stores and restores the context of the secure OS 171, thereby eliminating the need for the secure switching device driver 180 on the secure memory 113. Therefore, the capacity of the secure memory 113 can be reduced.

(6) In the above embodiment and modification, the mobile phone 100 forms a virtual storage space by the MMU 103. However, a configuration that does not use the virtual storage space may be used. In this case, data and programs stored in each memory are managed by physical addresses.
Therefore, in such a configuration, it is not necessary to save the contents of the MMU related to saving and returning the context.

In this case, the secure OS 171 context may not be saved. When called from the switching control unit 106, the secure switching device driver 180 returns the head address of the secure OS 171 to the CPU 102 and starts the secure OS 171 from the beginning.
(7) In the first embodiment, the mobile phone 100 includes the normal OS 151 loaded on the normal memory 111 and the secure OS 171 loaded on the secure memory 113 and executed. A configuration without the OS 151 may also be used.

  As described in the initial operation of the mobile phone 100, after the power is turned on, first, the boot program 162 is started. The boot program 162 initializes the CPU 102 and the MMU 103 and then outputs an initialization request to the switching control unit 106, and the switching control unit 106 loads the secure OS 171 and the secure switching device driver 180 onto the secure memory 113.

The secure OS 171 loads various programs on the secure memory 113 and the normal memory 111.
Each program on the normal memory 111 outputs all commands including system calls to the normal switching device driver 160 instead of the normal OS 151.
When the normal switching device driver 160 receives a command from the program on the normal memory 111, the normal switching device driver 160 writes the received command in a predetermined storage area and performs switching processing. When the secure OS 171 returns to the CPU 102, it reads a command from a predetermined storage area.

In this way, the secure OS 171 controls each program on the normal memory 111 and the secure memory 113.
Conversely, a configuration without the secure OS 171 may be used. In this case, the secure switching device driver 180 or the switching control unit 106 includes a debugger invalidation program.

Each program on the secure memory 113 outputs all commands including system calls to the secure switching device driver 180. The secure switching device driver 180 writes the received command in the command area on the shared memory 112 and outputs a switching instruction to the switching control unit 106.
When the normal OS 151 returns to the CPU 102, the command output from the program on the secure memory 113 is read from the command area of the shared memory 112.

In this way, the normal OS 151 may control each program on the normal memory 111 and the secure memory 113.
(8) In the embodiment and the modification described above, the switching control unit 106 and the memory protection unit 114 disconnect the secure memory 113 and the bus 130 so that the programs and data on the secure memory 113 can be externally accessed. Protect.

Alternatively, the memory protection unit 114 may protect the data in the secure memory 113 by encrypting and decrypting the data. The switching control unit 106 instructs the memory protection unit 114 to perform encryption or decryption instead of a connection instruction or a disconnection instruction.
The memory protection unit 114 encrypts or decrypts data in the secure memory 113 according to an instruction from the switching control unit 106.

In addition, not all data in the secure memory 113 but only the code portion, only the data portion, or only the stack portion of the music playback program 153 may be encrypted as necessary. The same applies to the secure OS 171, the encryption device driver 179, the secure input / output device driver 178, and the like.
(9) In the embodiment and the modification described above, the normal OS 151 manages the application management table 166, and uses the application management table 166 to correspond to the corresponding application and the secure application (for example, the music decryption daemon 156). Is calling. However, when there are a large number of applications that request processing to the secure application as with the music playback program 153, a configuration that includes a program for managing the application management table 166 and calling the program separately from the normal OS 151. good. This program is called a daemon control program.

In this case, when the normal switching device driver 160 is called from the switching control unit 106, the normal switching device driver 160 starts the daemon control program instead of the normal OS 151. The daemon control program reads a command from the shared memory 112 and calls the corresponding program based on the identification information included in the read command.
Each application and the program including the music decryption daemon 156 output a secure processing request to the daemon control program instead of the normal OS 151.

The daemon control program writes the received secure processing request in the shared memory 112 and outputs a switching instruction to the normal switching device driver 160.
(10) Although the mobile phone 100 has been described as one embodiment of the present invention, an information processing apparatus having a similar function, such as a personal computer, may be used.

In this case, the normal memory 111 and the secure memory 113 include a RAM and a hard disk. In the above description, the secure OS 171 and the music decryption program 176 are encrypted and stored in the secondary storage unit 104, but may be stored in advance in the hard disk portion on the secure memory 113.
2. Embodiment 2
A second embodiment of the present invention will be described below.

FIG. 49 shows a usage example of the mobile phone 400 according to the second embodiment of the present invention. The mobile phone 400 is connected to the invalidation list issuing device 250 via the base station 15, the mobile phone network 10, and the Internet 20.
The invalidation list issuing device 250 manages information related to invalidated programs, generates an invalidation list indicating these programs, and transmits the generated invalidation list to the mobile phone 400 via the Internet 20. Send.

The mobile phone 400 receives the invalidation list from the invalidation list issuing device 250 and determines whether or not the program stored therein is invalid based on the received invalidation list.
2.1 Invalidation list issuing device 250
As shown in FIG. 50, the invalidation list issuing device 250 includes a communication unit 251, a signature generation unit 252, a key storage unit 253, a hash generation unit 254, a control unit 257, an information storage unit 260, an input unit 262, and a display unit 263. Consists of

Specifically, the invalidation list issuing device 250 is a computer system including a microprocessor, a RAM, and a ROM. Computer programs are stored in the RAM and ROM, and the invalidation list issuing device 250 achieves its functions by the microprocessor operating according to the computer programs.
(1) Information storage unit 260
As shown in FIG. 50, the information storage unit 260 stores an OS invalidation list 266 and an application invalidation list 276.

The OS invalidation list 266 includes an issuer ID 267, a list ID 268, and invalidation IDs 269, 270, 271,.
The issuer ID 267 indicates the issuer of the OS revocation list. Examples of the issuer ID 267 include the device ID of the revocation list issuance device 250 and the identification information of the administrator of the revocation list issuance device 250.

The list ID 268 is information indicating whether the OS invalidation list 266 is new or old. Here, the creation date “2004015” of the OS invalidation list 266 is set as the list ID 268.
The invalidation IDs 269, 270, 271... Are identification information of the invalidated operating system.
The application invalidation list 276 includes an issuer ID 277, a list ID 278, an invalidation ID 279, 280, 281. The issuer ID 277 is information indicating the issuer of the application invalidation list. Examples of the issuer ID 277 include the device ID of the invalidation list issuance device 250 and the identification information of the administrator of the invalidation list issuance device 250.

The list ID 278 is information indicating whether the application invalidation list 276 is new or old. Here, the creation date “20041009” of the application invalidation list 276 is set as the list ID 278.
The invalidation IDs 279, 280, 281... Are identification information of invalidated applications.

(2) Communication unit 251
The communication unit 251 is connected to the Internet 20 and transmits and receives information between the control unit 257 and an external device connected to the Internet 20. Here, the external device is the mobile phone 400.
(3) Hash generation unit 254
The hash generation unit 254 receives the OS invalidation list 266 and the hash generation instruction from the control unit 257. Also, the application invalidation list 276 and the hash generation instruction are received.

  When the hash generation instruction is received, the received OS invalidation list 266 or application invalidation list 276 is substituted into a hash function to generate 160-byte OS digest data or application digest data. Here, SHA-1 is used for the hash function as an example. Since the hash function SHA-1 is a known technique, the description thereof is omitted. Other hash functions may be used.

The generated OS digest data or application digest data is output to the control unit 257.
(4) Key storage unit 253 and signature generation unit 252
The key storage unit 253 stores an issuing device private key unique to the revocation list issuing device 250 and an issuing device public key corresponding to the issuing device private key.

The signature generation unit 252 receives the OS digest data or the application digest data from the control unit 257, and is instructed to generate a signature.
When the OS digest data is received and the signature generation is instructed, the issuing device secret key is read from the key storage unit 253, and the received OS digest data is subjected to the signature generation algorithm S using the read issuing device secret key. The signature data is generated, and the generated signature data is output to the control unit 257. As an example, the signature generation algorithm S uses an elliptical DSA signature, an RSA (RivestShamirAdleman) signature, or the like.

When application digest data is received and signature generation is instructed, signature data is similarly generated and output to the control unit 257.
(5) Control unit 257
The control unit 257 receives a list request for requesting transmission of the latest OS invalidation list and application invalidation list from the mobile phone 400 via the communication unit 251 and the Internet 20.

  When the list request is received, the OS invalidation list 266 is read from the information storage unit 260, the read OS invalidation list 266 is output to the hash generation unit 254, and a hash generation instruction is output. Next, OS digest data is received from the hash generation unit 254. The received OS digest data is output to the signature generation unit 252 to instruct signature generation. Next, signature data is received from the signature generation unit 252. The received signature data is added to the OS invalidation list 266 to generate a signed OS invalidation list.

Similarly, the application invalidation list 276 instructs the hash generation unit 254 and the signature generation unit 252 to generate signature data. The generated signature data is added to the application invalidation list 276 to generate a signed application invalidation list.
Next, the generated signed OS invalidation list and signed application invalidation list are transmitted to the mobile phone 400 via the communication unit 251 and the Internet 20.

The control unit 257 receives various instructions and data from the operator via the input unit 262, and operates according to the received instructions.
(6) Input unit 262 and display unit 263
The input unit 262 receives an instruction and data input from the operator of the invalidation list issuing device 250 and outputs the received instruction and data to the control unit 257.

The display unit 263 displays various screens according to instructions from the control unit 257.
2.2 Mobile phone 400
The hardware configuration of the mobile phone 400 is substantially the same as the configuration of the mobile phone 100 shown in FIG. 2, and includes a debugger IF, CPU, MMU, secondary storage unit, switching control unit 106, interrupt controller, input unit, display unit, Consists of normal memory, shared memory, secure memory 413, memory protection unit 414, input / output unit, cryptographic processing device, wireless communication control unit, microphone, speaker, communication unit, buffer, code processing unit, and D / A conversion unit .

Since each unit other than the secure memory 413 and the memory protection unit 414 is the same as that of the mobile phone 100, detailed description thereof will be omitted, and only portions different from the mobile phone 100 will be described here.
(1) Secure memory 413
As shown in FIG. 51, the secure memory 413 stores various programs such as a music decryption program 446 and a secure OS 441.

Similar to the music decryption program 176 of the first embodiment, the music decryption program 446 includes a procedure for decrypting encrypted music data, and the description of this procedure is omitted.
The music decryption program 446 includes an application ID 447 and an invalid flag 448 in the header portion. The application ID 447 is identification information unique to the music decryption program 446. The invalid flag 448 is a flag indicating whether or not the music decryption program 446 has been invalidated, and the invalid flag “1” represents that the music decryption program 446 has been invalidated. “0” indicates that it is not invalidated.

  Since the secure OS 441 is this software that executes the same processing as the secure OS 171 of the first embodiment, description of the operation of the secure OS 441 is omitted. However, when starting each application on the secure memory 413 or returning the CPU to the secure OS 441, the secure OS 441 reads the invalid flag in the header portion of each application. If the invalid flag is “1”, the secure OS 441 starts or returns the application. Cancel.

The secure OS 441 includes a secure OSID 442 and an invalid flag 443 in the header portion.
The secure OS ID 442 is identification information corresponding to the secure OS 171. The invalid flag 443 is a flag indicating whether or not the secure OS 441 has been invalidated. The invalid flag “1” represents that the music decryption program 446 has been invalidated, and the invalid flag “0” Indicates that it has not been disabled.

In this embodiment, the secure switching device driver that is loaded onto the secure memory 413 and performs the switching process reads the invalid flag 443 of the secure OS 441 before returning the context of the secure OS 441 to the CPU, and the invalid flag is “ If “1”, the return of the secure OS 441 is stopped.
(2) Memory protection unit 414
As shown in FIG. 51, the memory protection unit 414 includes an invalidation list storage unit 421, an invalidation list update unit 424, an application verification unit 428, an application invalidation unit 429, an OS verification unit 431, and an OS invalidation unit 432. Is done.

<Invalidation list storage unit 421>
The invalidation list storage unit 421 stores an application invalidation list 422 and an OS invalidation list 423.
The application invalidation list 422 and the OS invalidation list 423 have the same configurations as the application invalidation list 276 and the OS invalidation list 266 stored in the information storage unit 260 of the invalidation list issuing device 250, respectively.

<Invalidation list update unit 424>
The invalidation list update unit 424 stores a signature verification key 426 in advance. The signature verification key 426 is the same key as the issuing device public key stored in the key storage unit 253 of the revocation list issuing device 250.
The invalidation list update unit 424 receives a connection instruction for instructing connection between the secure memory 413 and the bus 130 from the switching control unit 106. When the connection instruction is received, a list request for requesting transmission of the latest application invalidation list and OS invalidation list is transmitted to the invalidation list issuing device 250 via the wireless communication control unit and the communication unit.

Next, the signed OS invalidation list and the signed application invalidation list are received from the invalidation list issuing device 250 via the wireless communication control unit and the communication unit.
Signature verification is performed on the received signature data of the signed OS revocation list using a signature verification key. Specifically, check data is generated by applying a signature verification algorithm V to the signature data using a signature verification key. The signature verification algorithm V is an algorithm for verifying signature data generated by the signature generation algorithm S.

  Next, the received OS invalidation list is substituted into a hash function to generate OS digest data. The generated check data and digest data are compared, and if they match, it is determined that the signature verification is successful, and if they do not match, it is determined that the verification is unsuccessful. When signature verification fails, comparison of list IDs and update of the OS invalidation list, which will be described below, are stopped.

The signature verification is similarly performed on the received signed application invalidation list. If the signature verification is unsuccessful, the comparison of the application ID and update of the application invalidation list described below are stopped.
Next, the list IDs included in the received OS invalidation list and the OS invalidation list 423 stored in the invalidation list storage unit 421 are compared. If both are the same, the received OS invalidation list is discarded. If the received OS invalidation list list ID indicates a newer date than the list ID of the OS invalidation list 423 stored in the invalidation list storage unit 421, the invalidation list storage unit 421 stores the date. The existing OS invalidation list 423 is updated with the received OS invalidation list.

Similarly, for the application invalidation list, the received application invalidation list is compared with the old and new of the application invalidation list 422 stored in the invalidation list storage unit 421, and the application invalidation list 422 is older. In this case, the application invalidation list 422 in the invalidation list storage unit 421 is updated with the received application invalidation list.
<OS verification unit 431 and OS invalidation unit 432>
The OS verification unit 431 reads the secure OSID 442 from the header portion of the secure OS 441. Next, the OS revocation list 423 is read from the revocation list storage unit 421, and it is determined whether or not the read secure OSID 442 is included in the invalidation ID of the OS revocation list 423. If the secure OS ID 442 is included in the OS invalidation list 423, it is determined that the secure OS 441 is invalid, and the OS invalidation unit 432 is instructed to invalidate.

If the secure OSID 442 is not included in the OS invalidation list 423, it is determined to be valid.
The OS invalidation unit 432 receives an invalidation instruction from the OS verification unit 431 and rewrites the invalid flag in the header portion of the secure OS 441 to “1”.
<Application Verification Unit 428 and Application Invalidation Unit 429>
The application verification unit 428 reads the application ID 447 from the header portion of the music decryption program 446 on the secure memory 413. Next, the application invalidation list 422 is read from the invalidation list storage unit 421, and it is determined whether or not the application ID 447 is included in the application invalidation list 422. When the application ID 447 is included in the application invalidation list 422, it is determined that the music decryption program 446 is an invalid program, and the application invalidation unit 429 is instructed to be invalidated.

If the application ID 447 is not included in the application invalidation list, it is determined that the music decryption program 446 is a valid program.
The application invalidation unit 429 receives an invalidation instruction from the application verification unit 428 and sets the invalid flag of the music decryption program 446 to “1”.
When there are a plurality of applications on the secure memory 413, the application verification unit 428 and the application invalidation unit 429 similarly determine whether or not the application is invalid for all applications. Repeat the setting of the invalid flag.

(3) Memory Protection Unit Verification Operation The program verification operation by the memory protection unit 414 will be described with reference to the flowcharts shown in FIGS.
A connection instruction is received from the switching control unit 106 (step S671). Upon receiving the connection instruction, the invalidation list update unit 424 transmits a list request to the invalidation list issuing device 250 via the wireless communication control unit 118 and the communication unit 121 (step S672). Next, a signed OS invalidation list and a signed application invalidation list are acquired via the communication unit and the wireless communication control unit (step S673).

The revocation list update unit 424 reads the signature verification key 426, and uses the read signature verification key to perform signature verification of the obtained signed OS revocation list and signed application revocation list (step S674). If signature verification fails (NO in step S676), the process proceeds to step S681 by the OS verification unit.
If the signature verification is successful (YES in step S676), the list IDs of the OS invalidation list 423 and the application invalidation list 422 stored in the invalidation list storage unit are read (step S677). By comparing the read OS invalidation list 423 list ID with the list ID of the received OS invalidation list, and comparing the list ID of the application invalidation list 422 with the list ID of the received application invalidation list, OS invalidation It is determined whether the activation list 423 and the application invalidation list 422 are the latest version (step S678). If it is determined that it is not the latest version (NO in step S678), the OS invalidation list 423 and the application invalidation list 422 stored in the invalidation list storage unit 421 are determined based on the received OS invalidation list and the received application invalidation list. Is updated (step S679).

If it is determined that it is the latest version (YES in step S678), the process in step S679 is omitted.
When the processing by the invalidation list update unit 424 in steps S672 to 679 is completed, the OS verification unit 431 reads the secure OSID 442 from the secure memory 413 (step S681), and the read secure OSID 442 is registered in the OS invalidation list 423. Whether the secure OS 441 is invalid or valid is determined based on whether or not it has been established (step S682).

If it is determined to be valid (YES in step S683), the process proceeds to step S686 by the application verification unit 428.
If it is determined to be invalid (NO in step S683), the OS invalidation unit 432 sets the invalid flag 443 of the secure OS 441 to “1” (step S684).
When the processing up to step S684 by the OS verification unit 431 and the OS invalidation unit 432 is completed, the application verification unit 428 reads the application ID 447 of the music decryption program 446 on the secure memory 413 (step S686), and the read application ID is Whether the music decryption program 446 is valid or invalid is determined based on whether or not it is registered in the application invalidation list 422 (step S687).

If it is determined to be valid (YES in step S688), the verification process is terminated. If it is determined to be invalid (NO in step S688), the application invalidation unit 429 sets the invalid flag of the music decryption program 446 to “1” (step S689).
2.3 Summary / Effects As described above, the mobile phone 400 according to the present embodiment acquires the latest OS invalidation list and application invalidation list from the invalidation list issuing device 250 as needed. Based on the acquired OS invalidation list and application invalidation list, whether or not an application loaded on the secure memory 413 including the secure OS 441 and the music decryption program 446 stored therein is valid is stored. Judgment is made and execution of the disabled program is stopped.

By adopting such a configuration, it becomes possible to interrupt the execution of a program that has been found to be invalidated later after the mobile phone 400 is released. Can prevent unauthorized use of data.
2.4 Modification 1 of Embodiment 2
The second embodiment of the present invention may have the following configuration.
(1) Invalidation list issuing device 250
The invalidation list issuing device 250 stores an OS invalidation list and an application invalidation list. The OS invalidation list is an invalidated operating system in place of the invalidation IDs 269, 270, 271,. And a certificate ID of a secure OS certificate (to be described later).

The application revocation list is also configured to include certificate IDs of application certificates (to be described later) of revoked applications instead of the revocation IDs 279, 280, 281.
(2) Mobile phone 400
The mobile phone 400 includes a memory protection unit 454 instead of the memory protection unit 414, and includes a secure memory 453 instead of the secure memory 413. Instead of the memory protection unit 414 determining whether each program is valid or invalid based on an ID unique to each program on the secure memory 413, the memory protection unit 454 stores each program on the secure memory 453. Judge using a unique certificate.

Below, the structure which implement | achieves this function is demonstrated.
(2-1) Secure memory 453
As an example, the secure memory 453 includes a music decryption program 476 and a secure OS 481 as shown in FIG.
The secure OS 481 includes a secure OS certificate 482 and an invalid flag 483 in the header portion.

The secure OS certificate 482 is an X. As shown in FIG. 55, the public key certificate includes an issuer ID 484, a certificate ID 487, a secure OS public key 488, a signature algorithm 489, and a CA signature 491.
The issuer ID 484 is an identifier of a certificate authority (hereinafter referred to as CA: Certificate Authority) that is the issuer of the secure OS certificate 482. The secure OS public key 488 is a public key unique to the secure OS 481 whose validity is proved by the secure OS certificate 482. The signature algorithm 489 is identification information indicating the algorithm used to generate the CA signature 491. The CA signature 491 is generated by applying the algorithm S1 indicated by the signature algorithm 489 to the above-described issuer ID 484, certificate ID 487,... Using the secret key of the CA that is the issuer of the secure OS certificate 482. It is signature data.

The invalid flag 483 indicates whether the secure OS 481 is valid or invalid.
The music decryption program 476 includes an application certificate 477 and an invalid flag 478 in its header portion.
The application certificate 477 has a configuration in which the secure OS public key 488 in FIG. 55 is replaced with an application public key.

The invalid flag 478 indicates whether the music decoding program 476 is invalid or valid.
(2-2) Memory protection unit 454
As shown in FIG. 54, the memory protection unit 454 includes an invalidation list storage unit 461, an invalidation list update unit 424, a key storage unit 464, an application verification unit 468, an application invalidation unit 429, an OS verification unit 471, and an OS invalidation. The configuration unit 432 is configured.

The operations of the invalidation list update unit 424, the OS invalidation unit 432, and the application invalidation unit 429 are the same as those of the invalidation list update unit 424, the OS invalidation unit 432, and the application invalidation unit 429 of the second embodiment. Since there is, explanation is omitted here.
<Invalidation list storage unit 461>
The invalidation list storage unit 461 includes an OS invalidation list 463 and an application invalidation list 462 as shown in FIG.

The OS revocation list 463 has the same configuration as the OS revocation list stored in the revocation list issuance apparatus 250 and includes a certificate ID of the revoked operating system.
The application invalidation list 462 has the same configuration as the application invalidation list stored in the invalidation list issuing apparatus 250, and includes the certificate ID of the invalidated application.

<Key storage unit 464>
The key storage unit 464 stores a CA public key 466. The CA public key 466 is the public key of the CA that is the issuer of the secure OS certificate 482 and the application certificate 477, and the CA used for generating the CA signature included in the secure OS certificate 482 and the application certificate 477. It is a key that is paired with the secret key.

<OS verification unit 471>
When the revocation list update unit 424 finishes updating the OS revocation list and the application revocation list, the OS verification unit 471 reads the secure OS certificate 482 included in the secure OS 481 from the secure memory 453. The CA public key 466 is read from the key storage unit 464, and the signature verification is performed by applying the signature verification algorithm V1 to the CA signature 491 included in the secure OS certificate 482 using the read CA public key 466. The signature verification algorithm V1 is an algorithm for verifying the signature data generated by the signature generation algorithm S1.

If the signature verification result is unsuccessful, the subsequent processing is stopped and the OS invalidation unit 432 is instructed to invalidate the secure OS 481.
If the signature verification result is successful, whether or not the secure OS 481 is invalid is determined based on whether or not the certificate ID 487 included in the secure OS certificate 482 is registered in the OS revocation list 463. judge. If registered, it is determined that the secure OS 481 is an invalid program, and the OS invalidation unit 432 is instructed to invalidate the secure OS 481.

If not registered, the OS verification unit 471 determines that the secure OS 481 is a valid program.
In the present embodiment, signature verification of the secure OS certificate 482 is performed, and if the signature verification is successful, it is determined whether or not the certificate ID 487 is registered in the OS revocation list 463. Whether or not the certificate ID 487 is registered in the OS revocation list 463 is determined. If the certificate ID 487 is not registered, signature verification may be performed.

<App verification unit 468>
When the verification of the secure OS 481 by the OS verification unit 471 is completed, the application verification unit 468 reads the application certificate 477 included in the music decryption program 476 from the secure memory 453. The CA public key 466 is read from the key storage unit 464, and the signature verification is performed by applying the signature verification algorithm V1 to the CA signature included in the application certificate 477 using the read CA public key 466.

If the signature verification result is unsuccessful, the subsequent processing is stopped and the application invalidation unit 429 is instructed to invalidate the music decryption program 476.
If the result of the signature verification is successful, whether or not the music decryption program 476 is invalid depending on whether the certificate ID included in the application certificate 477 is registered in the application invalidation list 462 or not. Determine. If registered, it is determined that the music decryption program 476 is an invalid program, and the application invalidation unit 429 is instructed to invalidate the music decryption program 476.

If not registered, the music decryption program 476 is determined to be an effective program.
Note that the order of determining whether or not the signature verification and the certificate ID are registered in the application invalidation list 462 may be reversed.
2.5 Modification 2 of Embodiment 2
In the first modification, the music decryption program 476 may include a plurality of certificates constituting a hierarchical structure.

FIG. 56 shows the configuration of a plurality of certificates included in the music decryption program 476 and the hierarchical structure of these certificates.
As shown in FIG. 56, the music decryption program 476 includes an application certificate 501, a manufacturer certificate 511, and a CA certificate 521.
The application certificate 501 includes an issuer 502, a certificate ID 503, an application public key 504, a signature algorithm 506, and a manufacturer signature 508.

  The issuer 502 is identification information indicating the application maker that is the issuer of the application certificate 501. In FIG. 56, “application maker” is described for convenience of explanation. The certificate ID 503 is identification information unique to the application certificate 501. The application public key 504 is a public key unique to the music decryption program 476, and its validity is proved by the application certificate 501. The signature algorithm 506 is identification information indicating the signature generation algorithm used to generate the manufacturer signature 508. The manufacturer signature 508 is information included in the application certificate 501 such as an issuer 502, a certificate ID 503, an application public key 504, and a signature algorithm 506 using an application maker private key 519 unique to the manufacturer of the music decryption program 476. And signature data generated by applying the signature generation algorithm S2.

The manufacturer certificate 511 includes an issuer 512, a certificate ID 513, a manufacturer public key 514, a signature algorithm 516, and a CA signature 518.
The issuer 512 is identification information indicating the CA that is the issuer of the manufacturer certificate 511. FIG. 56 shows “CA” for convenience of explanation. The certificate ID 513 is identification information unique to the manufacturer certificate 511. The manufacturer public key 514 is the manufacturer's public key of the music decryption program 476, and its validity is proved by the manufacturer certificate 511. The manufacturer public key 514 is a key corresponding to the application manufacturer secret key 519. The signature algorithm 516 is identification information indicating the signature generation algorithm used for generating the CA signature 518. The CA signature 518 is generated by applying the signature generation algorithm S3 to information included in the manufacturer certificate 511 such as the issuer 512, the certificate ID 513, the manufacturer public key 514, and the signature algorithm 516 using the CA private key 529. Signature data.

The CA certificate 521 includes an issuer 522, a certificate ID 523, a CA public key 524, a signature algorithm 526, and a root CA signature 528.
The issuer 522 is identification information indicating the root CA that is the issuer of the CA certificate 521. FIG. 56 shows “root CA” for convenience of explanation. The certificate ID 523 is identification information unique to the CA certificate 521. The CA public key 524 is a CA public key, and its validity is proved by the CA certificate 521. The CA public key 524 is a key corresponding to the CA private key 529. The signature algorithm 526 is identification information indicating the signature generation algorithm used to generate the root CA signature 528. The root CA signature 528 uses the root CA private key 531 and uses the root CA private key 531 for information included in the CA certificate 521 such as the issuer 522, certificate ID 523, CA public key 524, and signature algorithm 526. The signature data generated by applying the signature generation algorithm S4. The root CA private key 531 is a private key unique to the root CA.

Here, as an example, CA is a manufacturer of mobile phone 400, and root CA is a public certificate issuing organization. In place of the manufacturer certificate 511, an OS certificate 482 of the secure OS 481 that controls the music decryption program 476, a certificate assigned to the mobile phone 400, and a manufacturer's certificate of the secure OS 481 may be used.
In this modification, the key storage unit 464 stores a root CA public key instead of the CA public key 466. The root CA public key is a key corresponding to the root CA private key 531. The invalidation list storage unit 461 stores a manufacturer invalidation list and a CA invalidation list in addition to the application invalidation list 462. The manufacturer invalidation list is a list including certificate IDs of invalidated manufacturer certificates, and the CA invalidation list is a list including certificate IDs of invalidated CA certificates.

First, the application verification unit 468 reads the CA certificate 521 and the root CA public key, and applies the signature verification algorithm V4 to the root CA signature 528 included in the CA certificate 521 using the read root CA public key to verify the signature. I do. The signature verification algorithm V4 is an algorithm for verifying the signature data generated by the signature generation algorithm S4.
If the signature verification fails, the application verification unit 468 stops the following processing and instructs the application invalidation unit 429 to invalidate the music decryption program 476.

If the signature verification is successful, it is next determined whether or not the certificate ID 523 included in the CA certificate 521 is registered in the CA revocation list. If registered, the application verification unit 468 And the application invalidation unit 429 is instructed to invalidate the music decryption program 476.
If it is not registered, the maker certificate 511 is read out, and the signature verification algorithm V3 is applied to the CA signature 518 included in the read maker certificate 511 using the CA public key 524 included in the CA certificate 521. Signature verification. The signature verification algorithm V3 is an algorithm for verifying signature data generated by the signature generation algorithm S3.

If the signature verification fails, the application verification unit 468 stops the following processing and instructs the application invalidation unit 429 to invalidate the music decryption program 476.
If the signature verification is successful, it is next determined whether or not the certificate ID 513 included in the manufacturer certificate 511 is registered in the manufacturer invalidation list. If registered, the application verification unit 468 And the application invalidation unit 429 is instructed to invalidate the music decryption program 476.

  If it is not registered, the application certificate 501 is read out next. Using the manufacturer public key 514 included in the manufacturer certificate 511, signature verification is performed by applying the signature verification algorithm V2 to the manufacturer signature 508 included in the read application certificate 501. The signature verification algorithm V2 is an algorithm for verifying the signature data generated by the signature generation algorithm S2.

If the signature verification fails, the application verification unit 468 stops the following processing and instructs the application invalidation unit 429 to invalidate the music decryption program 476.
If the signature verification is successful, it is next determined whether or not the certificate ID 503 included in the application certificate 501 is registered in the application revocation list 462. If registered, the application verification unit 468 The application invalidation unit 429 is instructed to invalidate the music decryption program 476.

If not registered, it is determined that the music decoding program 476 is an effective program.
Thus, higher security can be ensured by performing double and triple verification. In addition, by introducing a manufacturer certificate, all programs developed by the same manufacturer can be invalidated.

Similarly, the secure OS 481 may be verified using a plurality of certificates.
2.6 Other Modifications (1) In the second embodiment described above, the OS invalidation list includes the date when the OS invalidation list was generated as the list ID, but the OS invalidation shown in FIG. A version number may be included as a list ID 543 as in a list 541. The version information is a number indicating the generation of the OS invalidation list. A larger value indicates newer information.

Further, as shown in the OS invalidation list 551, the total number of invalidation IDs may be included as the list ID 553. Since the total number of programs to be invalidated cannot be reduced, it is possible to determine that the larger the list ID value is, the newer the OS invalidation list is, by using the total number of invalidation IDs as the list ID. it can.
(2) In the above description, the invalidation list issuing device 250 generates the OS invalidation list and the application invalidation list, but the issuer of the application invalidation list and the OS invalidation list may be different.

For example, the OS invalidation list is generated and issued by an invalidation list issuing device managed by an operating system developer. The application invalidation list is generated and issued by an invalidation list issuing device managed by the application developer.
(3) In the above embodiments and modifications, the OS verification may verify the secure application, and the application verification unit may verify the secure OS.

When the developers of secure applications and secure OSs are different, it is possible to further improve safety by mutually verifying in this way.
(4) The application invalidation list and the OS invalidation list transmitted by the invalidation list issuing device 250 are always the latest, and the application invalidation list 422 and the OS stored in the invalidation list storage unit 421 are stored. The invalidation list 423 cannot be newer than these. Accordingly, when updating the application invalidation list and the OS invalidation list, the invalidation list update unit 424 skips the comparison of the list IDs as described above, and unconditionally invalidates if the signature verification is successful. The application invalidation list 422 and the OS invalidation list 423 may be updated with the application invalidation list and the OS invalidation list received from the activation list issuing device 250.

(5) In the above embodiment, when a connection instruction is output from the switching control unit 106, each program stored in the secure memory 413 is verified. However, the verification timing is limited to this. Instead, it may be when the mobile phone 400 is turned on or when each program is started.
3. Embodiment 3
The third embodiment according to the present invention will be described below.

The mobile phone according to the present embodiment is connected to the invalidation list issuing device via the mobile phone network and the Internet as in the second embodiment.
3.1 Invalidation List Issuing Device The invalidation list issuance device according to the present embodiment is similar to the invalidation list issuance device 250 according to the second embodiment. The communication unit, the signature generation unit, the key storage unit, the hash generation unit, It comprises a control unit, an information storage unit 610, an input unit, and a display unit.

  The configuration and operation of the communication unit, signature generation unit, key storage unit, hash generation unit, input unit, and display unit are the communication unit 251, signature generation unit 252, key storage unit 253, hash included in the invalidation list issuing device 250. Almost the same as the generation unit 254, the input unit 262, and the display unit 263, the hash generation unit generates OS digest data from the OS matrix invalidation list (described later) instead of the OS invalidation list and the application invalidation list. Then, application digest data is generated from an application matrix invalidation list (described later). The description of these units is omitted, and is a feature of the present embodiment. Only the information storage unit 610 and the control unit will be described.

(1) Information storage unit 610
As shown in FIG. 58, the information storage unit 610 stores an application issue key matrix 601, an OS issue key matrix 602, application invalidation information 604, 606..., An application matrix invalidation list 611, and an OS matrix invalidation list 621. I remember it.
<Application issue key matrix 601 and OS issue key matrix 602>
As shown in FIG. 58, the application issuance key matrix 601 has 16 issuance keys Key_11, Key_12, Key_13... Arranged as matrix elements of a 4 × 4 matrix. Each issuance key is 64-bit key data generated using a pseudo random number as an example.

In the application issuance key matrix 601, row numbers “1”, “2”, “3”, “4” are arranged in the vertical direction from the top, and column numbers “1”, “2” are arranged in the horizontal direction from the left. , “3”, “4” are arranged.
The matrix element 661 corresponding to the row number “1” and the column number “1” is the issue key Key_11, and the matrix element 662 corresponding to the row number “1” and the column number “2” is the issue key Key_12. The matrix element 663 corresponding to the row number “1” and the column number “3” is the issue key Key_13, and the matrix element 664 corresponding to the row number “1” and the column number “4” is the issue key Key_14.

  Similarly, the matrix elements 665 to 668 having the row number “2” and the column numbers “1” to “4” are the issue keys Key_21, Key_22, Key_23, and Key_24, respectively. The matrix elements 669 to 672 having the row number “3” and the column numbers “1” to “4” are the issuance keys Key_31, Key_32, Key_33, and Key_34. The matrix elements 673-676 of the row number “4” and the column numbers “1” to “4” are Key_41, Key_42, Key_43, and Key_44.

In the present embodiment, a total of four issue keys are assigned to each secure application, one from each column of the application issue key matrix 601. The combination of the four issued keys is different for each secure application.
As an example, a music decryption program (described later) executed on a mobile phone includes an issue key Key_11, Key_32, Key_23, Key_14 surrounded by solid circles 677, 678, 679, and 680 in the application issue key matrix 601. Is assigned. Further, the issue key Key_21, Key_32, Key_33, and Key_44, which are surrounded by dotted circles 681, 682, 683, and 684, are assigned to a secure application (referred to as application B) different from the music decryption program.

The OS issuance key matrix 602 has the same configuration as that of the application issuance key matrix 601, and stores 16 issuance keys as matrix elements of a matrix of 4 rows × 4 columns.
<Application invalidation information 604, 606 ...>
In order to facilitate the description of the application invalidation information 604, 606..., First, the application unique key matrix and the OS unique key matrix will be described.

FIG. 59 shows an application unique key matrix 592 included in an encrypted music decryption program 591 (described later) and an OS unique key matrix included in an encrypted secure OS 596 (described later) stored in the mobile phone according to the present embodiment. 597.
The application unique key matrix 592 has a one-to-one correspondence with the music decryption program generated by decrypting the encrypted music decryption program 591, and includes four issuance keys assigned to the music decryption program. The application unique key matrix 592 includes four pieces of key information 901, 902, 903, and 904. Each key information includes a column number, a row number, and an issuance key. The key information 901 includes an issuance key Key_11 assigned to the music decryption program from the matrix element in the first column of the application issuance key matrix 601, and an application issuance. The key matrix 601 includes a row number “1” and a column number “1” corresponding to Key_11. The key information 902 includes the issue key Key_32 assigned to the music decryption program from the matrix element in the second column of the application issue key matrix 601, the row number “3” corresponding to the Key_32 on the application issue key matrix 601, and the column number “ 2 ”. The key information 903 includes the issue key Key_23 assigned to the music decryption program from the matrix element in the third column of the application issue key matrix 601, the row number “2” corresponding to the Key_23 on the application issue key matrix 601, and the column number “ 3 ”. The key information 904 includes the issue key Key_14 assigned to the music decryption program from the matrix element in the fourth column of the application issue key matrix 601, the row number “1” corresponding to the Key_14 on the application issue key matrix 601, and the column number “ 4 ”.

The OS unique key matrix 597 has the same configuration as that of the application unique key matrix, and includes key information 906, 907, 908, and 909. Each key information includes a column number and a row number issuance key.
The secure OS generated by decrypting the encrypted secure OS 596 stored in this embodiment is assigned four issue keys, one from each column of the OS issue key matrix 602. The combination of the four issuance keys differs for each operating system.

Each of the key information 906 to 909 includes a unique key assigned to the secure OS from each column of the OS unique key matrix 602 and a column number and a row number on the OS unique key matrix 602 corresponding to the unique key. .
The application invalidation information 604, 606... Is obtained by extracting the column number and the row number from each key information of the application unique key matrix of the invalidated application.

  As an example, the application invalidation information 604 corresponds to the application B described above. As shown in FIG. 58, the application invalidation information 604 includes four column numbers “1” — 931, “2” — 932, “3” — 933, “4” — 934, and a row number 935 corresponding to each column number. To 938. Column number “1” — 931 and row number “2” — 935 correspond to issue key Key — 21 assigned to application B from the first column of application issue key matrix 601. Corresponding to the issue key Key_32 assigned to the application B from the second column of the column number “2” _932, the row number “3” _936, and the pre-issue key matrix 601. Similarly, the column number “3” _933 and the row number “3” _937 correspond to the issue key Key_33, and the column number “4” and the row number “4” correspond to the issue key Key_44.

Although not specifically illustrated, the information storage unit 610 stores OS invalidation information obtained by extracting the column number and the row number from each key information of the OS unique key matrix of the invalidated operating system. Yes.
<Application Matrix Invalidation List 611 and OS Matrix Invalidation List 621>
As shown in FIG. 60, the application matrix invalidation list 611 is configured by arranging 16 matrix elements 911 to 926 in a 4 × 4 matrix. For convenience of explanation, a matrix element stored in a matrix element in the i-th row and j-th column is expressed using a variable Mij.

  The variable Mij applies the encryption algorithm E2 to the decryption key for decrypting the encrypted application including the encrypted music decryption program 591 using the issue key in the i-th row and j-th column on the application issue key matrix 601. Is generated. Enc (Key_ij, decryption key) in the figure indicates that the decryption key is generated by encryption using the issuance key Key_ij. For example, the variable M11 that is the matrix element 911 having the row number “1” and the column number “1” is the issue key Key_11 of the matrix element 661 having the row number “1” and the column number “1” on the application issue key matrix 601. Is used to encrypt the decryption key.

  Here, the application matrix invalidation list 611 is generated when the application invalidation information stored in the information storage unit 610 is only the application invalidation information 604. At this time, the matrix elements M21, M32, M33, and M44 corresponding to the row number and the column number included in the application invalidation information 604 encrypted the dummy data “0000” using the issue key instead of the decryption key. Is.

  The OS matrix invalidation list 621 has the same configuration as that of the application matrix invalidation list 611, and 16 matrix elements are arranged in a matrix of 4 rows × 4 columns. The matrix element in the i-th row and j-th column uses a decryption key for decrypting various encrypted operating systems including the encrypted secure OS 596, using the issue key arranged in the i-th row and j-th column of the OS issue key matrix 602. Is encrypted. However, the matrix element corresponding to the row number and the column number included in the OS invalidation information is obtained by encrypting dummy data instead of the decryption key.

Although not specifically shown, the application matrix invalidation list 611 and the OS matrix invalidation list include list IDs indicating the new and old.
(2) Control unit The control unit receives a list request from a mobile phone via the Internet. When the list request is received, the OS matrix invalidation list 621 and the application matrix invalidation list 611 are read from the information storage unit 610, and the signed OS matrix invalidation list to which the signature generated by the hash control unit and the signature generation unit is added. And the signed application matrix invalidation list are transmitted to the mobile phone. This is the same as the generation and transmission of the signed OS invalidation list and signed application invalidation list by the control unit 257 of the second embodiment, and detailed description thereof will be omitted.

In addition, the control unit receives an instruction to input new application invalidation information and generate an application matrix invalidation list by the operator via the input unit. In accordance with the received instruction, a new application matrix invalidation list is generated.
Also, it receives an input of new OS invalidation information and an instruction to generate an OS matrix invalidation list. In accordance with the received instruction, a new OS matrix invalidation list is generated.

The operation for generating the application matrix invalidation list will be described below using the flowchart shown in FIG. In the present embodiment, the application issue key matrix 601 and the application matrix invalidation list are configured by arranging 16 elements in a 4 × 4 matrix, but the present invention is not limited to this. In the flowchart, the case of p rows and n columns is more generally described. (P and n are integers of 1 or more)
First, a decryption key is substituted into p × n matrix elements M11, M12... Mpn (step S721). A variable j for storing the column number and a variable i for storing the row number are initialized with 0 (step S722).

Next, the application invalidation information is read (step S723), and 1 is added to the variable j (step S724). The row number corresponding to the column number j of the read application invalidation information is extracted, and the extracted row number is substituted into the variable i (step S726).
Next, dummy data “0000” is substituted into the matrix element Mij (step S727). Next, it is determined whether or not the variable j = n (step S729). If it is determined that j is not n (NO in step S729), the process returns to step S724, and steps S724 to 729 are repeated until j = n.

  If it is determined that the variable j = n (YES in step S729), it is determined whether all of the application invalidation information stored in the information storage unit 610 has been read (step S731), and the reading must be completed. If (NO in step S731), the process returns to step S722, and the processing in steps S722 to 731 is repeated for the next application invalidation information.

If it is determined that all application invalidation information has been read (YES in step S731), 0 is substituted for variable i (step S734), and 0 is substituted for variable j (step S736). Next, 1 is added to the variable i (step S737), and 1 is added to the variable j (step S739).
The issuance key Key_ij in the i-th row and j-th column of the application issuance key matrix 601 is read (step S741). Using the read issuance key Key_ij, the matrix element Mij is subjected to the encryption algorithm E2 to generate Enc (Key_ij, Mij), and the generated Enc (Key_ij, Mij) is substituted into Mij (step S742).

If variable j = n (YES in step S743), the process proceeds to step S744. If variable j = n (NO in step S743), the process returns to step S739, and step S739 is performed until variable j = n. Repeat the process of ˜743.
Next, if the variable i = p (YES in step S744), the generation of the application matrix invalidation list is terminated.

If the variable is not i = p (NO in step S744), the process returns to step S736, and the processes in steps S736 to 744 are repeated until i = p.
The OS matrix invalidation list is also generated in the same procedure using the OS issue key matrix and the OS invalidation information.
3.2 Mobile Phone The mobile phone according to the present embodiment has a configuration similar to that of the mobile phone 400 according to the second embodiment. Therefore, description of the same part as Embodiment 2 is abbreviate | omitted here, and only the characteristic part of this Embodiment is demonstrated.

(1) Secure memory 613
As an example, the secure memory 613 stores an encrypted music decryption program 591 and an encrypted secure OS 596 as shown in FIG.
The encrypted music decryption program 591 is generated by applying an encryption algorithm E3 to a music decryption program including the same music decryption procedure as the music decryption program 446 of the second embodiment. The encrypted music decryption program 591 includes an application unique key matrix 592 and an invalid flag 593 unique to the music decryption program in the header portion. The application unique key matrix 592 is as described above. The invalid flag 593 is a flag indicating whether or not the music decryption program is invalid. If it is “0”, it is valid, and if it is “1”, it is invalid.

  The encrypted secure OS 596 is generated by applying an encryption algorithm E3 to a secure OS having the same operating function as the secure OS 441 of the second embodiment. The encrypted secure OS 596 includes an OS unique key matrix 597 and an invalid flag 598 unique to the secure OS in the header portion. The OS unique key matrix 597 is as described above.

The invalid flag 598 is a flag indicating whether or not the secure OS is invalid. If the flag is “0”, the invalid flag 598 indicates that the secure OS is valid, and “1” indicates that the secure OS is invalid.
(2) Memory protection unit 571
As shown in FIG. 62, the memory protection unit 571 includes an invalidation list storage unit 572, an invalidation list update unit 575, an application verification unit 578, an application invalidation unit 579, an OS verification unit 581, an OS invalidation unit 582, and an encryption / The decoding unit 586 is configured.

  The invalidation list storage unit 572 stores an application matrix invalidation list 573 and an OS matrix invalidation list 574. The application matrix invalidation list 573 and the OS matrix invalidation list 574 have the same configuration as the application matrix invalidation list 611 and the OS matrix invalidation list stored in the information storage unit 610 of the invalidation list issuing device.

The operation of the invalidation list update unit 575 is the same as that of the invalidation list update unit 424 of the second embodiment. Instead of the application invalidation list and the OS invalidation list, the application matrix invalidation list and the OS matrix invalidation list are used. Update.
The operations of the application invalidation unit 579 and the OS invalidation unit 582 are the same as those of the application invalidation unit 429 and the OS invalidation unit 432 according to the second embodiment, and thus will not be described again here.

<Application Verification Unit 578 and OS Verification Unit 581>
The application verifying unit 578 uses the application unique key matrix 592 included in the encrypted music decryption program 591 and the application matrix invalidation list 573 stored in the invalidation list storage unit 572 to use the encrypted music decryption program 591. Generate a decryption key. If the decryption key can be correctly generated, it is determined that the music decryption program is valid. If the decryption key cannot be generated, it is determined that the music decryption program is invalid. The detailed procedure for verifying the music decoding program will be described later.

If it is determined to be valid, the generated decryption key is output to the encryption / decryption unit 586, and the decryption of the encrypted music decryption program 176 is instructed.
If it is determined to be invalid, the application invalidation unit 579 is instructed to invalidate.
Similarly to the application verification unit 578, the OS verification unit 581 determines whether the secure OS generated by decrypting the encrypted secure OS 596 is valid or invalid. Here, instead of the application unique key matrix 592 and the application matrix invalidation list 573, an OS unique key matrix 597 and an OS matrix invalidation list 574 are used.

<Encryption / Decryption Unit 586>
The encryption / decryption unit 586 receives the decryption key of the encrypted secure OS 596 from the OS verification unit 581 and is instructed to decrypt. When the decryption is instructed, the secure OS is generated by applying the decryption algorithm D3 to the encrypted secure OS 596 on the secure memory 613 using the received decryption key.

Also, the decryption key of the encrypted music decryption program 591 is received from the application verification unit 578, and decryption is instructed. Using the received decryption key, the decryption algorithm D3 is applied to the encrypted music decryption program 591 to generate a music decryption program.
Here, D3 is an algorithm for decrypting the ciphertext generated by the encryption algorithm E3, and DES, AES (Advanced Encryption Standard), or the like is used as an example.

In addition, a disconnection instruction output from the switching control unit 576 for instructing disconnection between the secure memory 613 and the bus 130 is detected. When the disconnection instruction is detected, the encrypted music decryption program 591 and the encrypted secure OS 596 are generated by encrypting the music decryption program and the secure OS with the received decryption key.
(3) Verification Operation by Memory Protection Unit 571 The verification operation of the program on the secure memory 613 by the memory protection unit 571 will be described with reference to the flowchart of FIG.

  The memory protection unit 571 receives a connection instruction (step S701). Upon receiving the connection instruction, the invalidation list update unit 575 acquires the latest application matrix invalidation list and OS matrix invalidation list from the invalidation list issuing device via the Internet, and stores them in the invalidation list storage unit 572. The stored application matrix invalidation list 573 and OS matrix invalidation list 574 are updated (step S702). The processing in step S702 by the invalidation list update unit 575 is the same as the processing in steps S672 to 679 (FIG. 49) by the invalidation list update unit 424 of the second embodiment, and the OS invalidation list is converted into an OS matrix invalidation list. And the application invalidation list may be replaced with the application matrix invalidation list.

Next, the OS verification unit 581 verifies the secure OS (step S703), and determines that the secure OS is valid (YES in step S706), instructs the encryption / decryption unit 586 to decrypt the encrypted secure OS 596. Then, the encryption / decryption unit 586 decrypts the encrypted secure OS 596 to generate a secure OS (step S707).
If it is determined that the secure OS is invalid (NO in step S706), the OS invalidation unit 582 is instructed to set the invalid flag 598 to “1” (step S709).

Next, the application verification unit 578 verifies whether or not the music decryption program is valid (step S711). If it is determined to be valid (YES in step S712), the encryption / decryption unit 586 decrypts the encrypted music decryption program 591 to generate a music decryption program (step S713).
If determined to be invalid (NO in step S712), the application invalidation unit 579 sets the invalid flag 593 to “1” (step S716).

(4) Verification of Music Decoding Program The following describes the music decoding program verification processing by the application verification unit 578 with reference to the flowchart of FIG. This is the detail of step S711 in FIG. In this embodiment, the application matrix invalidation list 573 forms a matrix of 4 rows × 4 columns, and the application unique key matrix 592 includes 4 pieces of key information. More generally, a case will be described in which the application matrix invalidation list 573 constitutes a matrix of n rows and p columns, and the application unique key matrix 592 is constituted of p pieces of key information.

The application verification unit 578 reads the application unique key matrix 573 (step S731). For convenience of explanation, a variable i indicating a row number and a variable j indicating a column number will be introduced for explanation.
The application verification unit 578 substitutes 1 for the variable j (step S732). The row number corresponding to the column number j in the application unique key matrix 592 is substituted into the variable i (step S733).

  Next, the matrix element Mij is read from the application matrix invalidation list 573 (step S736). The issue key Key_ij is extracted from the application unique key matrix 592, and the read matrix element Mij is decrypted by applying the decryption algorithm D2 using the extracted issue key Key_ij (step S737). If the decryption result is not “0000” (NO in step S739), it is determined that the music decryption program is valid (step S741), and the decryption result, that is, the decryption key of the encrypted music decryption program 591 is used as the encryption / decryption unit 586. (Step S742).

If the processing result is “0000” (YES in step S739), it is next determined whether or not the variable j = p. If j = p is not satisfied (NO in step S744), 1 is added to the variable j. (Step S747), the process returns to step S733.
If variable j = p (YES in step S744), it is determined that the music decoding program is invalid (step S746).

Note that the verification of the secure OS by the OS verification unit 581 in step S703 is performed by replacing the application unique key matrix in the flowchart of FIG. 61 with the OS unique key matrix and replacing the application matrix revocation list with the OS matrix revocation list. Therefore, explanation is omitted.
3.3 Summary / Effects As described above, in the third embodiment, the encrypted music decryption program 591 and the encrypted secure OS 596 on the secure memory 613 of the mobile phone each have a unique application unique key matrix 592. , OS unique key matrix 597 is included.

The memory protection unit 571 determines whether or not the music decryption program is valid based on the application matrix invalidation list 573 and the application unique key matrix 592. Only when it is valid, a decryption key can be generated from the application matrix invalidation list 573.
Similarly, the secure OS is also determined to be valid using the OS matrix invalidation list 574 and the OS unique key matrix.

Consider a case where an application manufacturer ships a plurality of applications encrypted by the same method using the same encryption key.
Of the 16 keys constituting the application issuance key matrix 601 in FIG. 58, a total of 4 issuance keys are assigned to each application, one from each column. At this time, the four issuance keys assigned to different applications are assigned so as not to match. As an example, the music decryption program of this embodiment is assigned issuance keys Key_11, Key_32, Key_23, and Key_14, and these issuance keys are included in the application unique key matrix 592 of the encrypted music decryption program 591. .

Issuing keys Key_21, Key_32, Key_33, and Key_44 are assigned to an application (referred to as application B) shipped from the same manufacturer as the music decryption program, and the application issuing key matrix of the encrypted application B includes these keys. These four issuance keys are included.
Here, when it is determined that the application B is a program to be invalidated after shipment, the application invalidation information 604 is added to the invalidation list issuing device. The application invalidation information 604 is composed of four issue keys assigned to the application B and corresponding column numbers and row numbers. The application matrix invalidation list 611 generated based on the application invalidation information 604 includes dummy data in the matrix elements M21, M32, M33, and M44, as shown in FIG. With the four issued keys, a decryption key cannot be generated.

As shown in FIG. 58, Key_32 is also assigned to the music decryption program. However, according to the verification operation described with reference to the flowchart of FIG. 64, a decryption key can be generated using another issue key.
In this way, if a plurality of issuance keys are assigned to each application and a decryption key is generated using the application revocation list and the issuance key, the application is invalidated even if encrypted using the same method. Only applications that should be enabled can be disabled.

  Further, the encryption / decryption unit 586 re-encrypts the secure OS and the application including the music decryption program when the secure memory 613 and the bus are disconnected. Therefore, the program on the secure memory 613 can be more reliably protected while the program on the normal memory uses the CPU. In such a configuration, the memory protection unit may not physically disconnect the bus and the secure memory 613.

3.4 Modifications (1) In the third embodiment, the memory protection unit 571 receives the connection instruction from the switching control unit 106 and receives the latest OS matrix invalidation list and application matrix via the communication control unit. The invalidation list is acquired, these are updated, and each program on the secure memory 613 is verified. However, the timing for updating the OS matrix invalidation list and the application matrix invalidation list and verifying each program on the secure memory 613 is not limited to this.

As an example, the cellular phone may be activated or may be performed periodically, such as once a day. Further, at the time of activation, the OS matrix invalidation list and the application matrix invalidation list may be updated, and the program may be verified when a connection instruction is received after the activation.
Also, when starting each program, for example, when switching from the normal OS to the secure OS, the secure OS is verified, and when the secure OS starts the music decryption program, the music decryption program is verified. It is good.

  Further, a list request is transmitted from the memory protection unit 571 to the invalidation list issuing device, and the latest OS matrix invalidation list and application matrix invalidation list are acquired. When the matrix invalidation list and the application matrix invalidation list are created again, they may be transmitted from the invalidation list issuing device to the mobile phone.

(2) Although the mobile phone acquires the latest OS matrix invalidation list and application matrix invalidation list via the Internet, it may be obtained from a recording medium such as a memory card.
(3) Although the cellular phone has been described as an embodiment of the present invention, it may be a communication device that constitutes a LAN as described below.

Any one of the devices constituting the LAN may acquire the latest invalidation list and distribute it to other devices.
As an example, it is a device forming a home network as shown in FIG. The home network is configured by connecting a PC (Personal Computer) 650, a notebook PC 651, a DVD player 652, a home server 653, and a microwave oven 654 by a bus.

Each device includes a secure memory that cannot be directly accessed from a normal operating system or application, and has a function of verifying the effectiveness of various applications and operating systems that are loaded onto the secure memory and executed.
The home server 653 is connected to the Internet 20 and periodically requests the invalidation list issuing device 250 for an application invalidation list and an OS invalidation list. The latest application invalidation list and OS invalidation list are acquired from the invalidation list issuing device 250 via the Internet. The acquired invalidation list is output to each device constituting the home network via the bus.
4). Embodiment 4
Embodiment 4 of the present invention will be described below.

4.1 Configuration of Mobile Phone Similar to the mobile phone 100 of the first embodiment, the mobile phone of the present embodiment includes a debugger IF, a CPU 102, an MMU, a secondary storage unit, a switching control unit, an interrupt controller, and an input unit. , Display unit, normal memory, shared memory, secure memory 713, memory protection unit 701, input / output unit, cryptographic processing device, wireless communication control unit, microphone, speaker, communication unit, antenna, buffer, code processing unit, D / A The circuit is composed of a conversion unit, and each circuit is connected to a bus.

In the mobile phone of this embodiment, the configuration and operation of each unit other than the memory protection unit 701 and the secure memory 713 are the same as those in Embodiment 1, and thus the description thereof is omitted. Here, the features of this embodiment are described. Only the part will be described.
(1) Secure memory 713
As shown in FIG. 66, the secure memory 713 stores a secure application such as a music decryption program 704 and a communication key generation program 706, and a secure OS 707.

The music decryption program 704 is a secure application including the same music decryption processing procedure as the music decryption program 176 of the first embodiment.
The communication key generation program 706 is a secure application that generates an encryption key when the mobile phone transmits / receives content via the Internet.
The secure OS 707 is an operating system similar to the secure OS 171 of the first embodiment.

Here, each program on the secure memory 713 outputs its own access information to the access management unit 702 when started on the secure memory. The access information is an address of a memory area that can be accessed by each program.
(2) Memory protection unit 701
The memory protection unit 701 includes an access management unit 702 and a signal monitoring unit 703 as shown in FIG.

The access management unit 702 receives access information from each program on the secure memory 713 and stores the received access information in association with the corresponding program. Each program is provided with a counter that counts the number of unauthorized accesses.
The signal monitoring unit 703 stores in advance the number of times unauthorized access of each program is permitted (allowable number). The signal monitoring unit 703 monitors a signal on the bus between the secure memory 713 and the CPU, and detects an address on the secure memory 713 that is an access target of the CPU.

Next, the access information of the program currently being executed is read from the access management unit 702, and the read access information is compared with the detected address. If the detected address is included in the storage area indicated by the read access information, monitoring is continued as it is.
If not included, the access management unit 702 adds 1 to the counter stored in association with the corresponding program. Next, the counter is compared with the stored allowable number of times. If the counter is less than the allowable number of times, monitoring is continued as it is.

If the counter exceeds the allowable number of times, it is determined that the corresponding program is invalid.
If the program determined to be illegal is the music decryption program 704, the signal monitoring unit 703 forcibly stops the execution of the music decryption program 704 and transfers the execution right of the CPU 102 to the secure OS 707. .
The same applies when the program determined to be illegal is another secure application.

If the program determined to be illegal is the secure OS 707, the signal monitoring unit 703 forcibly stops the execution of the secure OS 707, clears the CPU 102 and the MMU, and outputs a switching instruction to the switching control unit.
4.2 Summary / Effects As described above, the mobile phone of the present invention monitors the operation of each program loaded in the secure memory 713 and stops executing a program that repeats an illegal operation. In this way, even if a program in the secure memory 713 has a defect or an unauthorized alteration is made during execution, the execution of these programs can be stopped.

4.3 Modification of Embodiment 4 (1) In the above embodiment, the memory protection unit 701 detects an illegal operation by monitoring a signal on the bus by the signal monitoring unit 703. Instead of this, the program counter value of the CPU may be periodically monitored.
(2) In the above embodiment, each program on the secure memory 713 outputs different access information for each program at the time of activation, and the signal monitoring unit 703 is based on the access information. Although the operation of each program is monitored, the access management unit 702 may store information indicating the access prohibited area on the secure memory 713 in advance. In this case, when any program is being executed, if the attempt is made to access the prohibited area, the signal monitoring unit stops the program execution by the CPU 102, clears the CPU 102 and the MMU, and outputs a switching instruction to the switching control unit. To do.

(2) In the present embodiment, as described in the second embodiment, the memory protection unit 701 includes an invalidation list storage unit, an application verification unit, an application invalidation unit, an OS verification unit, and an OS invalidation unit. When a connection instruction is received from the switching control unit, it may be determined whether each program on the secure memory is valid.
In this configuration, the signal monitoring unit 703 finds a program that performs an illegal operation during the operation, stops the operation of the program, and disables the OS invalidation list or application invalidation stored in the invalidation list storage unit. A secure OSID or application ID corresponding to the program that performed the illegal operation is added to the list.

By doing in this way, the newly discovered invalid program will not be executed again.
5. Embodiment 5 Embodiment 5 of the present invention will be described below.
The cellular phone 750 of the fifth embodiment has two memory cards. One of the memory cards stores an OS (operating system) and various applications, and the mobile phone 750 reads and executes these programs. For convenience of explanation, this memory card is called a normal memory card 800.

The other memory card stores an encrypted program for performing processing to be protected. Each program is composed of a program part and a data part. For convenience of explanation, this memory card is referred to as a secure memory card 820.
The cellular phone 750 permits each program on the secure memory card 820 to read the program portion of the other program, but prohibits reading the data portion of the other program.

5.1 Secure memory card 820
As shown in FIG. 67, the secure memory card 820 includes an input / output unit 821 and an information storage unit 830.
Specifically, the secure memory card 820 is a computer system including a microprocessor, a RAM, and a ROM, and computer programs are stored in the RAM and the ROM. The secure memory card 820 achieves a part of its functions by the microprocessor operating according to the computer program.

The input / output unit 821 inputs / outputs information to / from an external device.
The information storage unit 830 stores a secure ID 850, an encrypted music decryption program 831, an encryption key generation program 841, and the like.
The secure ID 850 is information unique to the secure memory card 820, and indicates that the secure memory card 820 stores a program for performing secure processing.

The encrypted music decryption program 831 includes an ID 832 “A”, an encryption / decryption program 834, and encrypted decryption data 836. ID 832 “A” is identification information unique to the encrypted music decryption program 831.
The encryption / decryption program 834 is generated by encrypting a decryption program including a procedure for decrypting music data. The encryption / decryption data 836 encrypts data such as parameters used by the decryption program for decryption processing. It has become.

The encryption key generation program 841 includes an ID 842 “B”, an encryption generation program 844, and encryption key data 846.
The ID 842 “B” is identification information unique to the encryption key generation program 841. The encryption generation program 844 is an encryption of a generation program including a procedure for generating an encryption key, and the encryption key data 846 is an encryption of data such as parameters used by the generation program.

5.2 Normal memory card 800
The normal memory card 800 includes an input / output unit 801 and an information storage unit 802 as shown in FIG.
The input / output unit 801 inputs and outputs various types of data between the information storage unit 802 and the external device.

  The information storage unit 802 stores various applications such as a music playback program 808 and an OS 806. The program stored in the information storage unit 802 is composed of a code part and a data part including a procedure of processing executed by each program. Each program has a unique program ID. As an example, the OS 806 has a program ID “OS”, and the music playback program 808 has a program ID “E”.

5.3 Mobile phone 750
68, the mobile phone 750 includes a debugger IF 751, a CPU 752, an MMU 753, an interrupt controller 757, an input unit 758, a display unit 759, a memory 761, a memory protection unit 764, an input / output unit 765, an input / output unit 766, A wireless communication control unit 768, a communication unit 771, an antenna 772, a microphone 769, a speaker 770, a buffer 773, a code processing unit 774, and a D / A conversion unit 776 are connected by a bus 760.

  Debugger IF 751, MMU 753, interrupt controller 757, input unit 758, display unit 759, wireless communication control unit 768, communication unit 771, antenna 772, microphone 769, speaker 770, buffer 773, code processing unit 774 D / A conversion unit 776 Since the operation and configuration are the same as those of the first embodiment, description thereof is omitted here. The memory 761 stores various data and programs, and the CPU 752 fetches instructions included in the programs stored in the memory 761, the normal memory card 800, and the secure memory card 820 one by one. Decode and execute the command.

Hereinafter, the memory protection unit 764, the input / output unit 765, and the input / output unit 766, which are features of this embodiment, will be described.
(1) Input / output unit 765 and input / output unit 766
The input / output unit 765 and the input / output unit 766 are connected to one of the two memory cards, and input / output information between the memory card and the memory protection unit 764.

(2) Memory protection unit 764
As shown in FIG. 69, the memory protection unit 764 includes a decryption unit 781, a decryption key storage unit 782, an access control unit 783, a key storage unit 784, a memory information storage unit 785, and an ID detection unit 786.
(2-1) Key storage unit 784
The key storage unit 784 stores the decryption key of the encrypted music decryption program 831 and the decryption key of the encryption key generation program 841 in association with the ID of each program.

(2-2) Decryption unit 781 and decryption key storage unit 782
The decryption unit 781 receives the decryption instruction and the ciphertext from the access control unit 783. When the decryption instruction is received, the decryption key is read from the decryption key storage unit 782, and the encrypted data is decrypted using the read decryption key to generate plain text. The generated plaintext is output to the CPU 752.
Here, the encrypted data decrypted by the decryption unit 781 is encrypted data constituting the encrypted music decryption program 831 and the encryption key generation program 841 stored in the secure memory card 820.

The decryption key storage unit 782 stores only one decryption key used by the decryption unit 781.
(2-3) Memory information storage unit 785
As shown in FIG. 70, the memory information storage unit 785 stores a secure memory information table 811 and a normal memory information table 861.
The secure memory information table 811 includes a plurality of secure memory information 812, 813,. Each secure memory information includes a program ID, a code address, and a data address.

  The program ID is an ID of each program stored in the secure memory card 820. The code address is an address indicating an area where the program portion of the encrypted application stored in the secure memory card 820 is stored. The data address is an address indicating an area in which the data portion of the encrypted application is stored.

Specifically, the secure memory information 812 includes an ID “A” 832 of the encrypted music decryption program 831 as a program ID and an address “A000 to A111” stored in the encryption / decryption program 834 as a code address. The data addresses include addresses “A222 to A333” in which the encrypted / decrypted data 836 is stored.
The secure memory information 813 includes an ID “B” 842 of the encryption key generation program 841 as a program ID, an address “A444 to A555” stored as an encryption generation program 844 as a code address, and a data address as The address “A666 to A777” where the encryption key data 846 is stored is included.

The normal memory information table 861 includes a plurality of normal memory information 862, 863..., And each normal memory information includes a program ID, a code address, and a data address.
The program ID is an ID of a program normally stored on the memory card 800, the code address is an address indicating the area where the program portion of the program corresponding to the program ID is stored, and the data address is data This is the address of the area where the part is stored.

Specifically, the normal memory information 862 corresponds to the OS 806 stored on the normal memory card 800, and the normal memory information 863 corresponds to the music playback program 808.
(2-4) ID detection unit 786
The ID detection unit 786 constantly monitors a program counter (hereinafter referred to as a PC) of the CPU 752, and while the CPU 752 is executing a program on the secure memory card 820, a program ID indicating a program being executed by the CPU 752 is displayed. I remember it.

The operation of the ID detection unit 786 will be described below using the flowchart of FIG. For convenience of description, the description starts from step S801. At this time, the CPU 752 is executing a program stored on the normal memory card 800 or the memory 761.
The ID detection unit 786 monitors the PC (step S801), shows the code address of each program included in the secure memory information table 811 and the normal memory information table 861 stored in the memory information storage unit 785, and the PC By comparing with the address, it is determined whether or not the address indicated by the PC is an address on the secure memory card 820 (step S802).

If the address is not on the secure memory card 820 (NO in step S802), PC monitoring is continued.
If it is determined that the address is on the secure memory card 820 (YES in step S802), then the secure memory information corresponding to the address detected from the PC is selected from the secure memory information table 811 and included in the selected secure memory information. The program ID is extracted (step S803). The extracted program ID is stored (step S804). Next, a secure access notification indicating that execution of the program on the secure memory card 820 is started is output to the access control unit 783 (step S805).

Next, the PC is monitored (step S806), and it is determined whether or not the address stored in the PC is an address on the secure memory card 820 (step S807).
If it is determined that the address is on the secure memory card 820 (YES in step S807), secure memory information corresponding to the address detected from the PC is selected from the secure memory information table 811 and the program ID included in the selected secure memory information is selected. Is extracted (step S809). The extracted program ID is compared with the program ID stored in the ID detection unit 786 itself. If they match (YES in step S811), the process returns to step S806 to continue monitoring the PC.

If they do not match (NO in step S811), the stored program ID is rewritten to the extracted program ID (step S812), and the process returns to step S806.
If it is determined in step S807 that the address is not on the secure memory card 820 (NO in step S807), the program ID stored in the ID detection unit 786 itself is deleted (step S814), and the process returns to step S801.

(2-5) Access control unit 783
The access control unit 783 stores a secure ID written in the secure memory card 820 in advance.
It is detected through the input / output unit 765 and the input / output unit 766 that a memory card is inserted. When it is detected that the memory card is inserted, the data written in the memory card is searched. When the same secure ID 850 as the stored secure ID is detected, it is detected that the memory card is the secure memory card 820. Here, it is assumed that the input / output unit 265 is connected to the normal memory card 800 and the secure memory card 820 is connected to the secure memory card 820.

When the access control unit 783 detects the attachment of the normal memory card 800 via the input / output unit 765, the access control unit 783 searches the information stored in the normal memory card 800 via the input / output unit 765, and stores the normal memory information table. The generated normal memory information table is stored in the memory information storage unit 785.
Further, when the installation of the secure memory card 820 is detected via the input / output unit 766, information stored in the secure memory card 820 is searched via the input / output unit 766, and a secure memory information table is generated. The generated secure memory information table is written into the memory information storage unit 785.

When the CPU 752 accesses the normal memory card 800, the access control unit 783 mediates a signal output from the CPU 752 (hereinafter referred to as an access signal) to the normal memory card 800 as it is, and from the normal memory card 800, The output data is received, and the received data is output to the CPU 752.
When the CPU 752 accesses the secure memory card 820, the access destination address is extracted from the access signal, and reading or reading of the secure memory card 820 data is prohibited by the extracted address. The operation of the access control unit 783 will be described in detail with reference to the flowcharts shown in FIGS. For convenience of description, the description starts from step S821. At this time, the CPU 752 is executing a program on the normal memory card 800 or the memory 761.

The access control unit 783 mediates data input / output between the CPU 752 and the normal memory card 800 (step S821).
A secure access notification indicating that the execution of the program on the secure memory card 820 is started is received from the ID detection unit 786 (step S805).
Upon receiving the secure access notification, the access control unit 783 invalidates the debugger IF 751 (step S823), and reads the program ID stored in the ID detection unit 786 (step S824). The decryption key corresponding to the read program ID is read from the key storage unit 784 (step S826), and the read decryption key is written to the decryption key storage unit 782 (step S827).

Next, the access signal output from the CPU 752 is received, and the access destination address is detected from the received access signal (step S829).
When the access destination address is detected, the program ID is read from the ID detection unit 786 (step S831). When the program ID is read (YES in step S832), secure memory information including the access destination address detected in the code address or data address is selected from the secure memory information table 811, and the program ID is extracted from the selected secure memory information. (Step S834).

The extracted program ID is compared with the program ID read from the ID detection unit 786. If the two match (YES in step S836), the process proceeds to step S844.
If the two do not match (NO in step S836), the access control unit 783 further determines whether the detected address is included in the code address of the selected secure memory information or the data address. Is determined (step S838). If it is determined that the data address is included (NO in step S838), an error notification indicating that access cannot be permitted is output to the CPU 752, and the process returns to step S829.

If it is determined that it is included in the code address (YES in step S838), the decryption key corresponding to the extracted program ID is read from the key storage unit 784, and the decryption key stored in the decryption key storage unit 782 is read. The decryption key is changed (step S842).
Next, the information stored in the storage area corresponding to the address detected via the input / output unit 766 is read (step S844). The decoding unit 781 is instructed to decode the read information (step S846), and the process returns to step S829.

In step S832, when the program ID stored in the ID detection unit 786 does not exist (NO in step S832), the access control unit 783 deletes the decryption key stored in the decryption key storage unit 782 (step S851). ), The debugger IF 751 is enabled (step S852), and the process returns to step S821.
5.4 Summary / Effects As described above, the mobile phone of the present invention executes a program stored in a normal memory card and a secure memory card. The program stored in the secure memory card is encrypted in advance.

When the CPU 752 executes a program stored in the secure memory card 820, the memory protection unit 764 manages an area where access is permitted and an area where access is prohibited by the program being executed.
The case where the music decryption program is executed will be described as an example. The CPU 752 includes an area where the encrypted music decryption program 831 included in the encrypted music decryption program 831 is stored, and an encryption generation program of the encryption key generation program. The area 844 stored can be accessed, but the area stored the encryption key data 846 of the encryption key generation program cannot be accessed.

In this way, each application on the secure memory card 820 can be prevented from being illegally read and changed by accessing its own data part from other applications.
Further, since the information stored in the secure memory card 820 is encrypted, even when the secure memory card 820 is accessed while the CPU 752 is executing a program other than the program on the secure memory card 820. Can't decipher. Therefore, the data on the secure memory card 820 can be protected from unauthorized access.
5.5 Modification Regarding Embodiment 5 In the above embodiment, when the CPU 752 tries to access the data portion of another application while the secure application on the secure memory card 820 is being executed, the access control unit 783 Although the error notification is output to the CPU 752, the execution right of the CPU 752 may be transferred to another program such as the OS 806 as in the case of the fourth embodiment. In this case, the access control unit 783 deletes the decryption key stored in the decryption key storage unit 782, and sets the address stored in the OS 806 in the program counter of the CPU 782.
6). Other Modifications Although the present invention has been described above with reference to the first to fifth embodiments, the present invention is not limited to these embodiments, and includes the following cases.

(1) The present invention may be a method for executing the above-described first to third embodiments and modifications.
(2) Further, the present invention may be a computer program that realizes these methods by a computer, or may be a digital signal composed of the computer program.
The present invention also provides a computer-readable recording medium such as a flexible disk, hard disk, CD-ROM, MO, DVD, DVD-ROM, DVD-RAM, BD (Blu-ray Disc). ), Recorded in a semiconductor memory or the like. Further, the present invention may be the computer program or the digital signal recorded on these recording media.

Further, the present invention may transmit the computer program or the digital signal via an electric communication line, a wireless or wired communication line, a network represented by the Internet, a data broadcast, or the like.
The present invention may be a computer system including a microprocessor and a memory, wherein the memory stores the computer program, and the microprocessor operates according to the computer program.

In addition, the program or the digital signal is recorded on the recording medium and transferred, or the program or the digital signal is transferred via the network or the like, and is executed by another independent computer system. It is good.
(3) The above embodiment and the above modifications may be combined.

  Each apparatus and recording medium constituting the present invention manufactures industries that handle information that needs to be protected, such as industries that create and distribute contents including video and audio, and electrical equipment that handles these information. And can be used in the selling industry in a management, continuous and repetitive manner. In addition, each device and recording medium constituting the present invention can be manufactured and sold in the electric appliance manufacturing industry in a management manner, continuously and repeatedly.

FIG. 1 shows an example of use of the mobile phone 100 of the first embodiment. FIG. 2 is a block diagram showing the configuration of the mobile phone 100 and the memory card 300. FIG. 3 shows an example of information stored in the secondary storage unit 104. FIG. 4 shows an example of information stored in the normal memory 111. FIG. 5 shows details of the application management table 166. FIG. 6 shows an example of information stored in the secure memory 113. FIG. 7 shows details of the secure application management table 186. FIG. 8 is a block diagram showing the relationship between programs stored in the normal memory 111 and the secure memory 113. The data structure of the command which normal OS151 and the secure memory 113 handle is shown. 5 is a flowchart showing the operation of a normal OS 151. 3 is a flowchart showing the operation of a secure OS 171. It is a flowchart which shows operation | movement of the music decoding daemon 156. 6 is a flowchart showing a process for switching from a normal OS 151 to a secure OS 171. 5 is a flowchart showing a switching process from a secure OS 171 to a normal OS 151. 3 is a flowchart showing the operation of the mobile phone 100. It is the flowchart which showed the operation | movement of each program in the registration process of a music decoding program. It is the flowchart which showed the operation | movement of each program in the registration process of a music decoding program. Continuing from FIG. It is the flowchart which showed the operation | movement of each program in the processing request to the music decoding program 176. It is the flowchart which showed the operation | movement of each program in the processing request to the music decoding program 176. It continues from FIG. It is the flowchart which showed the operation | movement of each program in the processing request to the music decoding program 176. It continues from FIG. It is the flowchart which showed the operation | movement of each program in the processing request to the music decoding program 176. It continues from FIG. It is the flowchart which showed the operation | movement of each program in the processing request to the music decoding program 176. It continues from FIG. It is the flowchart which showed the operation | movement of each program in the processing request to the music decoding program 176. Continuing from FIG. It is the flowchart which showed the operation | movement of each program in the processing request to the music decoding program 176. It continues from FIG. It is the flowchart which showed the operation | movement of each program in the processing request to the music decoding program 176. It continues from FIG. It is the flowchart which showed the operation | movement of each program in the processing request to the music decoding program 176. Continuing from FIG. It is the flowchart which showed the operation | movement of each program in the processing request to the music decoding program 176. Continuing from FIG. 7 is a flowchart showing processing when an interrupt is generated by the normal input / output device 132 during execution of the normal OS 151. FIG. 21 shows details of step S239. 7 is a flowchart illustrating processing when an interrupt is generated by the normal input / output device 132 during execution of the secure OS 171. 10 is a flowchart illustrating processing when an interrupt is generated by the secure device 133 during execution of the normal OS 151. FIG. 23 shows details of step S287. 10 is a flowchart illustrating processing when an interrupt is generated by the secure device 133 during execution of the normal OS 151. It continues from FIG. 10 is a flowchart showing processing when an interrupt is generated by the cryptographic processing device 117 during execution of the normal OS 151. FIG. 27 shows details of step S337. 10 is a flowchart showing processing when an interrupt is generated by the cryptographic processing device 117 during execution of the normal OS 151. It continues from FIG. 10 is a flowchart showing processing when an interrupt is generated by the cryptographic processing device 117 during execution of the normal OS 151. It continues from FIG. It is the flowchart which showed the deletion process of the music decoding program 176. In the operation of the mobile phone 100, a command exchange between programs is shown. In the operation of the mobile phone 100, a command exchange between programs is shown. In the operation of the mobile phone 100, a command exchange between programs is shown. It continues from FIG. In the operation of the mobile phone 100, a command exchange between programs is shown. It continues from FIG. In the operation of the mobile phone 100, a command exchange between programs is shown. It continues from FIG. In the operation of the mobile phone 100, a command exchange between programs is shown. It continues from FIG. In the operation of the mobile phone 100, a command exchange between programs is shown. It continues from FIG. An example of information stored in the normal memory 111 is shown. 4 is a flowchart showing an operation when the mobile phone 100 is activated. An example of information stored in the secure memory 113 is shown. An example of a logical memory space formed by the MMU control program 184 is shown. FIG. 10 is a block diagram showing a relationship between programs in a modification of the first embodiment. In the modification of Embodiment 1, the structure of the secure device driver management table 231 which the normal OS 151 and the secure OS 171 have is shown. The usage example of the mobile phone 400 of Embodiment 2 is shown. 3 is a block diagram showing a configuration of an invalidation list issuing device 250. FIG. 4 is a block diagram showing a configuration of a memory protection unit 414 and a secure memory 413 included in a mobile phone 400. FIG. 10 is a flowchart showing the operation of the memory protection unit 414. 10 is a flowchart showing the operation of the memory protection unit 414. Continuing from FIG. FIG. 22 is a block diagram showing configurations of a memory protection unit 454 and a secure memory 453 in a modification example of the second embodiment. Details of the secure OS certificate are shown. In the modification of Embodiment 2, the structure and relationship of the application certificate 501, the manufacturer certificate 511, and the CA certificate 521 provided in the music decryption program 476 are shown. An example of a structure of OS invalidation list is shown. An example of the information memorize | stored in the information storage part 610 of the invalidation list issuing apparatus in Embodiment 3 is shown. The configurations of the application unique key matrix 592 and the OS unique key matrix 597 are shown. The detailed structure of the application matrix invalidation list 611 is shown. It is a flowchart which shows the process sequence of the production | generation of an application matrix invalidation list. FIG. 10 is a block diagram illustrating configurations of a memory protection unit 571 and a secure memory 613 included in a mobile phone according to a third embodiment. 5 is a flowchart showing a verification operation by a memory protection unit 571. 21 is a flowchart showing a verification operation of a music decryption program 592 by an application verification unit 578. FIG. 10 is a configuration diagram illustrating a configuration of a home network according to a modification of the third embodiment. FIG. 10 is a block diagram illustrating configurations of a memory protection unit 701 and a secure memory 713 that constitute a mobile phone according to a fourth embodiment. In the fifth embodiment, an example of the configuration of the secure memory card 820 and information stored in the secure memory card 820 is shown. FIG. 10 is a block diagram showing configurations of a mobile phone 750 and a normal memory card 800 and a secure memory card 820 that are attached to the mobile phone 750 of the fifth embodiment. 7 is a block diagram showing a configuration of a memory protection unit 764. FIG. The configurations of the secure memory table 811 and the normal memory table 861 are shown. 10 is a flowchart showing operations of an access control unit 783 and an ID detection unit 786. It is a flowchart which shows operation | movement of the access control part 783. It continues from FIG.

Explanation of symbols

10 mobile phone network 15 base station 20 internet 100 mobile phone 101 debugger IF
102 CPU
103 MMU
104 Secondary storage unit 106 Switching control unit 107 Interrupt controller 108 Input unit 109 Display unit 111 Normal memory 112 Shared memory 113 Secure memory 114 Memory protection unit 116 Input / output unit 117 Cryptographic processing device 118 Wireless communication control unit 119 Microphone 120 Speaker 121 Communication unit 122 Antenna 123 Buffer 124 Code processing unit 126 D / A conversion unit 130 Bus 131 Access unit 132 Normal input / output device 133 Secure input / output device 300 Memory card

Claims (61)

A data processing apparatus that executes a program by switching between a secure mode in which use of a secure resource to be protected is permitted and a normal mode in which only use of a normal resource that is not protected is permitted,
Normal storage means for storing a normal program composed of one or more processing procedures using the normal resource;
Secure storage means configured to store one or more processing procedures using the secure resource and storing a secure program including at least a calling instruction for calling the normal program;
A determination means for determining whether or not an instruction to be executed next in the secure mode is the call instruction;
An output means for outputting identification information indicating the normal program called by the call instruction when determined to be the call instruction in the secure mode;
Switching means for protecting the secure resource and switching from the secure mode to the normal mode when it is determined that the call instruction is provided;
Receiving means for receiving the identification information in a normal mode;
A reading means for reading out the normal program indicated by the received identification information from the normal storage means in the normal mode;
A data processing apparatus comprising: processing means that operates in accordance with the read normal program in the normal mode. The switching unit switches from a secure mode to a normal mode by interrupting a secure operating system that controls the secure program and starting a normal operating system that controls the normal program. Data processing equipment. The data processing apparatus includes a shared storage area to which access is permitted in both the secure mode and the normal mode,
The output means outputs the identification information in the secure mode by writing the identification information to the shared storage area.
The data processing apparatus according to claim 2, wherein the receiving unit receives the identification information by reading the identification information from the shared storage area in a normal mode. The reading means stores the identification information and position information indicating the position of the normal program in the normal storage means in association with each other, and from the position indicated by the position information corresponding to the received identification information. The data processing apparatus according to claim 3, wherein the normal program is read out. One processing procedure constituting the normal program includes a plurality of functions constituting a library, and the other processing procedure calls one of the plurality of functions,
The data processing apparatus according to claim 3, wherein when the processing unit operates according to the other processing procedure, the processing unit operates according to a function called by the other processing procedure. The data processing device further includes:
In secure mode, instruction acquisition means for receiving a write instruction indicating writing to the secure storage means of the secure program;
A secure load means for writing the secure program to the secure storage means and outputting write end information indicating that the writing is completed when the write instruction is acquired in a secure mode;
The switching means further switches from the secure mode to the normal mode when the writing end information is output,
3. The data processing apparatus according to claim 2, further comprising normal load means for receiving the write end information and writing the normal program in the normal storage means in the normal mode. . In the normal mode, the reading means further includes position information indicating the identification information and the location of the normal program in the normal storage means when the normal program is written into the normal storage means by the normal load means. The data processing apparatus according to claim 6, which is stored in association with each other. The data processing device further includes:
In the secure mode, a deletion instruction acquisition means for acquiring a deletion instruction for instructing deletion of the secure program;
A secure deletion unit that deletes the secure program from the secure storage unit and outputs deletion end information indicating that the deletion is completed in the secure mode when the deletion instruction is acquired;
The switching means further switches from the secure mode to the normal mode when the deletion end information is output,
The data processing device further includes:
The data processing apparatus according to claim 6, further comprising: a normal deletion unit that acquires the deletion end information and deletes the normal program from the normal storage unit in a normal mode. The reading means stores the identification information and position information indicating the position of the normal program in the normal storage means in association with each other, and from the position indicated by the position information corresponding to the received identification information. The data processing apparatus according to claim 2, wherein the normal program is read out. The data processing device further includes:
Boot program storage means for storing a boot program including an initialization procedure for initializing one or more devices included in the data processing apparatus including the processing means and a startup procedure for starting the secure operating system;
And an initialization unit configured to initialize the device in accordance with the boot program read out from the boot program storage unit and start a secure operating system after the initialization is completed. Item 3. A data processing apparatus according to Item 2. The data processing device further includes:
In normal mode, including normal output means for outputting a processing result by the processing means and secure identification information indicating the secure program,
The switching means further switches from the normal mode to the secure mode when the processing result is output,
The data processing device further includes:
Secure reception means for receiving the processing result and the secure identification information in secure mode;
A secure reading means for reading out the secure program corresponding to the received secure identification information from the normal storage means,
The data processing apparatus according to claim 2, wherein the processing unit further operates according to the secure program using the processing result in the secure mode. The data processing apparatus according to claim 2, wherein the switching unit disconnects the secure resource and the processing unit when switching from the secure mode to the normal mode. The data processing apparatus according to claim 2, wherein the switching unit encrypts secure information held in the secure resource when switching from the secure mode to the normal mode. The secure information held in the secure resource is executed in a secure mode, and includes a program composed of an instruction code part, a data part, and a stack part,
The data processing apparatus according to claim 13, wherein the switching means encrypts the instruction code portion when switching from the secure mode to the normal mode. The secure information held in the secure resource is executed in a secure mode, and includes a program composed of an instruction code part, a data part, and a stack part,
The data processing apparatus according to claim 13, wherein the switching means encrypts the data portion when switching from the secure mode to the normal mode. The secure information held in the secure resource is executed in a secure mode, and includes a program composed of an instruction code part, a data part, and a stack part,
The data processing apparatus according to claim 13, wherein the switching unit encrypts the stack part when switching from the secure mode to the normal mode. The data processing device further includes a debug receiving unit that receives a debug operation signal from a debug device that monitors and operates the operation of the processing unit,
The switching unit connects the processing unit and the debug receiving unit when switching from the secure mode to the normal mode, and disconnects the processing unit and the debug receiving unit when switching from the normal mode to the secure mode. The data processing apparatus according to claim 2. The reading means stores the identification information and position information indicating the position of the normal program in the normal storage means in association with each other, and from the position indicated by the position information corresponding to the received identification information. The data processing apparatus according to claim 1, wherein the normal program is read out. The data processing device that switches between a first operating system and a second operating system, and that transitions a process generated in each operating system to an execution state, an execution waiting state, or a hibernation state to execute and manage the process. And
First generation means for generating a first process in the first operating system;
In the second operating system, second generation means for generating a second process corresponding to the first process;
First detection means for detecting a state transition of the first process in the first operating system;
A first output means for outputting transition information indicating the detected state transition in the first operating system;
OS switching means for switching the first operating system to the second operating system;
In the second operating system, second acquisition means for acquiring the transition information;
The data processing apparatus according to claim 1, further comprising: a second transition unit that transitions the state of the second process according to the acquired transition information. The data processing device further includes:
In the second operating system, second detection means for detecting a state transition of the second process;
A second output means for outputting transition information indicating the detected state transition in the second operating system;
The OS switching means further switches the second operating system to the first operating system,
The data processing device further includes:
In the first operating system, first acquisition means for acquiring the transition information;
20. The data processing apparatus according to claim 19, further comprising first transition means for transitioning the state of the first process according to the acquired transition information. The data processing apparatus includes a shared storage area accessible in both the first operating system and the second operating system,
The first output means outputs the transition information by writing the transition information in the shared storage area,
The data processing apparatus according to claim 20, wherein the second acquisition unit acquires the transition information by reading the transition information from the shared storage area. The second output means outputs the transition information by writing the transition information in the shared storage area,
The data processing apparatus according to claim 21, wherein the first acquisition unit acquires the transition information by reading the transition information from the shared storage area. The data processing device includes a device managed and operated in the second operating system,
The second process is a device driving program for controlling driving of the device;
The data processing apparatus according to claim 22, wherein the second detection unit detects a state transition of the second process accompanying an operation of the device. In the first operating system, when the first process transitions from a sleep state to an execution state,
The data processing apparatus operates according to the first process for performing exclusive processing to avoid duplication of processing requests to the device,
24. The data processing apparatus according to claim 23, wherein in the first operating system, the first output means outputs the transition information after the exclusion process is completed. The data processing device further includes:
Interrupt detection means for detecting occurrence of an interrupt in the first operating system and the second operating system;
In the first operating system, when an interrupt is detected, an interrupt investigation means for investigating an interrupt occurrence factor;
The first operating system includes interrupt transition means for transitioning the first process from a sleep state to an execution state when the interrupt investigation means determines that the interrupt is caused by the device. The data processing apparatus according to claim 23. The data processing device further includes:
A notification means for outputting interrupt notification information indicating detection of an interrupt when an interrupt is detected in the second operating system;
The OS switching means switches the second operating system to the first operating system;
The first acquisition means further acquires the interrupt notification information in the first operating system,
The data processing apparatus according to claim 25, wherein the interrupt investigation unit further investigates an interrupt occurrence factor when the interrupt notification information is acquired in the first operating system. The notification means, when an interrupt is detected, causes the interrupt detection means to stop detecting an interrupt,
27. The data processing apparatus according to claim 26, wherein the first acquisition unit cancels the stop with respect to the interrupt detection unit when the interrupt notification information is acquired. The data processing device that operates according to a program,
Storage means for storing a program comprising a plurality of processing procedures;
Correctness determination means for determining whether or not the program stored in the storage means is illegal;
The data processing apparatus according to claim 1, further comprising: an invalidating unit that invalidates the program when it is determined to be illegal. The validity judgment means includes
A program information acquisition unit for acquiring program identification information indicating the program stored in the storage unit;
A revocation information acquisition unit that acquires revocation identification information indicating a revoked program;
A determination unit that determines whether the acquired program identification information and the acquired invalidation identification information match,
29. The data processing apparatus according to claim 28, wherein when it is determined that they match, the program is determined to be invalid. The program information acquisition unit
An identification information storage unit storing program identification information indicating the program;
A reading unit that is obtained by reading the program identification information from the identification information storage unit,
The invalidation information acquisition unit
A revocation information storage unit that stores revocation identification information indicating a revoked program;
30. The data processing apparatus according to claim 29, further comprising: a reading unit that is acquired by reading the invalidation identification information from the invalidation information storage unit. The legitimacy judging means judges whether or not the program is illegal based on a public key certificate proving the legitimacy of a public key assigned to the program. 28. A data processing apparatus according to 28. The validity judgment means includes
A certificate storage unit storing the public key certificate including public key identification information for identifying the public key;
A public key information acquisition unit for acquiring the public key identification information from the public key certificate;
A revocation information storage unit that stores revocation identification information indicating a revoked public key;
An invalidation information reading unit for reading invalidation identification information from the invalidation information storage unit;
A determination unit that determines whether or not the acquired public key identification information and the read invalidation identification information match,
The data processing apparatus according to claim 31, wherein when it is determined that they match, the program is determined to be invalid. The legitimacy judging means further includes:
The data processing apparatus according to claim 32, further comprising: an update unit that acquires the latest invalidation identification information from outside and writes the acquired invalidation identification information in the invalidation information storage unit. The data processing apparatus according to claim 33, wherein the update unit acquires the latest invalidation identification information each time an access request to the storage unit is detected. The updating unit receives the invalidation identification information from a CRL (Certificate Revocation List) issuing device via a network, and receives the invalidation identification information from the CRL issuing device via a network and a server device. The data processing apparatus according to claim 33, wherein the data processing apparatus is obtained by reading the invalidation identification information from a recording medium. The update unit further obtains signature data generated by applying a digital signature to the latest invalidation identification information from the outside, performs signature verification on the acquired signature data, and the signature verification is successful The data processing apparatus according to claim 33, wherein the acquired invalidation identification information is written into the invalidation information storage unit. The validity judgment means includes
A certificate storage unit storing at least the public key certificate including signature data generated by applying a digital signature to the public key;
A public key certificate acquisition unit for acquiring the public key certificate from the certificate storage unit;
A verification unit that verifies whether the acquired public key certificate is correct by performing signature verification on the signature data included in the acquired public key certificate,
The data processing apparatus according to claim 31, wherein if it is determined that the public key certificate is not correct, the program is determined to be invalid. Whether the program stored in the storage means is illegal by using the at least two public key certificates respectively certifying the validity of at least two public keys. The data processing apparatus according to claim 28, wherein: The two public keys are a first public key assigned to the program and a second public key assigned to an operating system that controls the operation of the data processing device or the program,
The validity judgment means includes
A second public key certificate including a second signature data generated by applying a digital signature to at least the second public key using a private key of an authoritative certification authority, and the second public key; ,
A first signature data generated by applying a digital signature to at least the first public key using a secret key of the data processing apparatus or the operating system; and a first public key including the first public key. A certificate storage unit storing a public key certificate;
A public key certificate acquisition unit for acquiring the first public key certificate and the second public key certificate from the certificate storage unit;
Whether the obtained second public key certificate is correct by performing signature verification on the second signature data included in the obtained second public key certificate using the public key of the certification authority. Whether or not
If it is determined to be correct, obtain the second public key from the second public key certificate;
The obtained first public key certificate is correct by performing signature verification on the first signature data included in the obtained first public key certificate using the obtained second public key. And a verification unit for verifying whether or not
The program is determined to be invalid when it is determined that the second public key certificate is not correct and when it is determined that the first public key certificate is not correct. 39. A data processing apparatus according to item 38. The data processing apparatus according to claim 28, wherein the validity judgment unit makes the judgment each time an access request to the storage unit is detected. 41. The data processing apparatus according to claim 40, wherein the validity determination unit makes the determination each time an access request to a program stored in the storage unit is detected. The data processing apparatus according to claim 28, wherein the validity judgment unit makes the judgment immediately after power supply to the data processing apparatus is started. A data processing apparatus for decrypting and executing an encrypted program,
The storage means stores an encrypted program generated by applying an encryption algorithm to the program using a program key instead of the program,
The validity judgment means includes
an encryption key storage unit storing m encryption keys selected from the p encryption keys;
Using each of the m encryption keys, m encryption information generated by encrypting either the program key or the predetermined detection information is stored in association with the m encryption keys. An encrypted information storage unit,
Using each of the m encryption keys, a decryption unit that applies a decryption algorithm to the corresponding encryption information to generate m decryption information;
A determination unit that determines whether all of the m pieces of decrypted information generated are the detection information;
The data processing apparatus according to claim 28, wherein when all of the generated m pieces of decoding information are determined to be the detection information, the program is determined to be invalid. The p encryption keys are arranged at each element position of the first matrix of n rows and m columns (p = n × m), and one encryption key is selected from each column of the first matrix. Thus, m encryption keys are selected from the first matrix,
The encryption key storage unit stores the element position where each encryption key is arranged in the first matrix in association with each encryption key,
The encryption information storage unit stores the encryption information at the same element position as the element position where the encryption key corresponding to each encryption information is arranged in the second matrix of n rows and m columns,
The decryption unit reads the element position corresponding to the encryption key from the encryption key storage unit, and the encrypted information arranged in the same element position as the read element position in the second matrix of the encryption information storage unit 44. The data processing apparatus according to claim 43, wherein a decryption algorithm is applied to the read encrypted information using the read encryption key. The data processing device,
Memory means for storing data;
A processor that operates according to a program composed of a plurality of processing procedures;
It is arranged between the memory means and the processor, and determines whether or not the transfer data addressed to the memory means output from the processor satisfies a transfer restriction condition, and determines that the transfer restriction condition is satisfied. And a monitoring unit that suppresses transfer of transfer data to the memory unit and transfers transfer data to the memory unit when it is determined that the transfer restriction condition is not satisfied. The data processing apparatus according to claim 1. The monitoring unit stores a transfer restriction condition for each of a plurality of application programs, selects a transfer restriction condition for each application program executed by the processor, and uses the selected transfer restriction condition. The data processing apparatus according to claim 45. The transfer restriction condition is address range information indicating a predetermined storage space in the memory means,
The said monitoring means extracts address information from the said transfer data, and when the extracted address information is contained in the said address range information, it suppresses transfer of the said transfer data. Data processing device. The transfer restriction condition is a limit number indicating an upper limit of the number of accesses to a predetermined storage space in the memory means,
The monitoring unit stores the cumulative number of accesses to the storage space in the past, extracts address information from the transfer data, and the accumulated address information is included when the extracted address information is included in the address range information. 47. The data processing device according to claim 46, wherein when the number of times after addition obtained by adding 1 to the number of times exceeds the limit number of times, transfer of the transfer data is suppressed. The data processing apparatus according to claim 46, wherein the monitoring unit determines whether or not the transfer data transferred on a bus connected to the processor satisfies a transfer restriction condition. The memory means stores an encryption code and encrypted data generated by encrypting a code part and a data part of an application program different from the current program being executed by the processor, using an encryption key. And
The transfer restriction condition is address range information indicating a storage space in which the encrypted data is stored in the memory means,
The monitoring means stores a decryption key for decrypting the encryption code and encrypted data, extracts address information from the transfer data, and the extracted address information stores the encryption code. A decryption code is generated by using the decryption key to decrypt an encrypted code existing in the storage space indicated by the transfer data, and generating the decrypted code. 47. The data processing apparatus according to claim 46, wherein transfer of transfer data is suppressed when address information transferred and extracted to a processor is included in the address range information. The monitoring unit further adds identification information for identifying the program being executed by the processor to the program invalidation list when determining that the transfer restriction condition is satisfied. The data processing apparatus described. The data processing device,
Memory means for storing data;
A processor comprising a program counter that operates according to a program composed of a plurality of processing procedures and stores the address of an instruction to be executed next;
It is determined whether or not an address stored in the program counter is included in a predetermined address range, and when it is determined that the address is included in a predetermined address range, a predetermined value is stored in the program counter for the processor. Monitoring means for instructing to store the value of
The data processing apparatus according to claim 1, wherein the processor stores the predetermined value in a program counter when the instruction is received. This is a data processing method used in a data processing apparatus that executes a program by switching between a secure mode in which use of a secure resource to be protected is permitted and a normal mode in which only use of a normal resource that is not protected is permitted. And
The data processing apparatus includes a normal storage unit that stores a normal program including one or more processing procedures that use the normal resource, and one or more processing procedures that use the secure resource, Secure storage means storing a secure program including at least a calling instruction for calling the normal program,
The data processing method includes:
A determination step of determining whether an instruction to be executed next in the secure mode is the call instruction;
An output step of outputting identification information indicating the normal program called by the call instruction when the call instruction is determined in the secure mode;
A switching step of switching from the secure mode to the normal mode when protecting the secure resource when determined to be the call instruction;
A receiving step for receiving the identification information in a normal mode;
In a normal mode, a reading step of reading out the normal program indicated by the received identification information from the normal storage means;
And a processing step that operates according to the read normal program in the normal mode. In the data processing method, the first operating system and the second operating system are switched, and a process generated in each operating system is changed to one of an execution state, an execution waiting state, and a dormant state to execute and manage the process. And
A first generation step of generating a first process in the first operating system;
A second generation step of generating a second process corresponding to the first process in the second operating system;
A first detection step of detecting a state transition of the first process in the first operating system;
A first output step for outputting transition information indicating the detected state transition in the first operating system;
An OS switching step of switching the first operating system to the second operating system;
A second acquisition step of acquiring the transition information in the second operating system;
54. The data processing method according to claim 53, further comprising: a second transition step for transitioning the state of the second process according to the acquired transition information. The data processing method used in the data processing apparatus that operates according to a program,
The data processing apparatus includes a storage unit that stores a program including a plurality of processing procedures.
A legitimacy determining step of determining whether or not the program stored in the storage means is illegal;
54. The data processing method according to claim 53, further comprising: an invalidating step of invalidating the program when it is determined to be illegal. A data processing method used in the data processing apparatus,
The data processing device comprises a memory means for storing data and a processor that operates according to a program comprising a plurality of processing procedures,
The data processing method includes:
When determining whether or not the transfer data addressed to the memory means output from the processor satisfies a transfer restriction condition between the memory means and the processor, and determines that the transfer restriction condition is satisfied 54. The method further comprises a monitoring step of transferring transfer data to the memory means when it is judged that transfer data transfer to the memory means is suppressed and a transfer restriction condition is not satisfied. The data processing method described in 1. A data processing program used in a data processing apparatus that executes a program by switching between a secure mode in which use of a secure resource to be protected is permitted and a normal mode in which only use of a normal resource that is not protected is permitted. And
The data processing apparatus includes a normal storage unit that stores a normal program including one or more processing procedures that use the normal resource, and one or more processing procedures that use the secure resource, Secure storage means storing a secure program including at least a calling instruction for calling the normal program,
The data processing program is
A determination step of determining whether an instruction to be executed next in the secure mode is the call instruction;
An output step of outputting identification information indicating the normal program called by the call instruction when the call instruction is determined in the secure mode;
A switching step of switching from the secure mode to the normal mode when protecting the secure resource when determined to be the call instruction;
A receiving step for receiving the identification information in a normal mode;
In a normal mode, a reading step of reading out the normal program indicated by the received identification information from the normal storage means;
And a processing step that operates in accordance with the read normal program in the normal mode. The data processing program for switching between a first operating system and a second operating system, and executing and managing a process by changing a process generated in each operating system to one of an execution state, an execution wait state, and a hibernation state. And
A first generation step of generating a first process in the first operating system;
A second generation step of generating a second process corresponding to the first process in the second operating system;
A first detection step of detecting a state transition of the first process in the first operating system;
A first output step for outputting transition information indicating the detected state transition in the first operating system;
An OS switching step of switching the first operating system to the second operating system;
A second acquisition step of acquiring the transition information in the second operating system;
58. The data processing program according to claim 57, further comprising: a second transition step for transitioning the state of the second process according to the acquired transition information. The data processing program used in the data processing apparatus that operates according to a program,
The data processing apparatus includes a storage unit that stores a program including a plurality of processing procedures.
A legitimacy determining step of determining whether or not the program stored in the storage means is illegal;
58. The data processing program according to claim 57, further comprising: an invalidation step of invalidating the program when it is determined to be illegal. A data processing program used in the data processing device,
The data processing device comprises a memory means for storing data and a processor that operates according to a program comprising a plurality of processing procedures,
The data processing program is
When it is determined whether transfer data addressed to the memory means output from the processor satisfies a transfer restriction condition between the memory means and the processor, and it is determined that the transfer restriction condition is satisfied 58. The method further comprises a monitoring step of suppressing transfer of transfer data to the memory means and transferring transfer data to the memory means when it is determined that a transfer restriction condition is not satisfied. The data processing program described in 1. The data processing program is
58. The data processing program according to claim 57, recorded on a computer-readable recording medium.

Images