JP4816975B2 - Application authentication system - Google Patents

Description

  The present invention relates to a technique for authenticating a terminal and an application operating on the terminal by an authentication module in a system having a terminal such as a mobile phone and an authentication module such as an IC card.

  2. Description of the Related Art Conventionally, in a system in which an IC card is attached to a terminal and performs business transactions with the server, an area having tamper resistance cannot be secured in the terminal, so an application program (hereinafter abbreviated as “application”) that operates in the server Directly came to authenticate the IC card. Therefore, the terminal only relays communication between the server and the IC card.

On the other hand, in recent years, an application can be downloaded from a server to a mobile phone or the like and can be operated on a mobile terminal.
None

  However, since an application downloaded to a mobile phone or the like may perform an illegal operation, the operation of the downloaded application is strictly limited.

  For example, an application downloaded to a mobile phone has a large use restriction on local resources, such as being unable to write data to an IC card attached to the mobile phone and restricting (prohibiting) use of various interfaces.

  In addition, applications downloaded to mobile phones are related to individuals such as e-mail addresses recorded in phone books and address books held by mobile phones and IC cards, and mail contents stored in e-mail inboxes. There are restrictions so that information cannot be read or written. This is because the application is legitimate, and it cannot be verified whether it has the right to access information held inside a mobile phone, IC card, etc. It is.

  This is an extremely impeding factor for future application of portable tools (diversification) and application to E-Commas (EC).

  In order to eliminate such restriction, it is necessary to authenticate the downloaded application and confirm the identity of the application. For example, it is conceivable to perform authentication by downloading a signature attached by a third party to the application together with the application and presenting the signature and information necessary for verifying that the signature is correct on the IC card. However, after the mobile phone downloads the application and the signature, the information required for the mobile phone to determine that the signature is correct (for example, a digest generated by a hash function) is generated. There is a possibility that a dummy signature that is different from the signature attached to, and a digest that has been subjected to an operation that can be verified by the signature are presented to the IC card by the mobile phone. For this reason, the IC card cannot trust that the signature and the digest presented on the IC card are of the actually downloaded application, and the IC card cannot authenticate the downloaded application. There is a problem.

  In addition, since an application downloaded to a terminal such as a mobile phone (hereinafter abbreviated as “terminal application”) can access the IC card, information stored so as to be protected by the IC card can be read and written. Similarly, it is necessary for the IC card to perform processing for authentication of the terminal application that accesses the IC card and determine whether or not the access may be permitted.

  As a process for authenticating a terminal application that is accessed by a secure device such as an IC card, conventionally, the terminal device has secret information similar to that held by the secure device. The process of judging whether or not was performed. However, the terminal has neither an area nor a function for securely holding secret information such as a tamper-resistant area. For this reason, there is a possibility that such secret information may be leaked. With the conventional method, the possibility that the terminal application is using the leaked information cannot be excluded, and the secure device strictly controls the terminal application. Has the problem of being unable to authenticate.

  In order to solve this problem, in the present invention, a program written in a ROM of a terminal such as a mobile phone in a tamper-resistant area in an authentication module such as an IC card (hereinafter sometimes referred to as “library”). The authentication module authenticates a library written in a region (hereinafter abbreviated as “ROM”) such as a terminal ROM or TRM that cannot be easily rewritten.

  If the library authenticated in this way generates the information necessary for judging that the signature is correct together with the signature of the downloaded application and presents it to the IC card, it is presented to the IC card by the authenticated library. It is possible to trust that the signature and information belong to the application actually downloaded, and the IC card can authenticate the application downloaded to the terminal. As a result, it becomes possible for the authenticated application to write data to the IC card and so on, and it becomes possible to realize a more complicated operation than the operation of a commercial transaction using a conventional terminal.

  In addition, as described above, the application downloaded to the terminal is authenticated by the IC card, so that the downloaded application can be permitted to use the external interface of the terminal.

  Also, to implement the present invention, it is necessary to download the signature of the downloaded application. For this purpose, the signature of the application is not only downloaded separately from the application, but also can be stored in the definition file of the application so as to be compatible with existing data specifications. For this reason, it is not necessary to download the signature separately from the download of the application.

  As described above, according to the present invention, it is possible to prevent an undesirable application from being executed in the terminal by combining the authentication module and the terminal and authenticating the application operating in the terminal with the information of the authentication module. can do.

  In addition, since the TRM access library in the terminal is authenticated by the authentication module, the TRM access library can perform processing for application authentication. As a result, it is possible to execute an application with high security, and it is possible to operate a commercial transaction using a terminal. Further, the tamper resistant area only needs to be in the authentication module, and it is not necessary to mount the tamper resistant area on the terminal, so that the manufacturing cost of the terminal can be reduced.

  Further, by authenticating the application operating in the terminal, the origin of the application is guaranteed, and access to the local resources of the terminal and the authentication module can be permitted to the application.

  In addition, since the server can authenticate the terminal by authenticating the TRM part of the authentication module and the application operating in the terminal can be authenticated, the application that operates highly confidential information in the terminal It is possible to exchange with the server, and a complicated business transaction operation can be realized between the server, the terminal, and the authentication module.

Also, by storing the signature of the application body in the optional area, it is possible to download the signature of the application body simultaneously with downloading of the application, and it is possible to save the trouble of downloading the signature of the application body.

  In addition, in a state where three or more devices are connected in series, authentication is sequentially performed from the device at one end, and the application stored in the device at the other end can be authenticated.

  The present invention relates to an application authentication system including a terminal and an authentication module. However, the “terminal” may be a portable electronic device represented by a mobile phone. Moreover, it may be something that cannot be practically carried, such as a personal computer or a public terminal installed on a street corner, and is an electronic device to which an authentication module described below can be attached, and operates an application internally. Is possible. As will be described below, the terminal has various units therein, but by providing the terminal with a ROM, a RAM, and a CPU, such a unit can be realized by software.

  The “authentication module” has an internal storage area, and includes an (SD) memory card, IC card, and smart card. When data is input from a mounted terminal, an operation is performed to return a response to the data. . In addition, the authentication module has a tamper-resistant area, which is an area that prevents unauthorized reading and unauthorized rewriting of information stored therein. Some of the units in the authentication module described below can also be realized by a card application that operates in such an IC card.

  Usually, an authentication module is mounted on a terminal, an electric circuit is formed between the terminal and the authentication module, and information is exchanged. However, there is also a form in which the main body of the terminal and the part where the authentication module is mounted are separated and information is exchanged by communication.

  The application running on the terminal performs at least one of arithmetic operations, use of the local interface, access to the server, access to the tamper resistant area, and access to the external memory. The “local interface” is an external interface of the terminal, and examples thereof include IrDA (interface for infrared communication), Bluetooth, other wireless communication, and an interface for wired communication.

  In the above, it was written that the terminal and the authentication module are easily separable, but the authentication module is provided inside the terminal by being crimped or soldered to the terminal circuit. And may not be easily separated.

  In the above description, the term “terminal” is used. However, the present invention is not limited to a portable device, and can be implemented using a personal computer, a workstation, or the like instead of using a terminal.

  The present invention can also be applied to processing for authenticating an application stored in a device at the other end from a device at the other end in a state where a plurality of devices are connected in series.

  (Embodiment 1)

  FIG. 1 is a functional block diagram of an application authentication system according to Embodiment 1 of the present invention. The application authentication system in the present embodiment includes a terminal 100 and an authentication module 101.

  The terminal 100 includes a download unit 102 that downloads an application. “Downloading an application” means reading data for executing an application from outside the download unit 102. Here, the “data for executing the application” is binary data if the application is binary data that can be directly executed by the terminal 100, and is described in a language in which the application is interpreted and executed by the terminal 100. If so, that is the description. The download unit reads data for executing the application and holds the data.

  The authentication module 101 has a TRM unit 103. The TRM unit 103 holds information for application authentication processing in a tamper resistant area. Note that “TRM” is an abbreviation for “Tamper Resistant Module”. The “application” is an application downloaded to the download unit 102 of the terminal 100, and the “application authentication” is a guarantee that the application is issued by a trusted person and does not perform an illegal operation. Whether the application has been received, whether it has been tampered with after it has been issued by a trusted person, or has not been tampered with after it has been guaranteed that it will not behave improperly. It is to confirm that the operation is not illegal. The “application authentication process” is a process for such confirmation.

  As a method of this authentication processing, a hash function such as SHA-1 (Secure HashStandard-1) or MD5 (Message Digest 5) is usually used (in some cases, called “summary function” instead of “hash function”). Is used to obtain result data obtained by processing data for executing an application as input data and encrypting the result data (so-called “signature”). Here, the “hash function” is a function that returns a result that is difficult in terms of computational complexity to find two different input data that match the result data obtained by processing the input data. Therefore, “information for application authentication processing” is the signature itself or a decryption key necessary for decrypting the signature to obtain a hash value. The “tamper resistant area” is a storage area of the authentication module, and it is difficult to read data in the storage area illegally or rewrite data in the storage area. For example, in order to access the storage area, the storage area must pass through hardware that cannot be accessed unless the correct procedure is performed, or the data stored in the storage area is encrypted. It is realized as it is.

For application authentication, the terminal 100 obtains the hash value of the application downloaded to the download unit 102 and presents the signature together with the hash value to the authentication module. The authentication module 101 uses the information held in the TRM unit 103 to It is examined whether the signature can be generated from the hash value or whether the hash value matches the hash value obtained by decrypting the signature. Alternatively, the terminal 100 may present the application itself and the signature downloaded to the download unit to the authentication module, and perform authentication by examining the relationship between the application itself and the signature.

  Since the application downloaded to the download unit 102 can be authenticated by the information held in the TRM unit 103 of the authentication module 101 by the application authentication system having such a configuration, an unauthorized application is downloaded and the terminal 100 is downloaded. Can be prevented from being executed or stored in the authentication module 101.

  FIG. 2 shows an example of the application authentication system of this embodiment. In this example, the service providing company 200 distributes the authentication module 101 in a state where the application 201 is stored. When a person who has obtained the authentication module 101 attaches the authentication module 101 to the terminal 100, the application 201 is downloaded from the authentication module 101 to the download unit 102 of the terminal 100 (arrow 203). When the downloaded application 202 is authenticated by the information stored in the TRM section of the authentication module 101, the application 202 operates in the terminal 100 and receives a service provided from the service providing company 200 (arrow 204). ).

  FIG. 3 shows another example of the application authentication system of the present embodiment. In this example, the service providing company 200 downloads the application 302 to the download unit 102 of the terminal 100 (arrow 303). When the application 302 is authenticated by the information held in the TRM section of the authentication module 101 and it is confirmed that the application 302 is not an unauthorized application, the application 302 is stored in the authentication module 101 as the application 301 (arrow 304). Thereafter, the application 301 is downloaded to the download unit 102 of the terminal 100 and executed in the terminal 100 as necessary.

  In FIG. 2 and FIG. 3, the application executed in the terminal 100 is downloaded from the authentication module, but authentication is performed by information downloaded from the server connected to the terminal and held in the TRM section of the authentication module. If it is confirmed that the application is not an unauthorized application, an example in which the application is executed in the terminal can be given.

  Note that the term “terminal” is used, but this does not mean that the terminal is limited to a portable terminal represented by a mobile phone. For example, it may be a household electrical appliance, or a so-called information home appliance or internet home appliance. Examples of such products include air conditioners, humidifiers, dehumidifiers, air purifiers, microwave ovens, refrigerators, dishwashers, water heaters, irons, trouser presses, vacuum cleaners, washing machines, and dryers. Machines, electric blankets, electric mattresses, lighting equipment, television receivers, radio receivers, tape recorders and other audio equipment, cameras, IC recorders, telephones, facsimile transceivers, copiers, printers, scanners, personal computers, etc. be able to.

  (Embodiment 2)

  FIG. 4 is a functional block diagram of the application authentication system according to the second embodiment of the present invention. The application authentication system includes a terminal 100 and an authentication module 101. The terminal 100 includes a download unit 102 and a TRM access library unit 401. The authentication module 101 includes a TRM unit 103 and a TRM access library unit authentication unit 402.

  The download unit 102 downloads an application.

  The TRM access library unit 401 performs processing for application authentication on the condition that the authentication module 101 authenticates itself. That is, the TRM access library unit 401 first causes the authentication module 101 to authenticate itself, and performs processing for application authentication when it is correctly authenticated.

  As a method for allowing the TRM access library unit 401 to authenticate itself to the authentication module 101, information unique to the terminal 100 is output to the authentication module 101, and the authentication module 101 stores information in which the output information is stored in a tamper resistant area. There is a method of performing authentication depending on whether or not it is compatible. The “information unique to the terminal 100” includes the telephone number when the terminal is a mobile phone. Another type of information unique to the terminal 100 is an identifier that is different for each terminal, such as an identifier that identifies the type of the terminal 100 and a manufacturing number that is assigned to the terminal 100. Also good. In addition, there is a method for authenticating the TRM access library unit 401 using information related to a combination of applications installed in the terminal 100. The “application installed in the terminal 100” means an application provided in the terminal 100, and is an application downloaded from the outside of the terminal or an application stored in the ROM of the terminal. In this case, the TRM access library unit 401 outputs information indicating which application is installed in the terminal 100 (for example, an identifier of the installed application) to the authentication module 101, and the authentication module 101 outputs the information Authentication is performed based on whether the received information matches the information stored in the tamper resistant area. Alternatively, authentication is performed based on whether or not unauthorized terminal information is stored in the tamper-resistant area and does not conform to the unauthorized terminal information.

  As mentioned above, for example, it is assumed that a new service C is provided to a member who is a member for receiving provision of both services A and B. In this case, the authentication module 101 authenticates the TRM access library unit 401 on the condition that the application A for receiving the provision of the service A and the application B for receiving the provision of the service B are installed in the terminal 100. By doing so, it becomes possible to provide the application C for receiving the provision of the service C to the members of the service A and the service B installed in the terminal.

  There is also a method for authenticating the TRM access library unit 401 using information for identifying the TRM access library unit 401. “Information for identifying the TRM access library unit 401” is, for example, information for identifying software constituting the TRM access library unit 401, and includes the name, version number, serial number, and the like of the software. The TRM access library unit 401 outputs information for identifying the TRM access library unit 401 to the authentication module, and the authentication module 101 determines whether or not the output information matches the information stored in the tamper resistant area. Authenticate.

  The “process for application authentication” is a process for authentication of an application downloaded to the download unit 102. The TRM access library unit 401 may perform part of processing related to application authentication. Further, since the TRM access library unit 401 is authenticated by the authentication module, all of the processes related to application authentication may be performed.

  Further, the processing performed by the TRM access library unit 401 need not be limited to processing for application authentication. For example, as shown in FIG. 36, the TRM access library unit 401 may further include an application manager and a device driver therein, and perform these processes.

  The “application manager” provides a function for controlling the operation of the application, such as starting, ending, and suspending the application downloaded to the download unit 102. As another name of the application manager, for example, “application control program” can be cited.

  The “device driver” is a program that manages input / output with the authentication module. For example, it is a program for absorbing the operation specifications for different input / output for each authentication module and allowing the application to perform input / output by operating the same interface. As another name of the device driver, “authentication module access program” can be cited.

  The TRM unit 103 holds the TRM access library unit authentication information in the tamper resistant area. “TRM access library unit authentication information” is information for authenticating the TRM access library unit 401. As already described, this information is information specific to the terminal 100 such as a mobile phone number, information related to a combination of applications installed in the terminal 100, or identifies the TRM access library unit 401. In some cases, the information is for information. Since the TRM access library unit authentication information is held in the tamper resistant area, the mobile phone number, the information for identifying the application installed in the terminal 100, and the information for identifying the TRM access library unit 401 are encrypted. In some cases.

  The TRM access library unit authentication unit 402 authenticates the TRM access library unit 401 of the terminal based on the TRM access library unit authentication information. That is, the TRM access library unit 401 is authenticated by the authentication information output from the TRM access library unit 401 to the authentication module and the TRM access library unit authentication information held in the TRM unit 103.

  FIG. 5 is a diagram for explaining a method for authenticating an application in the application authentication system according to the present embodiment. The difference between the application authentication systems shown in FIG. 4 and FIG. 5 is that the download unit 102 of the terminal 100 in FIG. 5 downloads an application to which a signature, which is information used for authenticating that there is no falsification. The point is that the terminal 100 further includes a signature authentication information output unit 501, and the authentication module 101 further includes a signature authentication information input unit 502 and a signature authentication unit 503.

  “Signature, which is information used to authenticate that there has been no tampering” is information for confirming that the application has not been tampered with. FIG. 6 shows the relationship between the application and the signature. The signature 602 is obtained by encrypting a value obtained by applying the hash function such as SHA-1 or MD5 to the application main body 601 as data. In order to confirm that the application main body has not been tampered with using the signature 602, first, the signature is decrypted to obtain a hash value. Next, a hash function is applied to the application body, and it is confirmed whether or not the obtained value is the same as the hash value obtained by decrypting the signature. Alternatively, a hash function is applied to the application main body to obtain a hash value, encryption is performed on the hash value, and it is confirmed whether or not the obtained one is the same as the signature. The former method is a method that is normally used when, for example, a signature uses a public key encryption method. The signature is encrypted with the secret key of the person who performs the signature, and the application main body is falsified. When it is confirmed that it has not been decrypted, it is decrypted with the public key corresponding to the private key of the person who signed it. The latter method is used, for example, when a person who confirms that the application main body has not been tampered with knows the secret key of the person who signed it, or when a common key encryption method is used.

  In the present embodiment, the TRM access library unit 401 authenticates itself to the authentication module and then is a part of the process for authenticating the application downloaded to the download unit 102, that is, the download unit 102. A signature authentication digest is generated from the application downloaded in step (b). The “signature authentication digest” is a hash value by a hash function such as SHA-1 or MD5 mentioned above.

  The signature authentication information output unit 501 outputs the signature authentication information 506 including the signature authentication digest 504 and the signature 505 generated by the TRM access library unit 401 to the authentication module. Here, the “signature 505” is a signature added to the application downloaded to the download unit 102.

  The signature authentication information input unit 502 inputs the signature authentication information 506 output from the signature authentication information output unit 501.

  The signature authentication unit 503 verifies the signature based on the signature authentication digest and the signature input from the signature authentication information input unit 502. As a verification method, for example, when the signature is encrypted with a private key of the public key encryption method, the signature is decrypted with the public key corresponding to the secret key, the decryption result, the signature authentication digest, And authenticate whether they are equal. Alternatively, the common key is held in the tamper-resistant area, and the signature is decrypted with the common key and compared with the digest for signature authentication, or the private key is held in the tamper-resistant area and the private key is used. There is a method of encrypting a signature authentication digest and comparing it with a signature.

  FIG. 7 is a flowchart for explaining the operation of the terminal 100. As a premise for performing the processing of this flowchart, it is assumed that the TRM access library unit 401 is authenticated by the authentication module. In step S <b> 701, the application is downloaded to the download unit 102. In step S702, the TRM access library unit 401 generates a signature authentication digest from the downloaded application. In step S703, signature authentication information 506 including the signature authentication digest obtained in step S702 and the signature added to the downloaded application is output from the signature authentication information output unit 501 to the authentication module 101.

  FIG. 8 is a flowchart for explaining the operation of the signature authentication information input unit 502 and the signature authentication unit 503 of the authentication module 101. As a premise for performing the processing of this flowchart, it is assumed that the TRM access library unit 401 is authenticated by the authentication module. For this purpose, for example, the TRM access library unit authentication unit 402 sets the authentication result in the authentication module 101, and refers to the set authentication result when performing the processing of the flowchart of FIG. Thus, there is a method of performing the processing of the flowchart of FIG. 8 only when the TRM access library unit 401 is authenticated. In step S <b> 801, signature authentication information 506 is input by the signature authentication information input unit 502. In step S 802, signature verification is performed based on the signature authentication digest 504 and the signature 505. The method for verifying the signature is as described above.

  In the present embodiment, the TRM access library unit 401 generates a signature authentication digest of the application downloaded to the download unit 102 on the condition that the authentication module 101 has authenticated, and generates the generated signature signature. Since the authentication digest is input to the authentication module 101, the signature authentication digest is reliable, and the authentication module 101 can authenticate the application downloaded to the download unit 102.

  (Embodiment 3)

  FIG. 9 shows a functional block diagram of the authentication module 101 according to the third embodiment of the present invention. The present embodiment is a more specific version of the authentication method using the signature authentication information in the second embodiment. The authentication module 101 in the second embodiment includes a signature-derived digest generation information acquisition unit 901 and a signature-derived digest. And a generation unit 902.

  The signature-derived digest generation information acquisition unit 901 acquires signature-derived digest generation information for generating a signature-derived digest by using the signature input from the signature authentication information input unit 502. If the signature is an encrypted hash value of the application main body, the “signature-derived digest generation information” is a decryption key for decrypting the encrypted one. When the public key encryption method is used as the encryption, the public key corresponding to the secret key used for encrypting the hash value of the application main body becomes the signature-derived digest generation information. This public key may be held in the authentication module. Further, it may be acquired from an appropriate server via the terminal 100 or the like.

  The signature-derived digest generation unit 902 generates a signature-derived digest 905 using the signature 903 input from the signature authentication information input unit and the signature-derived digest generation information held in the signature-derived digest generation information acquisition unit. . That is, if the signature-derived digest generation information is a public key, the signature 903 is decrypted with the public key to generate a signature-derived digest 905 that is a hash value of the application main body.

  The signature authenticating unit 503 performs authentication based on the signature derived digest 905 generated by the signature derived digest generating unit 902 and the signature authentication digest 904 input from the signature authentication information input unit 502. That is, the signature-derived digest 905 and the signature authentication digest 904 are compared. If they are the same, the application downloaded to the download unit 102 is authenticated, and if they are different, the authentication is not performed.

  FIG. 10 is a flowchart for explaining operations of the signature authentication information input unit 502, the signature-derived digest generation information acquisition unit 901, the signature-derived digest generation unit 902, and the signature authentication unit 503 in the present embodiment. As a premise for performing the processing of this flowchart, it is assumed that the TRM access library unit 401 is authenticated by the authentication module 101. For this purpose, for example, the TRM access library unit authentication unit 402 sets the authentication result in the authentication module 101, and refers to the set authentication result when performing the processing of the flowchart of FIG. Thus, there is a method of performing the processing of the flowchart of FIG. 10 only when the TRM access library unit 401 is authenticated. In step S1001, the signature authentication information 506 is input by the signature authentication information input unit 502, and a signature 903 and a signature authentication digest 904 are obtained. In step S1002, the signature-derived digest generation information acquisition unit 901 acquires signature-derived digest generation information. In step S1003, the signature-derived digest generation unit 902 generates a signature-derived digest 905 from the signature 903 and the signature-derived digest generation information. In step S 1004, the signature authentication unit 503 performs authentication based on the signature-derived digest 905 and the signature authentication digest 904.

  (Embodiment 4)

  FIG. 11 shows a functional block diagram of the application authentication system according to Embodiment 4 of the present invention. In the present embodiment, the terminal of the application authentication system in the second or third embodiment further includes an authentication module authentication unit 1101.

  The authentication module authentication unit 1101 authenticates the authentication module 101. As an authentication method, there is the method shown in the flowchart shown in FIG. In using this method, it is assumed that a secret key of the public key encryption method and a public key corresponding to the secret key are generated for the authentication module, and that the authentication module stores the secret key. In step S1201, the authentication module authentication unit 1101 generates a random number. In step S1202, the random number generated in step S1201 is encrypted with the public key of the authentication module 101. In step S1203, the authentication module 101 is input with the random number encrypted in step S1202 and requested to be decrypted. In step S1204, the decryption result is received from the authentication module 101. In step S1205, it is determined whether the random number generated in step S1201 is equal to the decryption result received in step S1204. As another method, there is a method in which the authentication module authenticating unit 1101 inputs the generated random number to the authentication module 101 and requests to encrypt the random number with the secret key of the authentication module 101. The authentication module authentication unit 1101 obtains the result of the encryption, decrypts it with the public key of the authentication module 101, and determines whether it is equal to the random number input to the authentication module 101.

  As described above, since the terminal 100 includes the authentication module authentication unit 1101 for authenticating the authentication module 101, the terminal 100 can authenticate the authentication module 101, and an application operating in the terminal 100 has high confidentiality. When writing information (privacy information, E-commerce (EC) log, bank account balance, etc.) to the authentication module 101, it is possible to confirm whether the authentication module 101 is valid.

  (Embodiment 5)

  FIG. 13 shows a functional block diagram of the application authentication system according to Embodiment 5 of the present invention. In the present embodiment, the TRM access library unit 401 of the application authentication system in the fourth embodiment further includes an application use resource information holding unit 1301.

  The application use resource information holding unit 1301 holds application use resource information. “Application usage resource information” is information about resources that are permitted to be used for an authenticated application. The “authenticated application” is an application that has been downloaded to the download unit 102 and has been correctly authenticated after being processed for authentication by the TRM access library unit 401. A “resource” is a resource external to the application used by the application. The resources include local resources that are resources of the terminal 100 and the authentication module 101 attached thereto, and other resources, for example, resources that are resources of a server that is a communication destination of the terminal 100. Local resources include types such as memory use, file use, IrDA use, Bluetooth use, communication use, TRM use, application use, and contactless / contact IC card I / F use. In addition, among the local resources, when the memory is used, there are those related to a range such as an amount of usable memory and a memory address. Moreover, the range of the time which can be used can also be mentioned.

  FIG. 14 illustrates the application use resource information. In FIG. 14, application usage resource information 1400 includes memory usage 1401, file usage 1402, IrDA usage 1403, Bluetooth usage 1404, communication usage 1405, TRM usage 1406, application usage 1407, contactless / contact. It consists of items such as use 1408, operation 1409, use date and time 1410 of the IC card I / F.

  The items of the memory use 1401 include, for example, the amount usable as the memory, the address of the usable range, the number of times of writing, the number of times of reading, the date and time when the memory can be used, and the date and time when it cannot be used. be able to. For flash memory, writing is a burdensome operation, so it is particularly meaningful to limit the number of times the memory is written.

  Examples of the file usage 1402 include items describing restrictions on access to files of the terminal 100 and files of an external memory connected to the terminal 100 such as the authentication module 101. For example, an accessible directory Name, accessible file name, accessible file type (specified by the file extension, for example), usable date and time, unusable date and time, and the like.

  IrDA use 1403 is an item indicating whether or not the use of the infrared communication function of the terminal 100 is permitted. Examples include the time when the function can be used / cannot be used, the total usable time, and the number of times of use. it can.

  The Bluetooth use 1404 is an item indicating whether or not the use of the Bluetooth communication function of the terminal 100 is permitted, and can be used in addition to the time when the function can be used, the total usable time, and the number of uses. The strength of radio waves, the number of roaming times, the date and time that can be used, etc. can be mentioned. By specifying usable radio wave intensity, a communicable distance can be specified.

  Use of communication 1405 is an item indicating whether or not use of a function of communication with a server or the like is permitted. The time when the function is usable / unusable, the total usable time, the number of times of use, In addition to strength and roaming times, you can list accessible servers. Whether an accessible server can be used by an application by specifying an address using an IP address, specifying a domain name, or specifying a server function such as a mail server or FTP server or a protocol for communication with the server Is specified.

  The TRM use 1406 is an item indicating whether or not access to the tamper-resistant area such as the authentication module 101 is permitted. The date and time when the tamper-resistant area can be accessed, the date and time when the access cannot be made, the number of accesses, and the tamper-resistant area. Card application that operates in an IC card having a card type, an accessible card application, types of usable IC card commands, and the like.

  Use application 1407 is an item for designating another application with which the application can cooperate. For example, an address book, mail, scheduler, game, etc. Moreover, the date and time when it can cooperate with other applications may be included. When the terminal 100 is a mobile phone, it may be specified whether or not the application is allowed to operate in parallel with the call at the time of telephone communication, and whether or not the application must be stopped or terminated at the start of the call. .

  The use 1408 of contact / non-contact IC card I / F is an item indicating whether or not use of an interface for communication with a contact / non-contact IC card or an IC card reader / writer capable of communication with the terminal 100 is permitted. The time when the interface can be used, the total usable time, the number of usable / unusable times, usable I / F (Type A, Type B, Type C, etc.), types of usable IC card commands, etc. Can be mentioned.

  The use date and time 1410 designates the date and time when the application can operate. Alternatively, the date and time when the operation of the application should be stopped is specified.

  When an application downloaded to the download unit 102 uses a resource, it issues a use request for the resource to the TRM access library unit 401, and the TRM access library unit 401 holds it in the application use resource information holding unit 1301. It is determined whether or not the requested resource is usable by referring to the requested application use resource information, and if the requested resource is available, the requested resource is used by the application.

  The application use resource information may be downloaded together with the application downloaded to the download unit 102 and held in the application use resource information holding unit 1301. FIG. 15 is a diagram schematically representing data in which application usage resource information is downloaded together with an application. First, there is application data 1501 which is an application main body, followed by application data signature data 1502 which is a signature for authenticating the application data 1501, followed by application usage resource information 1503, which authenticates the application usage resource information. There is application usage resource information signature data 1504. In the application usage resource information 1503, as indicated by the reference numeral 1505, “IrDA 1” indicates that IrDA can be used, and “Bluetooth 0” indicates that Bluetooth cannot be used. The

  Further, the application use resource information may be stored in the authentication module 101, read as necessary, and held by the application use resource information holding unit 1301.

  As described above, with the configuration in which the TRM access library unit 401 includes the application use resource information holding unit 1301, it is possible to limit resources that can be used by the downloaded application. Accordingly, it is possible to conduct a business in which application usage resource information is issued to an application producer, a service provider, and the like to obtain a price. The application resource information can be used for controlling the permission of the local resource, and the use of the local resource can be finely permitted / denied for a specific application. In the case of permitting local resources, if a usage fee is paid to the issuer of the application use resource information, the business transaction by issuing the application use resource information becomes possible. In addition, the user of the terminal 100 can obtain application usage resource information with less restrictions on the use of the application resources downloaded to the terminal 100 by paying a consideration. Can also be realized.

  In the second to fifth embodiments, the download unit 102 may download the license agreement. The “use license” is application use resource information with a signature of the download application. The “download application” is an application downloaded to the download unit 102. “Signed application resource information” is obtained by adding a signature of the application resource information to the application resource information. Since the application use resource information is a permit for the downloaded application to use the resources of the terminal 100 and the authentication module 101, it is important to guarantee the authenticity of the application use resource information, and a signature is added for this purpose. Append to application usage resource information.

  The verification of the signature of the downloaded application and the verification of the signature of the application use resource information may be performed simultaneously or at different times. For example, the signature of the application is first verified, and when the application is running and the resource is accessed, the signature of the application resource information is verified, confirming that it is authentic, and verifying the resource It may be determined whether access is permitted. The creator of the downloaded application signature and the application use resource information signature may be the same or different. The reason why the signature creator may be different is different from the creator of the application and the issuer of the application usage resource information. The former applies to the latter for permission to use the resource, and the application usage resource than the latter. This is because information may be issued. In addition, at the time of applying for permission to use resources, collection of consideration may be performed.

  In addition, if the application usage resource information in the license agreement includes expiration date information indicating the time limit during which the application can access the resource, the time limit allowed based on the expiration date information is displayed. If the information has already expired, the download unit 102 may download the license agreement and update the license agreement.

  The license agreement may be downloaded when the downloaded application is executed and / or when the application is authenticated. The license agreement may be downloaded from a server with which the terminal 100 can communicate. Alternatively, the authentication module 101 may be used.

  In addition, the download unit 102 may continue to hold the license agreement downloaded from the server. In this case, the license agreement may be updated in the server and held in the download unit 102. The license agreement may have expired. Therefore, the download unit 102 may inquire the server about the validity of the downloaded license when executing the downloaded application and / or authenticating the application.

  In addition, the download unit 102 causes the download unit 102 or another unit of the terminal 100 to inquire about the contents of the license agreement online with the server, and inquires whether the use of the application resource is permitted. It may be.

  (Embodiment 6)

  FIG. 16 shows a functional block diagram of the application authentication system according to Embodiment 6 of the present invention. In the present embodiment, the TRM access library unit 401 of the terminal 100 of the application authentication system of the fourth or fifth embodiment has application usage resource information output means 1601.

  The application use resource information output unit 1601 outputs application use resource information to the authentication module authenticated by the authentication module authentication unit 1101.

  In the present embodiment, the TRM unit 103 of the authentication module 101 holds the application usage resource information output from the application usage resource information output unit 1601 in a tamper-resistant area in a rewritable manner.

  In this way, the application usage resource information held in the tamper-resistant area is read into the terminal 100 as necessary, and whether the resource can be used when the application downloaded to the download unit 102 tries to use the resource. Referenced to determine if.

  As described above, the TRM access library unit 401 of the terminal 100 includes the application usage resource information output unit 1601, and the TRM unit 103 holds the application usage resource information output by the application usage resource information output unit 1601. Even after the application use resource information is provided in the state held in the module 101, the application use resource information can be rewritten as necessary. For example, the expiration date of the application use resource information can be rewritten. In addition, for example, when the service provider or the service user pays the price, the application use resource information held in the tamper-resistant area may be updated to one that does not limit the resources that can be used by the application. it can. Since rewriting is performed by the TRM access library unit 401 that has been authenticated by the signature authentication information input unit 502 in advance, unauthorized rewriting can be prevented.

  (Embodiment 7)

  FIG. 17 shows a functional block diagram of an application authentication system according to Embodiment 7 of the present invention. In the present embodiment, the terminal 100 of the application authentication system in the fifth or sixth embodiment has an application usage resource information download unit 1701.

  The application use resource information download unit 1701 downloads the application use resource information 1702 to which the signature 1703 is attached. This download may be downloaded together with the application downloaded to the download unit 102 as shown in FIG. Further, it may be downloaded separately from the application downloaded to the download unit 102. For example, an application may be downloaded in advance, and application use resource information may be downloaded when the application tries to access a resource.

  In the present embodiment, the TRM access library unit 401 may authenticate the signature 1703 attached to the application use resource information 1702 downloaded to the application use resource information download unit 1701. Since the TRM access library unit 401 is authenticated by the authentication module 101, the result of authenticating the signature 1703 of the application usage resource information 1702 by the correctly authenticated TRM access library unit 401 becomes reliable for the authentication module 101. Yes. Therefore, in accordance with the application use resource information 1702 thus authenticated, it is guaranteed that an illegal operation does not occur even if the downloaded application permits access to the authentication module 101.

  (Embodiment 8)

  FIG. 18 shows a functional block diagram of an application authentication system according to Embodiment 8 of the present invention. In this embodiment, the terminal 100 of the application authentication system in the fifth or sixth embodiment has an application use resource information download unit 1701 and an application use resource information signature authentication information output unit 1801, and the authentication module 101 An application use resource information signature authentication information input unit 1802 and an application use resource information signature authentication unit 1803 are provided. In the present embodiment, instead of authenticating the signature 1703 attached to the application use resource information 1702 in the seventh embodiment, the TRM access library unit 401 authenticates the signature 1703 by the authentication module.

  The application use resource information download unit 1701 downloads the application use resource information 1702 to which the signature 1703 is attached.

  In this embodiment, the TRM access library unit 401 generates a signature authentication digest from the application use resource information 1702 downloaded to the application use resource information download unit 1701, and the application use resource information signature authentication information output unit 1801 Signature authentication information 1806 including the generated signature authentication digest and signature 1703 is output to the authentication module.

  The application use resource information signature authentication information input unit 1802 inputs the signature authentication information 1806 output from the application use resource information signature authentication information output unit 1801. The signature authentication information 1806 includes a signature authentication digest 1804 generated by the TRM access library unit 401 and a signature 1805 that is a signature 1703 attached to the application use resource information 1702.

  The application use resource information signature authentication unit 1803 verifies the signature based on the signature authentication digest 1804 and the signature 1805 input from the application use resource information signature authentication information input unit 1802.

  FIG. 19 is a flowchart for explaining the operation of terminal 100 in the present embodiment. In step S1901, the TRM access library unit 401 generates a signature authentication digest 1804 from the application use resource information 1702. In step S1902, the signature authentication information 1806 including the signature authentication digest 1804 and the signature 1805 is output to the authentication module 101 by the application use resource information signature authentication information output unit 1801. In step S1903, an authentication result is received from the authentication module 101.

  FIG. 20 is a flowchart for explaining the operation of the authentication module 101 in the present embodiment. In step S2001, signature authentication information 1806 is input by the application use resource information signature authentication information input unit 1802. In step S2002, the application use resource information signature authentication unit 1803 verifies the signature of the signature 1805 based on the signature authentication digest 1804 and the signature 1805. In step S2003, the verification result is returned to the terminal 100.

  In such an embodiment, since the signature of the application use resource information 1702 is authenticated based on the signature authentication digest generated by the TRM access library unit 401 authenticated by the authentication module 101, the result of the authentication is Be reliable. In addition, since it is possible to authenticate the application using resource information signature authenticating unit 1803 based on whether or not it conforms to the signature stored in the TRM unit of the authentication module 101 without using encryption, authentication can be performed. It can be done with simple effort.

  (Embodiment 9)

  In the ninth embodiment of the present invention, an application in the authentication module that operates in the authentication module accepts access from an application that operates in the terminal on the condition that the TRM access library unit is authenticated by the authentication module. It is characterized by.

  FIG. 21 shows a functional block diagram of the application authentication system according to the present embodiment. In the present embodiment, the terminal 100 of the application authentication system in the second to third embodiments includes a terminal application holding unit 2101, and the authentication module 101 includes a TRM unit 103 including an in-authentication module application holding unit 2103. Have.

  The terminal application holding unit 2101 holds a terminal application 2102 that accesses the TRM unit of the authentication module 101. The “terminal application 2102” is an application executed inside the terminal 100. The application may be an application downloaded by the download unit 102 or may be an application held in the terminal ROM. “Hold” means that the terminal application 2102 can be executed. Accordingly, the terminal application holding unit 2101 is realized by a rewritable memory area of the terminal 100 that loads all or part of the terminal application 2102 in order to execute the terminal application 2102.

  The authentication module application storage unit 2103 stores the authentication module application 2104. The “in-authentication module application 2104” is an application that operates in the authentication module 101. If the authentication module 101 is an IC card, the in-authentication module application 2104 is a card application. “Hold” means that the authentication module application 2104 can be executed. Therefore, the in-authentication module application holding unit 2103 is realized by a rewritable memory area of the authentication module that loads all or part of the in-authentication module application 2104 in order to execute the in-authentication module application 2104.

  In this embodiment, the in-authentication module application 2104 operates by accepting an access from the terminal application 2102 on condition that the TRM access library unit authentication unit 402 authenticates the TRM access library unit 401. For this purpose, a value indicating whether or not the TRM access library unit 401 has been authenticated is stored in the authentication module, and as shown in FIG. 22, the value itself or such a value exists in step S2201. It is determined whether or not the authentication of the TRM access library unit 401 is successful. If the authentication is successful, the process proceeds to step S2202, and access from the terminal application 2102 is accepted. The determination in step S2201 may be performed by the in-authentication module application 2104 or by a non-authentication module application 2104. When the authentication module application 2104 is used, a determination is made by looking at a value indicating whether or not the TRM access library unit 401 has been authenticated between the activation of the authentication module application 2104 and the access of the terminal application 2102. Will do. When the determination in step S2201 is performed by a device other than the authentication module application 2104, a value indicating whether or not the TRM access library unit 401 has been authenticated is confirmed when the authentication module application 2104 is activated.

  When the authentication module 101 is an IC card, it is the card manager that activates the authentication module application 2104. Therefore, the TRM access library unit 401 determines whether the card manager activates the authentication module application 2104. Judgment is made by looking at a value indicating whether or not the user is authenticated. When the interface part (not shown in FIG. 21) of the authentication module 101 with the terminal determines whether to permit access from the terminal application 2102 to the authentication module application 2104, the TRM access library unit 401 authenticates. You may make it judge by seeing the value which shows whether it was done.

  Further, every time the in-authentication module application 2104 accepts access from the terminal application 2102, the value indicating whether or not the TRM access library unit 401 has been authenticated is seen to determine whether to accept the access and operate. It may be. FIG. 23 is a flowchart for explaining the operation of the application in the authentication module in such a case. In step S <b> 2301, access from the terminal application 2102 is accepted by the authentication module application 2104. In step S2302, the authentication module application 2104 checks a value indicating whether or not the TRM access library unit 401 has been authenticated, and determines whether or not the authentication of the TRM access library unit 401 has succeeded. If successful, in step S2303, the access from the terminal application 2102 is accepted to operate.

  FIG. 24 shows a form in which a value indicating whether or not the TRM access library unit 401 has been authenticated is stored in the TRM unit 103. The TRM unit 103 includes an authentication result identifier generation unit 2401. The authentication result identifier generation unit 2401 generates an authentication result identifier 2402 on the condition that the TRM access library unit authentication unit 402 has successfully authenticated the TRM access library unit 401. The in-authentication module application 2104 accepts access from the terminal application 2102 on condition that the authentication result identifier 2402 exists.

  Note that the authentication result identifier 2402 may not only indicate the authentication success of the TRM access library unit 401 by the TRM access library unit authentication unit 402 but may also have contents indicating the authentication failure. In this case, the authentication result identifier generation unit 2401 generates an authentication result identifier 2402 having contents according to the success / failure of the authentication of the TRM access library unit 401 by the TRM access library unit authentication unit 402. Further, the authentication module application 2104 looks at the contents of the authentication result identifier 2402 and determines whether or not the authentication is successful.

  FIG. 25 shows a method of realizing an authentication result identifier when the authentication module 101 is an IC card. In FIG. 25, the card application A (2501) authenticates the TRM access library unit 401. When the TRM access library unit 401 is authenticated, an authentication result identifier is stored in a rewritable memory area, for example, the RAM area 2503. Set. In FIG. 25, the flag mark schematically represents the authentication result identifier. The RAM area 2503 can be read and written by the card application A (2501). However, the RAM area 2503 is separated by a firewall function for starting each application independently so as not to adversely affect each application in the IC card. Card application B (2502) cannot directly access the RAM area 2503. Therefore, the card application A (2501) provides a public interface 2504 by using a public interface (Characteristic Interface) function that allows a user to designate a partner and publish the interface, and is accessed from the terminal application 2402 through the public interface 2504. The card application 2502 confirms whether the authentication result identifier exists in the RAM area 2503.

  FIG. 26 shows another method of realizing the authentication result identifier when the authentication module 101 is an IC card. The rectangles denoted by reference numerals 2601 and 2602 represent a dedicated file (DF). Each DF corresponds to each card application. For this reason, when DF is selected, the corresponding card application is activated. In the following, it is assumed that the DF denoted by reference numeral 2601 corresponds to the card application A, and similarly, the DF denoted by reference numeral 2602 corresponds to the application B. The rectangles to which reference numerals 2603, 2604, 2605, 2606, and 2607 are assigned represent elementary files (EF). When the card application corresponding to the DF is activated, the EF immediately below the DF corresponding to the card application can be operated. For example, when the DF 2601 is selected and the card application A is activated, the card application A can access the EFs 2603 and 2604.

  Hereinafter, it is assumed that when the card application A authenticates the TRM access library unit 401 and is correctly authenticated, an authentication result identifier is set in the EF denoted by reference numeral 2604. By including the state of the EF with the reference numeral 2604 in the security status of the DF with the reference numeral 2601, a DF selection corresponding to a descendant of the DF with the reference numeral 2601 in the tree structure formed by the DF and the EF Can be controlled. In other words, the selection of the DF with the reference numeral 2602 is set on the condition that any of the descendants of the DF with the reference numeral 2601, here, the identifier in the EF with the reference numeral 2604 exists. That is, since the selection of the DF corresponding to the card application B can be controlled based on the result of authentication of the TRM access library unit 401 by the card application A, the TRM access library unit 401 is authenticated for the card application B. Can only be activated if

  According to such an embodiment, unless the TRM access library unit 401 is authenticated by the authentication module 101, the in-authentication module application 2104 is not accessed from the terminal application 2102, so that the security of the authentication module 101 is maintained.

  Note that the in-authentication module application holding unit 2103 may be outside the TRM unit 103. In this case, the in-authentication module application 2104 checks whether the TRM access library unit 401 is authenticated by the TRM access library unit authentication unit 402 and operates by accepting the access of the terminal application 2102.

  (Embodiment 10)

  FIG. 27 is a functional block diagram of the application authentication system according to the tenth embodiment of the present invention. In the tenth embodiment of the present invention, the application in the authentication module operates by accepting access from the application on condition that the application operating on the terminal is authenticated. FIG. 27 shows a functional block diagram of the application authentication system in the present embodiment. In the application authentication system in the present embodiment, the TRM unit 103 of the application authentication system in the ninth embodiment has an application authentication result identifier generating unit 2701.

  The application authentication result identifier generation unit 2701 generates an application authentication result identifier 2702 on the condition that the application authentication by the TRM access library unit 401 is successful. Here, the “application” is an application downloaded to the download unit 102. “Authentication of an application by the TRM access library unit 401” means authentication performed based on a signature attached to the application and a signature authentication digest generated by the TRM access library unit 401.

  In the present embodiment, the intra-authentication module application 2104 enables the terminal application to access the intra-authentication module application 2104 on condition that an application authentication result identifier indicating successful authentication is present. Accept access from terminal applications.

  For example, when the terminal application 2102 is operating first and the application in the authentication module is not operating yet, the application authentication result identifier 2702 exists when the application in the authentication module is activated. Only in some cases, the authentication module application is launched. Alternatively, when both the terminal application 2102 and the in-authentication module application 2104 are activated, when the access from the terminal application 2102 to the in-authentication module application 2104 occurs, the application authentication result identifier 2702 exists. Only accept that access.

  If only one terminal application that accesses the authentication module application operates in the terminal 100, one type of application authentication result identifier 2702 is sufficient. However, if a plurality of such terminal applications operate in the terminal 100, an application authentication result identifier is generated by the application authentication result identifier generating unit 2701 for each terminal application to indicate which terminal application has been authenticated. Will be. Alternatively, when it is guaranteed that two or more terminal applications do not access the application in the authentication module at the same time, only one type of application authentication identifier is generated, and the authenticated terminal application is stored in the authentication module. The application authentication identifier may be generated only at the moment of accessing the application, and the application authentication identifier may be deleted when access of the application in the authentication module by the authenticated terminal application is completed.

  According to such an embodiment, only the authenticated terminal application can access the authentication module application, and the security of the authentication module 101 is ensured.

  (Embodiment 11)

  FIG. 28 shows a functional block diagram of an application authentication system according to Embodiment 11 of the present invention. The application authentication system in the present embodiment includes a terminal, an authentication module, and a server that downloads an application to the terminal.

  In FIG. 28, the terminal 2801 has a download unit 2804. The download unit 2804 is a unit for downloading an application. For example, an application is downloaded from the server 2803.

  The authentication module 2802 has a TRM unit 2805. The TRM unit 2805 holds information for application authentication processing in a tamper resistant area. Here, “application” means an application downloaded to the download unit 2804 of the terminal 2801. "Application authentication" means whether an application is issued by a trusted person, is guaranteed to not behave improperly, or is issued by a trusted person It is to confirm that the application does not perform an illegal operation, such as whether or not a tampering or an unauthorized operation has been guaranteed. As this processing method, an application such as SHA-1 or MD5, which uses a hash function that is difficult to find two different input data that match the result data obtained by processing the input data, is usually used. The result data obtained by processing the data for execution of the data as input data is obtained and encrypted (so-called “signature”). Therefore, “information for application authentication processing” is the signature itself or a decryption key necessary for decrypting the signature to obtain a hash value. The “tamper resistant area” is a storage area of the authentication module, and it is difficult to read data in the storage area illegally or rewrite data in the storage area. For example, in order to access the storage area, it is necessary to pass through hardware that cannot be accessed unless the correct procedure is performed, or the data stored in the storage area is encrypted. .

  The server 2803 has a terminal authentication unit 2806. The terminal authentication unit 2806 determines that the authentication of the terminal 2801 is successful on the condition that the authentication of the authentication module 2802 via the terminal 2801 is successful. That is, the server 2803 authenticates the authentication module 2802. At that time, the server 2803 and the authentication module 2802 need to communicate with each other, but the communication is performed by relaying the terminal 2801. As a method for the server 2803 to authenticate the authentication module 2802, the server 2803 generates a random number, encrypts the random number with the public key of the authentication module, and encrypts the random number to the authentication module 2802 via the terminal 2801. Request to decrypt the random number. The authentication module 2802 acquires a random number generated by the server 2803 by decryption using the secret key of the authentication module 2802 stored in the tamper resistant area, and returns it to the server 2803 by relaying the terminal 2801. The server 2803 determines whether the generated random number is equal to the random number sent from the authentication module 2802 and performs authentication. Alternatively, the server 2803 sends the random number as it is to the authentication module 2802, the authentication module 2802 performs encryption with the secret key, returns the result to the server 2803, and the server 2803 performs decryption with the public key of the authentication module 2802. There is also a method of authenticating the authentication module based on whether it is equal to the random number sent to the authentication module 2802.

  Since the authentication module 2802 is attached to the terminal 2801, when the server 2803 authenticates the authentication module 2802, the terminal 2801 to which the authentication module 2802 is attached is also authenticated. In addition, information unique to the terminal 2801, for example, the manufacturing number of the terminal 2801, an identifier indicating the type of device, an identifier stored in the ROM of the terminal 2801, and a version number are present in the tamper resistant area of the authentication module. If the authentication module 2802 authenticates the terminal 2801 as a condition, the authentication is more reliable.

  As a result, the server 2803 can authenticate the terminal 2801 even if the terminal 2801 does not have a tamper-resistant area, and the server 2803 can correctly authenticate the terminal 2801, and charging between the server 2803 and the terminal 2801 is possible. Processing, payment processing, etc. can be performed. In addition, an application including highly confidential data can be downloaded from the server 2803 to the terminal 2801, and a complicated commercial transaction operation can be executed in the application authentication system in the present embodiment.

  (Embodiment 12)

  FIG. 29 shows a functional block diagram of an application authentication system according to Embodiment 12 of the present invention. In this embodiment, the application authentication system includes a terminal 2801, an authentication module 2802, and a server 2803 for downloading an application to the terminal 2801 as in the eleventh embodiment.

  The terminal 2801 has a download unit 2804 and a TRM access library unit 2901. The download unit 2804 downloads an application. In this case, the application is downloaded from the server 2803. Alternatively, it may be downloaded from other than the server 2803. The TRM access library unit 2901 performs processing for application authentication on the condition that the authentication module 2802 authenticates itself. That is, the TRM access library unit 2901 authenticates itself to the authentication module 2802, and when the authentication is correctly performed, performs processing for authenticating the application downloaded to the download unit 2804. As a method for the TRM access library unit 2901 to authenticate itself to the authentication module 2802, unique information of the terminal 2801, for example, a serial number or an identifier indicating the type, or a serial of software for realizing the TRM access library unit 2901 There is a method of outputting the number, version number, etc. to the authentication module 2802 and checking whether there is unique information, serial number, version number, etc. of the terminal 2801 output to the tamper resistant area of the authentication module 2802.

  The authentication module 2802 includes a TRM unit 2805 and a TRM access library unit authentication unit 2902. The TRM unit 2805 holds TRM access library unit authentication information, which is information for authenticating the TRM access library unit 2901, in the tamper resistant area. As described above, the “TRM access library unit authentication information” is unique information of the terminal 2801, for example, a manufacturing number, an identifier indicating the type, or a serial number and a version number of software that implements the TRM access library unit 2901. Etc. The TRM access library unit authentication unit 2902 authenticates the TRM access library unit 2901 of the terminal 2801 based on the TRM access library unit authentication information. As the authentication method, as described above, unique information of the terminal 2801 output from the TRM access library unit 2901, identification information such as the serial number and version number of the TRM access library unit, and the TRM access library unit authentication unit 2902 are used. There is a method of performing the process based on whether or not the identification information exists in the TRM unit 2805. The result of this authentication is output from the TRM access library unit authentication unit 2902 to the TRM access library unit 2901. The result of this authentication is held in the authentication module 2802 and is referred to when information is exchanged with the terminal thereafter. If the TRM access library unit 2901 is correctly authenticated, the authentication module 2802 Exchange, otherwise exchange incorrect information.

  The server 2803 has a server TRM access library unit authentication unit 2903. Server TRM access library unit authentication unit 2903 determines that authentication of TRM access library unit 2901 has succeeded on the condition that authentication of TRM unit 2805 of authentication module 2802 via access library unit 2901 of terminal 2801 is successful. There are the following methods for the server TRM access library unit authentication unit 2903 to authenticate the TRM unit 2805 of the authentication module 2802 via the access library unit 2901 of the terminal 2801. That is, the server 2803 generates a random number, encrypts the random number with the public key of the authentication module 2802, and requests the authentication module 2802 via the terminal 2801 to decrypt the encrypted random number. The authentication module 2802 decrypts the random number using its own secret key stored in the tamper resistant area and returns it to the server 2803 via the terminal 2801. The server 2803 determines whether the generated random number is equal to the random number sent from the authentication module 2802 and performs authentication. Alternatively, the server 2803 sends the random number as it is to the authentication module 2802, the authentication module 2802 encrypts it with its own private key, returns the result to the server 2803, and the server 2803 decrypts it with the public key of the authentication module 2802. There is also a method of authenticating the authentication module based on whether it is equal to the random number sent to the authentication module 2802.

  FIG. 30 is a sequence diagram illustrating the interaction between server TRM access library unit authentication unit 2903, TRM access library unit 2901, and authentication module 2802. In step S3001, the TRM access library unit 2901 outputs a request for authenticating itself to the authentication module 2802, and in step S3002, an authentication result in the authentication module is output. In step S3003, an authentication request is output from the server TRM access library unit authentication unit 2903 to the TRM access library unit 2901. Correspondingly, an authentication request is output from the TRM access library unit 2901 to the authentication module 2802 in step S3004. In step S3005, the authentication module returns a result so that the authentication module itself is authenticated to the server TRM access library unit authentication unit 2903. At this time, a correct result or an incorrect result is returned depending on whether or not the TRM access library unit 2901 is correctly authenticated. In step S3006, the TRM access library unit 2901 returns the result output from the authentication module 2802 to the server TRM access library unit authentication unit 2903. The server TRM access library unit authentication unit 2903 checks this result, and if the authentication module 2802 can authenticate, it determines that the TRM access library unit 2901 has also been authenticated.

  As described above, the authentication result by the TRM access library unit authentication unit 2902 of the TRM access library unit 2901 is held in the authentication module 2802, and the authentication module 2802 exchanges correct information according to the authentication result. If the server 2803 authenticates the TRM part of the authentication module via the TRM access library part 2901 and can authenticate correctly, it may be determined that the authentication of the TRM access library part 2901 is successful. Become.

  As a result, the server 2803 can authenticate the terminal 2801 even if the terminal 2801 does not have a tamper-resistant area, and the server 2803 can correctly authenticate the terminal 2801, and charging between the server 2803 and the terminal 2801 is possible. Processing, payment processing, etc. can be performed. In addition, an application including highly confidential data can be downloaded from the server 2803 to the terminal 2801, and a complicated commercial transaction operation can be executed in the application authentication system in the present embodiment.

  When the TRM access library unit 2901 is authenticated by the TRM access library unit authentication unit 2902, the TRM access library unit 2901 is determined to be reliable by the authentication module. As a result, when all or part of the authentication processing of the application downloaded to the download unit 2804 is performed by the TRM access library unit 2901, the result of all or part of the authentication processing of the application by the TRM access library unit 2901 is performed. Is reliable for the authentication module 2802. Therefore, the authentication module 2802 can authenticate the application downloaded to the download unit 2804 by using all or part of the result of the application authentication process by the TRM access library unit 2901. As a result, access to data in the authentication module can be permitted to a correctly authenticated application, and a complicated commercial transaction operation can be performed.

  Note that the process for application authentication by the TRM access library unit 2901 may be performed on condition that the application has accessed the tamper resistant area of the TRM unit 2805 of the authentication module 2802. This eliminates the need to authenticate applications that do not access the tamper resistant area.

  Further, the TRM access library unit 2901 may perform processing for application authentication on condition that the application is downloaded to the download unit 2804. As a result, all downloaded applications are authenticated, and there is no possibility that an unauthorized application is executed on the terminal 2801.

  Further, the TRM access library unit 2901 may perform processing for application authentication with the start of application execution as a trigger. As a result, authentication of an application that has been downloaded but not executed can be omitted.

  (Embodiment 13)

  FIG. 31 shows a functional block diagram of an application authentication system according to Embodiment 13 of the present invention. The application authentication system according to this embodiment includes a terminal 2801, an authentication module 2802, and a server 2803 that downloads an application to the terminal 2801.

  The terminal 2801 includes a download unit 2804 and a TRM access library unit 2901. The TRM access library unit 2901 includes a signature digest generation unit 3101, a download application signature acquisition unit 3102, and an application authentication data output unit 3103. I have.

  The download unit 2804 downloads the application 3104. The application 3104 may be downloaded from the server 2803. Further, other than the server 2803, for example, it may be downloaded from the authentication module 2802. In this embodiment, the application 3104 is downloaded together with the signature 3105 of the application 3104. “Downloaded together with the signature 3105” not only means that they are downloaded at the same time, but the download of the application 3104 and the download of the signature 3105 may be performed before or after, and authentication of the application 3104 described later is performed. By time, it means that the application 310 and the signature 3105 have been downloaded.

  The signature digest generation unit 3101 generates a signature digest from the application. That is, a signature digest is generated from the application 3104 downloaded to the download unit 2804. The “signature digest” is a value obtained by using the same hash function as that used when generating the signature 3105.

  The download application signature acquisition unit 3102 acquires the signature 3105 downloaded together with the download of the application 3104. As described above, “downloaded together with the download of the application 3104” does not only mean that the application 3104 is downloaded at the same time, but the application 3104 and the signature 3105 are not downloaded until the later-described authentication of the application 3104 is performed. It means that it has finished.

  The application authentication data output unit transmits the acquired signature and the signature digest generated by the signature digest generation unit 3101 to the server. The “acquired signature” is the signature 3105 acquired by the download application signature acquisition unit 3102.

  The signature digest generation unit 3101, the download application signature acquisition unit 3102, and the application authentication data output unit 3103 perform processing for authenticating the application 3104 downloaded to the download unit 2804. This process may be performed on condition that the TRM access library unit 2901 has been authenticated by the authentication module 2802.

  The authentication module has a TRM unit 2805 and a TRM access library unit authentication unit 2902. The TRM unit 2805 and the TRM access library unit authentication unit 2902 are the same as the TRM unit and the TRM access library unit of the twelfth embodiment.

  The server 2803 includes a server TRM access library unit authentication unit 2903, an application authentication data input unit 3106, and a server application authentication unit 3107.

  The server TRM access library unit authentication unit 2903 is the same as that in the twelfth embodiment, and the TRM access library unit is provided on the condition that the authentication of the TRM unit 2805 of the authentication module via the TRM access library unit 2901 of the terminal 2801 is successful. It is determined that 2901 authentication is successful.

  The application authentication data input unit 3106 receives the signature digest output from the application authentication data output unit 3103 of the TRM access library unit 2901 determined by the server TRM access library unit authentication unit 2903 that the authentication was successful, and the signature. input.

  The server application authentication unit 3107 performs application authentication based on the signature digest input to the application authentication data input unit 3106 and the signature. Authentication is performed by decrypting the signature to obtain a digest and determining whether the digest is equal to the signature digest. If the signature is encrypted with the private key of the public key encryption system server 2803, the signature digest input to the application authentication data input unit 3106 is encrypted with the private key of the server 2803, and the signature is obtained. It may be determined whether or not the signature is the same as the signature input to the application authentication data input unit 3106.

  FIG. 32 shows the interaction along the time of the server 2803, the terminal 2801, and the authentication module 2802 constituting the application authentication system in the present embodiment. Steps S3201 to S3206 are the same as steps S3001 to S3006 in FIG. 30 in the twelfth embodiment. When the application 3104 is downloaded to the download unit 2804 after step S3206, the signature digest generation unit 3101 generates a signature digest of the application 3104, the download application signature acquisition unit 3102 acquires the signature 3105, and the application 3104 The authentication data output means 3103 inputs the signature digest and signature to the application authentication data input unit 3106 (step S3207). Thereafter, the application 3104 is authenticated by the signature digest and signature input to the application authentication data input unit 3106 by the server application authentication unit 3107.

  According to the present embodiment, the server TRM access library unit authentication unit 2903 of the server 2803 is authenticated on the condition that the authentication of the TRM unit 2805 of the authentication module 2802 via the TRM access library unit 2901 of the terminal 2801 is successful. It is determined that the authentication of the TRM access library unit 2901 has succeeded. Therefore, in the server 2803, the signature digest and the signature 3105 of the application 3104 that the application authentication data output unit 3103 of the TRM access library unit 2901 transmits to the application authentication data input unit 3106 are actually derived from the application 3104. The server can authenticate the application 3104.

  (Embodiment 14)

  FIG. 33 shows a functional block diagram of an application authentication system according to Embodiment 14 of the present invention. In the thirteenth embodiment, a part of the authentication process of the application downloaded to the download unit 2804 is executed by the server 2803. However, in the present embodiment, the application other than the server 2803 Authentication is performed, and the server 2803 obtains only the authentication result.

  The terminal 2801 has a download unit 2804 and a TRM access library unit 2901. The download unit 2804 downloads an application. The TRM access library unit 2901 includes authentication success information generation means 3301 and authentication success information output means 3303.

  The authentication success information generating unit 3301 generates authentication success information 3302 indicating the success of application authentication. In the present embodiment, application authentication may be performed only within the TRM access library unit 2901. In addition, the TRM access library unit 2901 and the authentication module 2802 may cooperate, and the authentication success information generating unit 3301 acquires the result of the authentication and indicates whether the authentication is successful. Authentication success information 3302 is generated. At this time, the authentication success information 3302 may be encrypted with the authentication module 2802 private key or the server 2803 public key.

  The authentication success information output unit 3303 outputs the authentication success information 3302 generated by the authentication success information generation unit 3301. If the authentication success information 3302 is not encrypted, the authentication success information 3302 may be encrypted with the secret key of the authentication module 2802 or the public key of the server 2803 and output.

  The authentication module 2802 includes a TRM unit 2805 and a TRM access library unit authentication unit 2902, and performs the same operation as in the thirteenth embodiment.

  The server 2803 includes a server TRM access library unit authentication unit, an authentication success information input unit 3304, and a server application authentication unit 3305.

  The server TRM access library unit authentication unit performs the same operation as in the thirteenth embodiment.

  The authentication success information input unit 3304 inputs the authentication success information output from the authentication success information output unit of the TRM access library unit that is determined to have been successfully authenticated by the server TRM access library unit authentication unit. When the TRM access library unit 2901 determines that the authentication is successful by the server TRM access library unit authentication unit, the information output by the TRM access library unit 2901 and the authentication module 2802 is reliable for the server 2803. Therefore, the contents of the authentication success information output unit 3303 can be determined to be reliable.

  The server application authentication unit 3305 performs application authentication based on the authentication success information input to the authentication success information input unit 3304. For example, when the authentication success information output by the authentication success information output unit 3303 is encrypted with the secret key of the authentication module 2802 or the public key of the server 2803, decryption is performed to check the contents of the authentication success information. Then, the application downloaded to the download unit 2804 is authenticated.

  (Embodiment 15)

  In the present invention, in order to authenticate an application (application program), it is necessary to download the application and download the signature. In the following, an application storing an application signature will be described.

  An application program can usually be divided into an application body and an application definition file. The “application body” is code or data for executing the application program, the “application definition file” is a file describing the attributes of the application body, and the “application body attributes” are, for example, The size of the application main body, the entry point for executing the application program, and parameters to be passed to the application program when executing the application program (in Java (registered trademark), the main class activation parameter), and the like. In the application definition file, when the part describing the attribute of the application main body is called an “attribute information storage unit”, there may be an optional area in the attribute information storage unit that can be freely used by the creator of the application. Therefore, the signature data of the application main body may be stored in this optional area. Note that the application main body may not be the code and data itself, but may be a compressed code and data. Similarly, the application definition file may be a compressed attribute description of the application body.

  FIG. 34 illustrates the structure of a Java (registered trademark) application, in particular, an i-appli application. In the i-appli, the application main body is stored in a JAR file 3401 and the application definition file is provided as an ADF file 3402. The attribute of the application main body stored in the ADF file 3402 is indicated by an essential key AppName as the name of the application, and the size of the application main body is indicated by the essential key AppSize. Further, as an optional area that can be freely used by the creator of the application, there is an area indicated by an optional key called AppParam. The area indicated by AppParam can use a maximum of 255 bytes. On the other hand, the signature of the application main body requires 20 bytes when 160-bit elliptical encryption is used, and 128 bytes are required when 1024-bit RSA encryption is used, and it fits in the area indicated by AppParam. Accordingly, the signature of the application main body can be stored in the area indicated by AppParam.

  FIG. 35 is a flowchart for explaining the operation in the case of authenticating the application storing the signature data of the application main body in the optional area as described above. In step S3501, signature data is acquired from the optional area. In step S3502, the signature is verified using the signature data acquired in step S3501. These steps can be executed by a program.

  FIG. 34 can also be regarded as showing the data structure of the application program. That is, it can be regarded as a data structure including a JAR file part 3401 that stores a JAR file that is a compressed file of codes and data, and an ADF file part 3402 that stores an ADF file that is an application definition file. In such a data structure, the ADF file of the ADF file part 3402 has an area indicated by AppParam for storing the start parameters of the main class and the like, and is stored in the JAR file part 3401 in the area indicated by AppParam. The signature of the JAR file is stored.

  The signature of the JAR file stored in the area indicated by AppParam may be a signature by a person who guarantees the operation of the application. Here, “the person who guarantees the operation of the application” means the person who created the application that operates by the code and data stored in the JAR file, the person who distributes the application, the person who created the application, It is a third party who verifies the operation and guarantees that it does not perform an illegal operation.

  Since the data structure of the application program shown in FIG. 34 can be expressed by a bit string (bit stream), recording such as an (SD) memory card, a floppy (registered trademark) disk, a compact disk, or the like recording such a bit string. Media can be created.

  With such an application program, when an application is downloaded, not only the application main body but also the signature of the application main body is downloaded, so that the trouble of downloading the signature can be saved.

  (Embodiment 16)

  FIG. 37 illustrates a functional block diagram of a terminal according to Embodiment 16 of the present invention. A feature of the present embodiment is that an authentication module is provided inside the terminal in the application authentication system of the first embodiment and is integrated.

  In the present embodiment, terminal 3700 has a download unit 3701 and a TRM unit 3702.

  The download unit 3701 downloads an application. That is, it has the same function as the download unit 102 in the first embodiment.

  The TRM unit 3702 holds information for application authentication in a tamper resistant area. That is, it has the same function as the TRM unit 103 in the authentication module 101 in the first embodiment.

  Therefore, in the terminal of the present embodiment, the procedure for downloading the application and the procedure for authenticating the downloaded application may be the same as those in the first embodiment.

  By using such a terminal, for example, when an authentication process is performed on an application downloaded from a service provider to the download unit 3701 of the terminal 3700 and the authentication process is successful, Access to information stored in the terminal such as information held in the TRM unit 3702 can be safely permitted.

  Note that the term “terminal” is used, but this does not mean that the terminal is limited to a portable terminal represented by a mobile phone. For example, it may be a household electrical appliance, or a so-called information home appliance or internet home appliance. Examples of such products include air conditioners, humidifiers, dehumidifiers, air purifiers, microwave ovens, refrigerators, dishwashers, water heaters, irons, trouser presses, vacuum cleaners, washing machines, and dryers. Machines, electric blankets, electric mattresses, lighting equipment, television receivers, radio receivers, tape recorders and other audio equipment, cameras, IC recorders, telephones, facsimile transceivers, copiers, printers, scanners, personal computers, etc. (This is also true for the “terminal” in the seventeenth embodiment described below).

  (Embodiment 17)

  FIG. 38 illustrates a functional block diagram of a terminal according to Embodiment 17 of the present invention. The feature of this embodiment is that the terminal and the authentication module are integrated so that an authentication module is provided inside the terminal in the application authentication system such as the second embodiment.

  In this embodiment, the terminal 3800 is a terminal provided with an authentication module 3801, and includes a download unit 3802 and a TRM access library unit 3803. The authentication module 3801 has a TRM unit 3804 and a TRM access library unit authentication unit 3805.

  The authentication module 3801 holds information in the tamper-resistant area and performs a process for authentication using the information. Details will be described later.

  The download unit 3802 downloads an application. That is, it has the same function as the download unit 102 in the second embodiment.

  The TRM access library unit 3803 performs processing for application authentication on the condition that the authentication module 3801 authenticates itself. That is, it has the same function as the TRM access library unit 401 in the second embodiment. Note that “authenticate itself to the authentication module 3801” means that the TRM access library unit authentication unit 3805 authenticates, as will be described later.

  The TRM unit 3804 holds the TRM access library unit authentication information in the tamper resistant area. The “TRM access library authentication information” is information for authenticating the TRM access library unit and is the same as the definition in the second embodiment. Therefore, the TRM unit 3804 has the same function as the TRM unit 103 in the second embodiment or the like. Note that the tamper-resistant region may be inside the TRM unit 3804, or inside the authentication module 3801 and outside the TRM unit 3804.

  The TRM access library unit 3805 authenticates the TRM access library unit 3803 based on the TRM access library unit authentication information. Therefore, the TRM access library unit 3805 has the same function as the TRM access library unit 402 in the second embodiment.

  FIG. 39 illustrates a flowchart for explaining a processing flow of terminal 3800 in the present embodiment. In the processing illustrated in this flowchart, it is assumed that an application is downloaded to the download unit 3802.

  In step S3901, the TRM access library unit authentication unit 3805 performs authentication of the TRM access library unit 3803.

  In step S3902, it is determined whether or not the TRM access library unit 3803 has been authenticated. If it has been authenticated, the process proceeds to step S3903. In FIG. 39, if authentication is not performed, the processing is terminated. Instead, the application downloaded to the download unit 3802 may be discarded.

  In step S 3903, the TRM access library unit 3803 performs processing for authenticating the application downloaded to the download unit 3802.

  If the downloaded application is authenticated in step S3904, the process proceeds to step S3905. If not authenticated, the process ends. Instead of ending the process, the application downloaded to the download unit 3802 may be discarded.

  In step S3905, access to the authentication module by the downloaded application is permitted. This authorization is performed by the authentication module 3801. Alternatively, when the application accesses the authentication module 3801, if the function of the TRM access library unit 3803 is always used, the TRM access library unit 3803 may permit access to the authentication module. Good.

  Note that as described in the second embodiment, the TRM access library unit 3802 may include an application manager, a device driver, and the like.

  According to the present embodiment, by providing an authentication module inside the terminal, it is possible to hold information that should be highly protected inside the terminal, and to authenticate applications downloaded to the terminal. It becomes possible.

  (Embodiment 18)

  Embodiment 18 of the present invention relates to an application authentication system comprising a first device and an authentication module. In the present embodiment, the application stored in the first device is authenticated using the information held by the authentication module.

  FIG. 40 illustrates a functional block diagram of the application authentication system of this embodiment. The application authentication system includes a first device 4001 and an authentication module 4002. The first device is not limited to a terminal, and may be, for example, a personal computer, a workstation, a large computer, or a server device. Further, the first device 4001 and the authentication module 4002 do not need to be directly electrically connected and do not need to be in physical contact. For example, it may be connected wirelessly. Further, they may be connected by a network represented by the Internet. In particular, the network may be constructed using a medium that does not use electrical conduction, such as an optical cable.

  The first device 4001 has an application storage unit 4003. The application storage unit 4003 stores an application. The application is not limited to a program that operates on the first device 4001. An application that operates on a device other than the first device 4001 may be used. “Storing” means holding an application. The length of time to hold is not ask | required. Also, the purpose of holding does not matter. For example, the storage for operating the application on the first device 4001 may be the purpose. Also, the purpose may be to download the application to the first device 4001 and operate it. Alternatively, it may be intended to temporarily hold the first device 4001 for relaying when the application is transmitted by communication. Alternatively, retention for downloading the application to a device other than the first device 4001 may be the purpose.

  The authentication module 4002 has a TRM unit 4004. The TRM unit 4004 holds information for application authentication processing in a tamper resistant area. Examples of the information for the application authentication process include a secret key for encryption, a certificate for confirming the authenticity of the signature of the application, and the like. The application here is an application stored in the application storage unit 4003 of the first device 4001. Therefore, the TRM unit 4004 of the authentication module in the present embodiment may have the same function as the TRM unit in the first embodiment. In this case, the application authentication processing method and the like are the same as those in the embodiment.

  The application authentication system according to the present embodiment can authenticate an application stored in the application storage unit 4003 of the first device 4001. For example, the application is prevented from performing illegal operations. be able to.

  Note that the first device 4001 may be a home appliance. Moreover, what is called an information household appliance or an internet household appliance may be used. Examples of such products include air conditioners, humidifiers, dehumidifiers, air purifiers, microwave ovens, refrigerators, dishwashers, water heaters, irons, trouser presses, vacuum cleaners, washing machines, and dryers. Machines, electric blankets, electric mattresses, lighting equipment, television receivers, radio receivers, tape recorders and other audio equipment, cameras, IC recorders, telephones, facsimile transceivers, copiers, printers, scanners, personal computers, etc. be able to.

  (Embodiment 19)

  The nineteenth embodiment of the present invention also relates to an application authentication system including a first device and an authentication module, as in the eighteenth embodiment. In the present embodiment, when authentication of an application stored in the first device is performed, a portion that performs the authentication in the first device is authenticated by the authentication module.

  FIG. 41 illustrates a functional block diagram of the application authentication system in the present embodiment. The application authentication system includes a first device 4101 and an authentication module 4102. Note that, as in the eighteenth embodiment, the first device 4101 and the authentication module 4102 do not need to be directly electrically connected and do not need to be in physical contact.

  The first device 4101 has an application storage unit 4103 and a TRM access library unit 4104.

  The application storage unit 4103 stores applications. For example, it has the same function as the application storage unit 4003 in the eighteenth embodiment.

  The TRM access library unit 4104 performs processing for application authentication on the condition that the authentication module 4102 authenticates itself. Here, “self” means the TRM access library unit 4104. Alternatively, “self” may be a part including the TRM access library unit 4104. For example, the first device 4101 itself may be “self”.

  “Application” means an application stored in the application storage unit 4003.

  Therefore, the TRM access library unit 4104 performs a process for authenticating itself by the authentication module, and performs a process for authenticating the application stored in the application storage unit 4103 when the process is successfully authenticated.

  As described in the second embodiment, the TRM access library unit 4104 may include an application manager and a device driver, and perform these processes.

  The authentication module 4102 includes a TRM unit 4105 and a TRM access library unit authentication unit 4106.

  The TRM unit 4105 holds the TRM access library unit authentication information in the tamper resistant area. The “TRM access library unit authentication information” is information for authenticating the TRM access library unit. For example, information for specifying the first device can be given. Examples of such information include the manufacturer number and serial number of the first device, and, if a telephone number is assigned to the first device, the telephone number as an example. In addition, information such as information on other devices to which the first device is connected, information for identifying the parts installed in the first device, or the version number of the program installed in the first device, etc. It may indicate the situation where one device is placed. Further, when the first device can hold some secret information, for example, an encryption key, information for detecting that the encryption key is authentic may be used as the TRM access library unit authentication information.

  For the tamper resistant region, refer to the description of the second embodiment.

  The TRM access library unit authentication unit 4106 authenticates the TRM access library unit 4104 of the first device 4101 based on the TRM access library unit authentication information. That is, the information sent from the TRM access library unit 4104 is acquired, it is determined whether the information obtained from the TRM access library unit 4104 is compatible with the TRM access library unit authentication information, and the authentication process is performed. Do.

  Note that the target to be authenticated by the TRM access library unit authentication unit 4106 is not limited to the TRM access library unit 4104 but may be a part including the TRM access library unit 4104. The whole may be authenticated. In this case, the TRM access library unit authentication information may use the serial number of the first device 4101 or the situation where the first device 4101 is placed.

  FIG. 42 illustrates a flowchart for explaining the operation of the application authentication system in the present embodiment.

  In step S4201, authentication processing of the TRM access library unit 4104 is performed by the TRM access library unit authentication unit 4106. At this time, the TRM access library unit authentication information held in the tamper resistant area is used.

  In step S4202, it is determined whether or not the TRM access library unit 4104 has been authenticated by the processing in step S4201. If it is determined that the application has been authenticated, the TRM access library unit 4104 performs authentication of the application stored in the application storage unit 4103 in step S4203.

  In the present embodiment, the TRM access library unit 4104 authenticated by the TRM access library unit authentication unit 4106 of the authentication module 4102 authenticates the application. For this reason, the authentication result of the application is reliable for the authentication module 4102. As a result, when an access to the authentication module occurs due to the execution of the application stored in the application storage unit 4103, the authentication module can permit the access. Further, for example, even if the application storage unit 4103 is provided for the purpose of downloading an application to another device, access to the authentication module from the application downloaded from the application storage unit 4103 may be permitted. it can. In addition, information indicating that the authentication module 4102 has authenticated can be added to the application. As a result, it is possible to realize processing more complicated than conventional processing.

  (Embodiment 20)

  The application authentication system shown in the nineteenth embodiment is composed of two main devices, the first device and the authentication module. However, as shown in the present embodiment, the number of main devices is not limited to two.

  FIG. 43 illustrates a functional block diagram of the application authentication system when the number of main devices is three. This application authentication system includes a first device 4301, a second device 4302, and a third device 4303. That is, the application authentication system has three main parts. These three main parts are connected in series, but as described in the eighteenth and nineteenth embodiments, they are directly connected electrically or physically contacted. There is no need to be. Further, one person may own or occupy the first device 4301, the second device 4302, and the third device 4303, and these three devices may be owned or occupied by different persons. It may be.

  The correspondence with the application authentication system of the nineteenth embodiment is as follows. That is, the first device 4301 corresponds to the authentication module, and the third device 4303 corresponds to the terminal or the first device 4101 in the nineteenth embodiment.

  The first device 4301 includes a TRM unit 4304 and a first authentication processing unit 4305.

  The TRM unit 4304 holds authentication information for authenticating the second device in the tamper resistant area. Therefore, it has the same function as the TRM unit in the nineteenth embodiment. However, the difference is that the information held in the tamper resistant area is authentication information for authenticating the second device. Note that the tamper-resistant area may hold not only information for authenticating the second device, but also information for authenticating the third device. As this authentication information, similar to the TRM access library unit authentication information in the nineteenth embodiment, the device manufacturing number, information indicating the status of the device, or the device holds the encryption key and certificate. If possible, information for detecting the authenticity of the encryption key or certificate can be listed.

  The first authentication processing unit 4305 authenticates the second device 4302 based on the authentication information. The “authentication information” is authentication information held in the tamper resistant area.

  The second device 4302 has a second authentication processing unit 4306. The second authentication processing unit 4306 authenticates the third device 4303 on the condition that it is authenticated by the first authentication processing unit. Here, “self” means the second device 3402 including the second authentication processing unit 4306.

  When the second device 4302 is authenticated by the first authentication processing unit 4305, the second device 4302 can be regarded as a reliable device for the first device 4301. Therefore, the first device 4301 can permit the second device 4302 to access information held in the tamper resistant area. Therefore, when the second authentication processing unit 4306 authenticates the third device 4303, it is possible to use information held in the tamper resistant area. Therefore, when the second authentication processing unit 4306 authenticates the third device 4303, information held in the tamper resistant area may be used.

  As described above, the second authentication processing unit 4306 may include a device driver function for accessing the first device 4301.

  Further, the second authentication processing unit 4306 may acquire information necessary for authenticating the third device 4303 from a different device different from the first device and the third device. At the time of this acquisition, the second authentication processing unit 4306 may present information indicating that the second device 4302 is authenticated by the first authentication processing unit 4305.

  The third device 4303 includes an application storage unit 4307 and a third authentication processing unit 4308. The application storage unit 4307 stores an application. Therefore, it has the same function as the application storage unit in the nineteenth embodiment. For this reason, the length of time for storing the application and the purpose of storing are not particularly limited.

  The third authentication processing unit 4308 performs processing for authenticating the application on the condition that the second device 4302 is authenticated by the second device 4302. “The application” means an application stored in the application storage unit 4307. Also, “self” means the third device 4303.

  When the third device 4303 is authenticated by the second authentication processing unit 4306, the third device 4303 can be regarded as a reliable device for the first device 4301. Therefore, the first device 4301 can permit the third device 4303 to access information held in the tamper-resistant area. Therefore, when the third authentication processing unit 4306 authenticates the application, it is possible to use information held in the tamper resistant area.

  Further, the third authentication processing unit 4308 may acquire information necessary for authenticating the application from a different device different from the first device and the second device. At the time of this acquisition, the third authentication processing unit 4308 may present information indicating that the third device 4302 has been authenticated by the second authentication processing unit 4306. At this time, information indicating that the second device 4302 is authenticated by the first authentication processing unit 4305 may be presented.

  FIG. 44 illustrates a flowchart for explaining the operation of the first device 4301. In step S4401, the first authentication processing unit 4305 acquires the authentication information that the TRM unit 4304 holds in the tamper resistant area. In step S4402, the second device is authenticated. In step S4403, it is determined whether authentication is successful. If the authentication is successful, in step S4404, the authentication is transmitted to the second device.

  FIG. 45 illustrates a flowchart for explaining the operation of the second device 4302. In step S4501, it is determined whether the first authentication processing unit 4305 is authenticated. This determination is made based on whether or not authentication is transmitted from the first device 4301 in step S4404 shown in FIG. If authenticated, the second authentication processing unit 4306 performs authentication processing of the third device in step S4502. In step S4503, it is determined whether authentication is successful. If the authentication is successful, in step S4504, the authentication is transmitted to the third device.

  FIG. 46 illustrates a flowchart for explaining the operation of the third device 4303. In step S4601, it is determined whether the second authentication processing unit 4306 has authenticated. This determination is made based on whether or not authentication is transmitted from the second device 4302 in step S4504 shown in FIG. If authenticated, application authentication processing is performed in step S4602. In FIG. 46, the process ends here, but the result of the application authentication process may be transmitted to the first device 4301, for example. Alternatively, the information may be transmitted to the second device 4302. If the application accesses another device, information indicating that the application has been authenticated by the third authentication processing unit 4308 may be presented. Alternatively, information indicating that the application is authenticated by the third authentication processing unit 4308 may be added to the application.

  The above is a case where the application authentication system is configured by three main devices. However, as illustrated in FIG. 47, the application authentication system may be configured by four main devices.

  47, the application authentication system includes a first device 4701, a second device 4702, a third device 4703, and a fourth device 4704. The first device 4701 has a TRM unit 4705 and a first authentication processing unit 4706, which correspond to the TRM unit 4304 and the first authentication processing unit 4305 exemplified in FIG. To do. The second device 4702 has a second authentication processing unit 4707. This corresponds to the second authentication processing unit 4306 illustrated in FIG.

  The third device has a third authentication processing unit 4708. The third authentication processing unit 4708 authenticates the fourth device 4704 on the condition that the second authentication processing unit 4707 authenticates itself. If the third device 4703 is authenticated by the second authentication processing unit 4707, the third device 4703 becomes a reliable device for the first device 4701. Therefore, the first device 4701 is the third device 4703. However, it is possible to allow the TRM unit 4705 to access information held in the tamper resistant area. Therefore, the third authentication processing unit 4708 may acquire information held in the tamper resistant region by the TRM unit 4705 and authenticate the fourth device 4704. Further, information held in another device may be acquired and authenticated.

  Note that when the third authentication processing unit 4708 acquires information held by the TRM unit 4705 in the tamper-resistant area, the third device 4703 and the first device 4701 can directly communicate with each other. In addition, the third device 4703 and the first device 4701 may be provided with a communication unit. Alternatively, when the second authentication processing unit 4707 has a device driver function for accessing the first device 4701, the following may be performed. That is, the third authentication processing unit 4708 uses the device driver function of the second authentication processing unit 4707 to acquire information held in the tamper-resistant region by the TRM unit 4705 via the second device 4702. Therefore, the third authentication processing unit 4708 may have a device driver function for accessing the second authentication processing unit 4707.

  The fourth device 4704 includes an application storage unit 4709 and a fourth authentication processing unit 4710. The application storage unit 4709 corresponds to the application storage unit 4307 in FIG. The fourth authentication processing unit 4710 authenticates the application on the condition that the third authentication processing unit 4708 authenticates itself. Here, “self” means the fourth device. Accordingly, if the fourth device is authenticated by the third authentication processing unit 4708, it is considered that the first authentication processing unit 4706 has authenticated, so the fourth authentication processing unit holds the TRM unit 4705 in the tamper-resistant region. The application stored in the application storage unit 4709 can be authenticated using the information to be stored. In addition, the fourth authentication processing unit 4710 presents information indicating that the third authentication processing unit 4708 has been authenticated to another device, acquires information for application authentication, and authenticates the application. You may make it perform.

  Thus, the operation when the application authentication system is configured by four main devices is as follows. The operation of the first device 4701 is the same as that illustrated in FIG. Similarly, the operation of the second device 4702 is illustrated in FIG. The operation of the third device 4703 is as illustrated in FIG. That is, in step S4801, it is determined whether the third device 4703 has been authenticated by the second authentication processing unit 4707. If authenticated, in step S4802, the fourth device 4704 is authenticated. In step S4803, it is determined whether or not the authentication is successful. If the authentication is successful, the authentication is transmitted to the fourth device 4704 in step S4804.

  The operation of the fourth device is illustrated in FIG. In step S4901, it is determined whether or not authentication has been performed by the third authentication processing unit 4708. If authentication has been performed, application authentication processing is performed in step S4902. The result of the application authentication process may be transmitted to the first device 4701, for example. Further, it may be transmitted to the second device 4702. If the application accesses another device, information indicating that the third authentication processing unit 4708 has authenticated may be presented. Alternatively, information indicating that the application has been authenticated by the third authentication processing unit 4708 may be added to the application.

  Furthermore, the number of main devices is not limited to four, and as illustrated in FIG. 50, the first device 5001, the second device 5002, the third device 5003, and the fourth device. The application authentication system may be configured by five devices 5004 and the fifth device 5005.

  FIG. 51 illustrates a functional block diagram of the application authentication system when the main numbers are generalized. In FIG. 51, the application authentication system includes (N + 1) devices that can be connected in series from the first device 5101 to the (N + 1) th device 5105. Although written as “connected”, this does not mean that it is directly electrically connected or in physical contact. For example, it may be connected by a network represented by the Internet. In particular, they may be connected by a network using an optical cable. Moreover, it may be connected by radio. In addition, each device may be connected to each other.

  The first device 5101 includes a TRM unit 5101 and a first authentication processing unit 5102. The TRM unit 5101 holds authentication information, which is information for authenticating the second device 5102, in the tamper resistant area. The first authentication processing unit 5102 authenticates the second device 5102 based on the authentication information.

  Hereinafter, any one device from the second device 5102 to the N-th device will be referred to as an i-th device. The i-th device has an i-th authentication processing unit. The i-th authentication processing unit authenticates the (i + 1) -th device on the condition that it is authenticated by the (i-1) -th authentication processing unit. Here, “self” means the i-th device. Therefore, the i-th authentication processing unit authenticates the (i + 1) -th device if the i-th device is authenticated by the (i-1) -th authentication processing unit. If the i-th device is authenticated by the (i-1) -th authentication processing unit, the i-th device can be regarded as reliable for the first device 5101. Therefore, the first device 5101 The i-th device can permit access to information held in the tamper-resistant area by the TRM unit 5101. Therefore, the i-th device may authenticate the (i + 1) -th device using information held in the tamper-resistant area.

  For example, when the i-th authentication processing unit accesses information held in the tamper-resistant area by the TRM unit 5107, the i-th device and the first device may directly communicate with each other.

  The i-th authentication processing unit may have a function such as a device driver for accessing the (i-1) -th authentication processing unit. With this provided function, requests for information are sequentially output from the i-th authentication processing unit to the first authentication processing unit 5107, and the requested information is returned in order from the first authentication processing unit 5107 to the i-th authentication processing unit. It becomes like this.

  The (N + 1) -th device 5105 has an application storage unit 5111 and an (N + 1) -th authentication processing unit 5112. The application storage unit 5111 stores applications. The time for storing the application is not particularly limited. For example, the application may be stored in order to execute the application in the (N + 1) -th device 5105, or the transmission of the application is relayed. It may be stored temporarily only in this. Further, the storage purpose is not particularly limited, and not only when the application is executed by the (N + 1) -th device 5105, but also for the purpose of downloading for executing the application on another device. Further, the application may be stored for the purpose of downloading and executing the application in the (N + 1) -th device 5105. In addition, although the name “application” is used, it need not be a program and may be data.

  The (N + 1) th authentication processing unit 5112 authenticates the application on the condition that it is authenticated by the Nth authentication processing unit. “Self” means the (N + 1) -th device 5105, and “application” means an application stored in the application storage unit 5111.

  A flowchart for explaining the operation of the first device 5101 is illustrated in FIG.

  FIG. 52 is a flowchart for explaining the operation of any one device from the second device to the Nth device. In step S5201, it is determined whether or not the (i-1) th authentication processing unit has been authenticated. If authenticated, the (i + 1) th device authentication process is performed in step S5202. In step S5203, it is determined whether or not the (i + 1) th device has been authenticated. If it has been authenticated, the fact that it has been authenticated is transmitted to the (i + 1) th device. As a result, the authentication is performed from the second device to the Nth device in order.

  FIG. 53 illustrates a flowchart of the operation of the (N + 1) -th device 5105. In step S5301, it is determined whether or not authentication has been performed by the Nth authentication processing unit 5105. If it is determined that authentication has been performed, application authentication processing is performed in step S5302. If the application can be authenticated, the result is transmitted to the first device 5101 or the like, and access to the first device 5101 by the application is permitted. Alternatively, information indicating that authentication has been performed may be added to the application.

  43, 47, 50, and 51, the devices are connected in series, but the devices may be connected using a nested structure. FIG. 54 schematically illustrates that devices are connected using a nested structure. The secure device 5401 corresponds to a first device, and includes a TRM unit and a first authentication processing unit. The secure device 5402 is connected so as to be incorporated as a part of the adapter 5402 corresponding to the second device. The adapter 5402 is connected so as to be incorporated as a part of the communication module 5403 corresponding to the third device. Further, the communication module 5403 is connected so as to be incorporated as a part of a PDA (Personal Digital Assistance) 5404 corresponding to the fourth device. The PDA 5404 is connected to a server corresponding to the fifth device through a communication line or the like with the server 5405. By connecting in this way, for example, an application stored in the server 5405 can be authenticated using information held in the tamper resistant area of the secure device 5401.

  Note that the (N + 1) -th device 5105 may be, for example, a household appliance. Moreover, what is called an information household appliance or an internet household appliance may be used. Examples of such home appliances include air conditioners, humidifiers, dehumidifiers, air purifiers, microwave ovens, ovens, refrigerators, dishwashers, water heaters, irons, trouser presses, vacuum cleaners, washing machines , Dryers, electric blankets, electric mattresses, lighting equipment, television receivers, radio receivers, audio equipment such as tape recorders, cameras, IC recorders, telephones, facsimile transceivers, copiers, printers, scanners, personal computers, etc. Can be mentioned.

  (Embodiment 21)

  In the twentieth embodiment, when any one of the second device to the N-th device is expressed as the i-th device, the i-th device is necessary for authenticating the (i + 1) -th device. Such information may be held. For example, the i-th device may have a tamper resistant area, and may hold information necessary for authentication.

  In this way, when there is a case where the i-th device may hold authentication information that is information necessary for authentication, the i-th device may have the i-th authentication information acquisition unit. Here, the i-th authentication information acquisition unit acquires authentication information from the authentication information storage area when the i-th device has an authentication information storage area that stores the authentication information. It is a part to do. In addition, when the authentication information is stored in the TRM unit of the first device, the i-th authentication information acquisition unit transmits the TRM via the devices from the second device to the (i-1) -th device. Get authentication information from the department. “Through a device from the second device to the (i-1) th device” means the following. That is, the i-th authentication information acquisition unit outputs a request for authentication information to the (i-1) -th authentication information acquisition unit, and finally the second authentication information acquisition unit issues a request for authentication information to the first device. Output. When the second authentication information acquisition unit acquires the authentication information from the first device, the authentication information is output to the third authentication information acquisition unit. Finally, the (i-1) th authentication information acquisition unit outputs the i-th authentication information. Output authentication information to the acquisition unit.

  FIG. 55 illustrates a flowchart for explaining the operation of the i-th device in the present embodiment. In step S5501, it is determined whether the (i-1) th authentication processing unit has authenticated. If it is determined that authentication has been performed, the process moves to step S5502, and it is determined whether authentication information of the (i + 1) -th device is stored in the authentication information storage area. For example, information stored in the authentication information storage area is read to determine whether authentication information can be obtained. If not stored, the process moves to step S5503, and authentication information is acquired from the TRM unit via the second device to the (i-1) th device. In step S5504, authentication processing of the (i + 1) -th device is performed, and it is determined in step S5505 whether or not authentication is successful. If the authentication is successful, the authentication is transmitted to the (i + 1) -th device in step S5506.

  By performing such processing, even if the number of devices constituting the application authentication system increases, if the device has authentication information, authentication is performed using the authentication information. It is possible to end the device authentication time in a short time.

Functional block diagram of the application authentication system in the first embodiment The figure which shows the Example of the application authentication system in Embodiment 1. FIG. The figure which shows the Example of the application authentication system in Embodiment 1. FIG. Functional block diagram of the application authentication system in the second embodiment Functional block diagram of the application authentication system in the second embodiment Diagram explaining the relationship between the application body and signature Flowchart for explaining the operation of the terminal in the second embodiment Flowchart for explaining the operation of the authentication module in the second embodiment Functional block diagram of the authentication module in the third embodiment Flowchart for explaining the operation of the authentication module in the third embodiment Functional block diagram of the application authentication system in the fourth embodiment The flowchart explaining the process which a terminal authenticates the authentication module in Embodiment 4. Functional block diagram of the application authentication system in the fifth embodiment Diagram showing application usage resource information The figure which shows the state where application use resource information is downloaded with the application typically Functional block diagram of the application authentication system in the sixth embodiment Functional block diagram of the application authentication system in the seventh embodiment Functional block diagram of the application authentication system in the eighth embodiment Flowchart explaining the operation of the terminal in the eighth embodiment Flowchart explaining operation of authentication module in embodiment 8 Functional block diagram of the application authentication system in the ninth embodiment Flowchart for explaining the operation of the authentication module in the ninth embodiment Flowchart for explaining the operation of the authentication module in the ninth embodiment Functional block diagram of the application authentication system in the ninth embodiment The figure which shows the example which implements Embodiment 9 in an IC card The figure which shows the example which implements Embodiment 9 in an IC card Functional block diagram of the application authentication system in the tenth embodiment Functional block diagram of an application authentication system in the eleventh embodiment Functional block diagram of an application authentication system in the twelfth embodiment Sequence diagram illustrating operation of application authentication system in embodiment 12 Functional block diagram of an application authentication system in the thirteenth embodiment Sequence diagram for explaining the operation of the application authentication system in the thirteenth embodiment Functional block diagram of an application authentication system in the fourteenth embodiment The figure which shows typically the application main body and application definition file of a JAVA (trademark) application Flowchart illustrating processing for authenticating an application using a signature stored in the optional area The TRM access library part of the application authentication system of Embodiment 2 is provided with an application manager and a device driver Functional block diagram of the terminal of the sixteenth embodiment Functional block diagram of the terminal of the seventeenth embodiment Flowchart for explaining a processing flow in the terminal according to the seventeenth embodiment Functional block diagram of an application authentication system in the eighteenth embodiment Functional block diagram of an application authentication system in the nineteenth embodiment Flowchart for explaining the flow of processing of the application authentication system in the nineteenth embodiment Functional block diagram of an application authentication system consisting of three devices The flowchart explaining the flow of operation | movement of a 1st apparatus. The flowchart explaining the flow of operation | movement of a 2nd apparatus. Flowchart for explaining the flow of operation of the third device when the application authentication system is composed of three devices Functional block diagram of an application authentication system consisting of four devices Flowchart for explaining the flow of operation of the third device when the application authentication system is composed of four devices Flowchart for explaining the flow of operation of the fourth device when the application authentication system is composed of four devices Functional block diagram of an application authentication system consisting of five devices Functional block diagram of an application authentication system composed of N + 1 devices Flowchart explaining the flow of operation of the i-th device Flowchart explaining operation flow of (N + 1) -th device Schematic diagram showing that devices are connected using a nested structure 24 is a flowchart for explaining the operation flow of the i-th device according to the twenty-first embodiment.

Explanation of symbols

100 Terminal 101 Authentication Module 102 Download Unit 103 TRM Access Unit

Claims (8)

Download means for downloading the software;
Software authentication means for authenticating the software;
An authentication module for authenticating the software authentication means;
A terminal configured by starting means for starting the software,
The authentication module has a tamper resistant area which is a tamper resistant area for storing information for authenticating the software authenticating means,
The authentication module authenticates the software authentication means using information for authenticating the software authentication means,
The software authentication means authenticated by the authentication module authenticates the software downloaded by the download means,
The activation unit is a terminal that activates the software when authentication of the software by the software authentication unit and authentication of the software authentication unit by the authentication module are successful. Downloading means for downloading software and a signature generated for said software;
Software management means for authenticating the software downloaded by the download means by verifying the signature;
An authentication module for authenticating the software management means;
A terminal configured by starting means for starting the software,
Wherein the authentication module comprises a tamper-resistant region is a region having tamper-resistance for storing the key information used for verification of the signature information for authenticating the software management unit,
The authentication module authenticates the software management means using information for authenticating the software management means;
The software management means authenticated by the authentication module generates a hash of the software downloaded by the download means, sends data including the generated hash and the signature of the software to the authentication module,
The authentication module verifies the received signature using the key information and the received hash,
The activation unit is a terminal that activates the software when authentication of the software by the software management unit and authentication of the software management unit by the authentication module are successful.
  The terminal according to claim 1, wherein the software is downloaded from a server via the download unit.   The terminal according to claim 1, wherein the software is downloaded from the authentication module via the download unit. A software activation method for a terminal comprising: download means for downloading software; software authentication means; an authentication module having a tamper-resistant area that is a tamper-resistant area; and activation means for activating the software. And
The tamper resistant area stores information for authenticating the software authentication means held inside the terminal,
The starting method is as follows:
The authentication module authenticating the software authentication means using information for authenticating the software authentication means;
Software authentication means authenticated by the authentication module authenticates the software downloaded by the download means; authentication of the software authentication means by the authentication module; and authentication of the downloaded software by the software authentication means And a step of starting the software by the starting means. Software and download means for downloading a signature generated for the software, software management means, an authentication module having a tamper-resistant area that is a tamper-resistant storage area, and activation means for starting the software A method for starting software in a terminal to be operated,
The tamper resistant area holds information for authenticating the software management means and key information used for signature verification of the software,
The starting method is as follows:
The authentication module authenticating the software management means using information for authenticating the software management means;
Software management means authenticated by the authentication module generates a hash of the software downloaded by the download means, and transmits data including the generated hash and the signature to the authentication module;
The authentication module verifies the received signature using the key information and the received hash;
Starting the software verified by the tamper resistant module by the software management means;
An activation method comprising: authentication of the software management means by the authentication module; and activation of the software by the activation means when authentication of the downloaded software by the software management means is successful. 6. The activation method according to claim 4, wherein the software is downloaded from a server via the download unit.   6. The activation method according to claim 4, wherein the software is downloaded from the authentication module via the download unit.

Images