KR20060073976A - Method and device for controlling installation of applications using operator root certificates - Google Patents

Abstract

The present invention relates to a method of controlling installation of applications in a communication device (100, 200) and a communication device (100, 200) comprising a secure execution environment (104, 204, 211) to which access is strictly controlled. The idea of the invention is that when an application is loaded into the device, the device verifies that the application originates from a trusted operator. The verification implies that the application must, in a secure manner, ensure the device that it originates from the trusted operator. The device identifies the trusted operator as well as the issuer of a SIM (211) located in the device. Thereafter, the device compares the identity of the trusted operator with the identity of the issuer of the SIM, and if the identity of said trusted operator corresponds to the identity of the issuer of the SIM, the previously verified application is installed in the secure execution environment of the device.

Description

Method and device for controlling installation of applications using operator root certificates}

The present invention relates to an application installation control method in a device having a secure execution environment in which access is controlled, and a communication device having a secure execution environment in which access is controlled.

Various electronic devices, such as mobile communication terminals, portable computers, and PDAs, may include security-related elements such as application programs, cryptographic keys, cryptographic key data material, intermediate cryptographic calculation results, passwords, and means of authenticating externally downloaded data. Requires access These elements and their processing need to be kept secret within the electronic device. It is desirable that the elements and their processing be known only to as few people as possible, since the device could be unfairly compromised if security related elements are known. Access to these kinds of elements can be to assist the intruder to manipulate the terminal with evil intent.

Thus, a secure execution environment is introduced in which processes within the electronic device can access security related elements. Access to, processing within, and exiting the secure execution environment must be carefully controlled. Conventional hardware with such a secure environment is usually included in tamper resistant packaging. For this kind of hardware, you won't be able to perform any scrutiny, instrumentation, or testing that might leak the security-related elements and their processing.

The "Mobile Information Device Profile" (hereinafter referred to as MIDP 2.0) for the Java 2 Micro Edition of Version 2.0 by the JSR 118 Expert Group enables an open third party application development environment for mobile information devices (MIDs). It defines the improved structure and associated application program interfaces (APIs) needed to enable this. Examples of MIDs include cellular phones, two-way pagers, and wireless PDAs. When a device determines that a MID application can be trusted, access is allowed as the device's security policy dictates. Trust may be granted to the signed application by verifying the signer of the application.

Devices that follow MIDP 2.0 assign applications to different protection domains depending on the source of the application. These protection domains are used to distinguish downloaded applications based on the signer of the downloaded application. MIDP 2.0 defines four different domains to be used depending on the signer of the application: a manufacturer domain, an operator domain, a third party domain, and an untrusted domain. Once the application is downloaded to the device, the device configuration determines which domain the application belongs to based on the public key infrastructure (PKI) authentication scheme. Each protection domain in the device holds a root certificate to which the application is authenticated, and the domain associates the root certificate with a series of authorizations. Authorization is specified through the protection domain security policy.

Trusted operator root certificates are used to verify applications from the operator. This operator root certificate is stored at a specific location within the smart card, such as the device's SIM, WIM, or USIM, and there is no explicit limit to the number of operator root certificates that can be stored on the card. However, if an operator root certificate cannot be obtained at a specific location, such as a SIM, then the operator domain must be disabled. In contrast, many operators do not have SIMs provided with operator root certificates, so the operator domain will be unavailable if the operator root certificate is not stored elsewhere on the device. Typically, operator root certificates are stored outside the SIM in the device because many operators do not have SIMs provided with an operator root certificate due to cost issues. Even if an operator's root certificate of a particular operator is stored in the device and applications signed by that operator have reached the device, the signed applications are not in the secure execution environment of the device only if the SIM located on the device has been issued by the particular operator. It is preferred to be installed.

The problem with the prior art related to the construction of the device's operator domains is that if different operator root certificates are stored in the device in the manufacturing state, then the application signed by that particular operator when the operator's root certificate is stored on the device. It can be successfully authenticated and installed within the secure execution environment of this device. It is obvious that this is contrary to the MIDP 2.0 specification, so it does not meet the security scheme of that specification.

Accordingly, it is an object of the present invention to solve the above problem, so that an operator root certificate corresponding to a signed application is issued under the secure execution environment of the device only if it is issued by the same operator that issued the smart card, such as a SIM located on the device. It provides a solution to successfully install a signed application.

This object is achieved by a method of controlling application installation of a communication device comprising a secure execution environment in which access is controlled in accordance with claim 1 and a communication device comprising a secure execution environment in which access is controlled in accordance with claim 10. . Preferred embodiments are defined by the dependent claims.

According to a first aspect of the invention, a method is proposed in which an application is loaded into a communication device. The communication device verifies that the application is from a trusted operator and identifies the issuer of the smart card located at the trusted operator and the communication device. Further, the communication device compares the identity of the trusted operator with the identity of the smart card issuer, and if the identity of the trusted operator corresponds to the identity of the smart card issuer, then the verified application secures the security of the communication device. Install in a runtime environment.

A communication device in accordance with a second aspect of the present invention is provided, which device loads an application into a communication device, verifies that the application is from a trusted operator, and which is located at the trusted operator and the communication device. Identify the issuer of the card and compare the identity of the trusted operator with the identity of the smart card issuer; Means for installing the verified application in the secure execution environment of the communication device if the identity of the trusted operator corresponds to the identity of the smart card issuer.

The basic idea of the invention is that when an application arrives and is loaded into a device such as a mobile communication terminal, a PDA or a portable computer, the device verifies that the application is from a trusted operator. A trusted operator is an operator who may provide an application to the device by the device or the device manufacturer, that is, the operator and the device manufacturer have certified mutual trust. To verify means that the application must ensure in a secure manner that it originates from a trusted operator. The device identifies not only its trusted operator, but also the smart card issuer such as the SIM located within the device. Accordingly, the device compares the identity of the trusted operator with the identity of the smart card issuer, and if the identity of the trusted operator corresponds to the identity of the smart card issuer, then the previously verified application is configured to secure the communication device. Installed in the runtime environment. The present invention provides the advantage that only operator applications loaded on a device that have been verified as originating from a trusted operator will be installed in the device's secure execution environment when the device's SIM card is issued by the same trusted operator. Have This is essential for devices operating in accordance with the MIDP 2.0 specification, because without it, the devices would violate the specification.

According to an embodiment of the invention, the application loaded on the device is signed by a trusted operator. Verification that an application is from a trusted operator is done through a certificate that compares the signed application with an operator certificate that means that the operator is trusted. The signature and authentication of the application is based on the X.509 PKI approach. The operator certificate corresponds to a signed application stored on the device and issued by a trusted operator. This embodiment ensures a high degree of security when installing applications. According to another embodiment of the present invention, the identification of the trusted operator is performed by extracting a first operator identifier identifying the trusted operator from the operator certificate in the device. In addition, the identification of the smart card issuer in the device extracts the issuer, that is, the second operator identifier that identifies the specific operator ID present in the IMSI code from the international mobile subscriber identity (IMSI) code of the smart card. Is performed. This is a simple and easy way to get individual identifiers.

According to another embodiment of the present invention, a mechanism for authenticating a signed application, i.e., checking whether the device SIM follows the installation of a specific operator root certificate and a certified application, includes a microprocessor implemented in the device, and The microprocessor runs a Java implementation. This embodiment is preferred in that it ensures the flexibility of the device. When the operation of the microprocessor, and thus the device, needs to be modified or changed, this can be done by modifying the Java implementation. After all, the hardware of the actual device does not have to be different. The MIDP 2.0 specification also affects the platform on which Java is implemented.

Other features and advantages of the invention will be apparent from the following detailed description and the appended claims when reviewed. Those skilled in the art will appreciate that other features of the present invention may also be added to make embodiments other than the embodiments described below.

The invention will be explained in more detail with reference to the following figures.

1 shows a block diagram of an apparatus structure for supporting data security, to which the present invention may be preferably applied.

Figure 2 shows a block diagram of a device structure for supporting data security, in which a removable smart card is further configured, to which the present invention is preferably applied.

3 illustrates a flow diagram for controlling application installation in a device with a secure execution environment, in accordance with an embodiment of the invention.

4 illustrates a flow diagram for controlling application installation in a device with a secure execution environment, in accordance with another embodiment of the present invention.

A device structure supporting data security conforming to the MIDP 2.0 specification is shown in FIG. Such a system is disclosed in the Applicant's International Patent Application PCT / IB02 / 03216, the contents of which are incorporated herein by reference. Circuitry to support data security is implemented in the form of an Application Specific Integrated Circuit (ASIC) 101. The processing portion of this structure includes a CPU 103 and a digital signal processor (DSP) 102. The ASIC 101 is included in an electronic device 100 such as a mobile communication terminal, a portable computer, a PDA, or the like, and is considered a "brain" of the device 100.

Secure environment 104 includes ROM 105 from which ASIC 101 is booted. This ROM 105 includes boot application software and an operating system. Certain application programs residing within the secure environment 104 take precedence over other application programs. In a mobile communication terminal, where the ASIC 101 may be configured, there will be boot software, which includes the main operation of the terminal. Without this software, the terminal cannot boot into its normal operating mode. By controlling this booting software, it is possible to control the initial operation of each terminal.

The secure environment 104 also includes a RAM 106 for storing data and applications, i. RAM 106 preferably stores smaller sized applications, called protected applications, for performing security-critical operations within secure environment 104, but objects such as cryptographic keys, intermediate cryptographic results and passwords. Can save too. Usually, a method of utilizing protected applications is to have "normal" applications request services from some protected application. New protected applications may be downloaded into the secure environment 104 at any time, except where such applications reside in ROM. Secure environment 104 software controls the download and execution of protected applications. Only signed protected applications are allowed to run. Protected applications may access any resources in the secure environment 104 and may communicate with normal applications to provide security services.

In an embodiment of the invention, the secure environment software includes a Java implementation when Java is a language used under the MIDP 2.0 specification. In order for the device to function satisfactorily outside the scope of MIDP 2.0, any suitable language may be used to implement the requested functionality.

Within the secure environment 104, a fuse memory 107 is included that includes a unique random number that is generated and programmed into the ASIC 101 during manufacture. The random number is used as the identity of the particular ASIC 101 and further used to derive keys for cryptographic operations. In addition, the storage circuit access control means is configured in the security environment 104 in the form of a security control register. The purpose of the security control register is to allow the CPU 103 to access the secure environment 104 or prevent the CPU 103 from accessing the secure environment 104 in accordance with the mode setting of the register. The operating mode of the CPU 103 can be set in a register by the application software, so that the configuration does not need to depend on external signals. From a security point of view, this is desirable because the processor mode setting can also be controlled by controlling the application software. There may be an external signal (not shown) connected to the ASIC 101, which makes it possible to set the security control register. By using an external signal, the mode change can be easily and quickly executed, which may be advantageous for the test environment. It is also possible to combine these two mode setting means, that is, a combination of application software and external signals.

This configuration further includes a standard bridge circuit 109 for limiting data visibility on the bus 108. This configuration will be enclosed in a tamper resistant package. This kind of hardware is not capable of performing inspections, measurements, and tests that could result in the disclosure of related components and the security concerns associated with their processing. DSP 102 accesses other peripherals 110 such as direct memory access (DMA) units, RAM, flash memory, and additional processors that may be provided outside ASIC 101.

Another embodiment of such a device configuration for supporting data security is shown in FIG. 2, where the same reference numerals represent the same components described with respect to FIG. Compared with the configuration shown in FIG. 1, the difference in the configuration of FIG. 2 is that the electronic device 200 includes a removable smart card 211 such as a SIM, which is also considered a security environment. For security purposes, mobile terminal 200 and smart card 211 store digital certificates issued by trusted certificate authorities (CAs). The certificates are used to assure the parties communicating with the mobile terminal 200 and / or the smart card 211 that the holder of a particular certificate has been authenticated by the trusted CA. The CA signs the certificate, and the certificate holder must have a public key that corresponds to the CA's private key to verify that the certificate signed by the CA is valid. In this case, different CAs must perform some communication with each other, such as exchanging their public keys. Certificates are well known to those skilled in the art, and the well-known standard certificates are those contained in CCITT Recommendation X.509.

According to the MIDP 2.0 specification, certificates can be issued by various CAs. That is, trusted manufacturers issue manufacturer root certificates, trusted operators issue operator root certificates, and trusted third parties issue third-party root certificates. Since these certificates are security related components, the certificates themselves are stored in the security environment, and security related processing for them is also performed in the security environment. An untrusted application refers to an application that is not trusted by the device because it is not provided with a trusted identifier or similar signature. A careful approach should be taken when running untrusted applications. They must run outside the secure execution environment, and they cannot be given full access to secure elements. As one alternative, they may not be allowed to exchange information through the secure environment interface. As another alternative, where rigorous procedures are in place, unreliable applications may not be allowed to be installed in the device at all.

A method for controlling installation of applications in a secure execution environment of a device according to an embodiment of the present invention is shown in FIG. An application is loaded into the device with some type of assurance that the application is actually from a trusted operator, that is, a protected application (step 301). The CPU of the device then interprets the guarantee and verifies that the application is from a trusted operator (step 302). When the application is verified, the CPU identifies the trusted operator from which the application occurred (step 303). The method continues with step 304 where a smart card issuer, such as a SIM, located in a communication device is identified. The CPU compares the identity of the trusted operator with the identity of the SIM issuer to compare the correspondence between the two entities (step 305). If the identity of the trusted operator matches the identity of the SIM issuer, that is, if the SIM issuer also issued the application, then the verified application is installed in the secure execution environment of the device (step 306). However, in step 306, if the identity of the trusted operator does not match the identity of the SIM issuer, that is, if the SIM issuer has not issued the verified application, the verified application is not installed in the secure execution environment of the device. Will not.

In step 306, because the verified application has been authenticated, the application may be installed outside the secure execution environment of the device even if the issuer of the SIM did not issue the application. As such, the application will be given limited access to security related elements, as described above. Alternatively, when the identity of the trusted operator does not match the identity of the SIM issuer, the verified application may not be installed at all on the device.

According to another embodiment of the invention, a method of controlling application installation in a secure execution environment of a device is shown in FIG. The signed application, that is, the protected application, is loaded into the device (step 401). The device's CPU then performs an authentication that compares the signed application with the operator root certificate stored in the device (step 402). This operator root certificate is issued by a trusted operator who is the same operator who signed the application. Thus, the certificate includes a public key corresponding to the secret key that was used when the trusted operator signed the application. In the description associated with FIG. 4, it should be noted that it is assumed that (i) the application is actually signed, and (ii) the device has an operator root certificate corresponding to the signed application. If the application is unsigned, that is, the application is not trusted, the method will end after step 402 because no application authentication is possible. Optionally, as previously described, untrusted applications can be installed outside the secure execution environment of the device. Even if the device does not have an operator root certificate, the method will again end after step 402 because the authentication of the application is not possible.

When the signed application is authenticated against the operator root certificate, the CPU extracts the first operator identifier from the operator certificate (step 403). This first identifier identifies the trusted operator who issued the operator root certificate. The method proceeds to step 404 where a second operator identifier is extracted from the IMSI code of the SIM located in the device. This second identifier identifies the SIM issuer. The CPU compares the first operator identifier with the second operator identifier and checks for correspondence between the two identifiers (step 405). If the first operator ID matches the second operator ID, that is, if the SIM issuer also signed the application, the authenticated application is installed in the secure execution environment of the device (step 406). However, if at step 406 the first operator ID does not match the second operator ID, that is, the SIM issuer has not signed the application, the authenticated application will not be installed in the secure execution environment of the device. In step 406, since the signed application has been authenticated, it should be appreciated that the application can be installed outside the secure execution environment of the device even if the SIM issuer has not signed the application. Thus, as discussed above, the application will be given limited access to security related elements. Again, if the identity of the trusted operator does not match the identity of the SIM issuer, then a verified application may not be installed on the device at all.

While the present invention has been described with reference to specific exemplary embodiments, those skilled in the art will recognize that there may be many different variations, modifications, and similar thereto. Accordingly, the foregoing embodiments are not intended to limit the scope of the invention as defined by the appended claims.

Claims (18)

A method of controlling application installation in a communication device (100, 200) having a secure execution environment (104, 204, 211) in which access is controlled, Loading (301) the application into the communication device; Verifying (302) at the communication device whether the application originated from a trusted operator; At a communication device, identifying (303) the trusted operator; Identifying, at the communication device, an issuer of the smart card 211 located at the communication device (304); At a communication device, comparing (305) the identity of the trusted operator with the identity of the smart card issuer; And If the identity of the trusted operator matches the smart card issuer identity, installing (306) the verified application in a secure execution environment of a communication device. The method of claim 1, wherein the application loaded 401 into the communication device 100, 200 is signed by the trusted operator and the step of verifying that the application is from a trusted operator comprises: And comparing (402) the signed application with an operator certificate stored in a communication device and issued by the trusted operator, the operator certificate corresponding to the signed application. . The method of claim 2, wherein identifying the trusted operator comprises: Extracting (403) a first operator identifier identifying the trusted operator from the operator certificate. According to any one of claims 1 to 3, wherein the step of identifying the issuer of the smart card 211 located in the communication device (100, 200), And extracting (404) a second operator identifier identifying the operator who issued the smart card from the identity code of the smart card. 5. The method of claim 4, wherein said identity code comprises an IMSI code. The method according to any one of claims 1 to 5, wherein the steps are performed by microprocessors (103, 203) provided in a communication device and executing a Java implementation. . The method according to any one of claims 1 to 6, wherein the communication device (100, 200) is a mobile communication terminal. The method according to any one of claims 1 to 7, wherein the smart card (211) is a SIM, a WIM, or a USIM. 9. The communication device (100, 200) according to any one of the preceding claims, wherein the communication device (100, 200) comprises circuits (101, 201) for providing data security, wherein the circuits (101, 201) are at least one. A processor (103, 203) and at least one storage circuit (104, 204, 211), the circuit (101, 201), At least one storage area in said storage circuitry (104, 204, 211) in which protected data relating to communication device security is located; Mode setting means for changing the processor operating mode to set the processor to one of at least two different operating modes; Storage circuit access control means for causing the processor to access the storage area in which the protected data is located when a first processor operating mode is set; And Storage circuit access control means for preventing the processor from accessing the storage area in which the protected data is located when a second processor operating mode is set. A communication device (100, 200) having a secure execution environment (104, 204, 211) in which access is strictly controlled, Load the application into the communication device, verify that the application is from a trusted operator, identify the trusted operator and the issuer of the smart card 211 located on the communication device, and identify the trusted operator's identity. Means (103, 203) for comparing the identity of the smart card issuer and installing the verified application in the secure execution environment of the communication device if the identity of the trusted operator matches the identity of the smart card issuer. Communication device characterized in that. The method of claim 10, wherein the application loaded into the communication device is signed by the trusted operator, The means (103, 203) is further configured to authenticate the signed application compared to an operator certificate stored on a communication device and issued by the trusted operator and corresponding to the signed application. Device. 12. A communications device according to claim 11, wherein said means (103, 203) is further configured to extract, from said operator certificate, a first operator identifier identifying said trusted operator. 13. The apparatus of any one of claims 10 to 12, wherein the means (103, 203) are further configured to extract, from an identity code of the smart card, a second operator identifier that identifies the operator that issued the smart card. Communication device characterized in that. 14. The communications device of claim 13, wherein said identity code comprises an IMSI code. 15. A communication device as claimed in any of claims 10 to 14, wherein said means (103, 203) are implemented by a microprocessor executing a Java implementation. The communication device according to any one of claims 10 to 15, wherein said communication device is a mobile communication terminal. 17. A communications device according to any of claims 10 to 16, wherein said smart card (211) is a SIM, WIM, or USIM. The method according to any one of claims 10 to 17, The communication device 100, 200 has circuits 101, 201 for providing data security, wherein the circuits 101, 201 have at least one processor 103, 203 and at least one storage circuit 104. , 204, 211, wherein the circuits 101, 201, At least one storage area in said storage circuitry (104, 204, 211) in which protected data relating to communication device security is located; Mode setting means for changing the processor operating mode to set the processor to one of at least two different operating modes; Storage circuit access control means for causing the processor to access the storage area in which the protected data is located when a first processor operating mode is set; And Storage circuit access control means for preventing the processor from accessing the storage area in which the protected data is located when a second processor operating mode is set.

Images