JP4417952B2 - Method and system for performing tests on devices and devices - Google Patents

Abstract

The present invention relates to a method and a system for performing testing in a device ( 1 ), in which at least one program ( 110, 112 ) is loaded and at least one item of mode data relating to the program is determined. Furthermore, at least one key ( 111 ) is generated for use in said program. In the method, at least two different security levels are determined for the keys to be used in the device ( 1 ). In the method, said security level determined for the key and at least one mode data relating to the program are examined, and on the basis of the examination, it is decided if said key is available for use in the mode indicated in the mode data of the program. The invention also relates to a device, a mobile communication device and a storage medium.

Description

  The present invention relates to a method for testing in a device, wherein at least one program is loaded into the device, at least one item of mode data associated with the program is determined, and at least one key used in the program is formed. Is done. The present invention also relates to a system for testing in a device, in which at least one program is loaded, and at least one item of mode data associated with the program is determined in the system. , At least one key used in the program is provided in the system. The present invention also relates to a device including at least one processor for executing a program loaded on the device, wherein at least one item of mode data related to the program is determined by the device and used in the program. At least one key is provided on the device. Furthermore, the present invention relates to storage means, wherein a set of program commands executable on a machine is stored in a device for testing, on which at least one program is loaded, The device is configured to be executed by the device, and at least one item of mode data is determined for the program, and at least one key used in the program is formed.

  There are known applications that can be used on the device after access to the application is obtained. In prior art systems, for example, a user can obtain such access rights by a method such as loading an application onto a device via a data network. In this connection, the user provides his / her contact data and the application provider sends the information necessary to validate the access rights, for example by mail. The user can conveniently pay for the application's access rights upon loading by providing his credit card number. Therefore, payment is charged through a credit card company. On the other hand, the payment may be made by cash on delivery, and the user pays when requesting access right data to be mailed. The user can enter the received access right data and then start using the application. Such data can also include, for example, a user ID and password, a registration code, and the like. The access rights may be beneficial to include the user's device identification information or other personalization information, thereby preventing different users from using the same application with the access rights of one user.

  As the use of electronic devices has diversified, it has become necessary to protect certain functions of electronic devices, such as by accessing certain functions only through authorized programs. Yes. For example, mobile phones have evolved into communication devices suitable for data processing for various purposes, and programs other than those necessary for making calls can also be executed. New programs can later be installed on these devices, and already installed programs can be updated to new versions. However, for example, the function of the mobile phone requires specific security. In this security, for example, any program can determine the information stored in the SIM card or call the mobile communication network using fake identification data so that another mobile subscriber is charged for the call. It's not that you can spend a lot of time. Similarly, in devices that include functions related to money transactions, such as the use of the device as a means of payment, a defective or fraudulent program may affect the money transaction or be stored, for example, on the device It is necessary to ensure safety so that the amount data cannot be changed. In addition, using some digitally recorded information on the device may involve limited access rights. For example, a user subscribes to music, software or other digital recording information and installs them on his device. In some cases, access rights to these digital record information are limited. For example, the digital record information can be installed only on a predetermined device, the use frequency or the use period of the digital record information may be limited, or, for example, payment is made each time the digital record information is used. You may have to do that. With respect to the situation described above, the device software comprises a protected part, which performs the necessary security checks and functions related to encoding and decoding. In addition, these devices typically include an operating system that is used to control the functional blocks of the device and to transmit data between different blocks. An interface is implemented to transmit information between the operating system and the protected part. For example, an encrypted message received at the device is forwarded to a protected part for decryption. The decrypted message can then be transferred to the operating system for further processing.

  The program executed on the device can be divided into various access right levels. The program is divided into, for example, a program that does not have access to any function that requires safety and a program that may process at least some of the functions that require safety. can do. Thus, when a program starts, the operating system or protected part checks the program's access rights and prevents or allows the program to access certain functions. The operation for determining the access right may be based on the origin of the program, for example. In this case, for example, a wider range of access rights can be given to a program created by a device manufacturer than a program created by a third party. On the other hand, for example, a device manufacturer can give a wider range of authority (high reliability) to a specific program manufacturer than others. In this case, more reliable access can be given to a program of a highly reliable program manufacturer than a program of a manufacturer whose reliability level is low or undefined.

  At present, keys for various purposes are stored in many devices. Among other things, the key can be used for information verification, access rights checking, software authentication, and information encryption and decryption. Such a key may be stored on a portion of the device that is not accessible to general software, or the key may be stored in an encrypted form. In this case, the program using the key includes another key for decrypting the key. Therefore, this second key must be stored in a memory that is not accessible to general programs.

  One of the problems with the devices mentioned above is that when developing a new program or when further developing an existing program, it must be possible to test the program in the most reliable environment possible. It is. Also, the program being tested must have the necessary keys available. A tool used to test a program such as a debugger program and / or a debugger device can inspect areas of the device that contain information that is kept secret, such as the keys described above. Some of this information may not be as harmful if disclosed. However, some may contain keys that need to be made inaccessible, even for testing purposes. These keys are related to, for example, various payment applications, management of access rights to digital record information (DRM, digital rights management), transmission of confidential information in encrypted form, and other similar functions. Is.

  In some prior art arrangements, at least all important keys that need to be kept secret are replaced with test keys that are deleted after use. In such a method, a program can be tested by using these test keys. However, after the test is completed, it is necessary to replace the test key with a new key on the device.

  It is an object of the present invention to provide an improved method and system for testing programs in a reliable hardware environment. The present invention is based on the idea of defining at least two different security levels for the keys used in the device, one of these security levels being selected for each key. The first security level is preferably a low security level, and therefore the second security level is a high security level. In the configuration of the present invention, the first security level key can also be used for testing purposes, but the second security level key is replaced with a test key for testing. To be precise, the method according to the invention mainly comprises at least two different security levels defined for the key used in the device, and at least of the security level defined for the key and the mode data associated with the program. An item is checked, and based on the check, it is determined whether the key can be used in the mode indicated in the mode data of the program. The system according to the invention is mainly a test in which at least two different security levels are defined for the keys used in the device, and the system checks the security level and at least one item of mode data associated with the program. And means for determining whether the key can be used in the mode indicated in the mode data of the program. The device according to the invention mainly comprises at least two different security levels defined for the keys used in the device, and the device checks the security level and at least one item of mode data associated with the program. And determining means for determining whether or not the key can be used in the mode indicated in the mode data of the program. Furthermore, the storage means according to the invention are mainly defined for a key used in the device by at least two different security levels, the storage means further relating to the security level and program determined for said key. A program command for checking at least one item of mode data; and a program command for determining whether the key can be used in a mode indicated in the mode data of the program based on the check. And

  The present invention presents advantages over prior art solutions. With the system according to the invention, it is possible to test the program in ambient conditions and environments in accordance with the actual usage situation as much as possible. Therefore, the possibility of detecting errors is higher than in prior art solutions and the reliability of the completed program is also higher. In addition, since the important key is not used in the test state, the security of the important key is ensured. On the other hand, since some keys are used for testing, the need for test keys is lower than with prior art solutions.

  Hereinafter, the present invention will be described in detail with reference to the accompanying drawings.

  In the following, the operation of the method according to an advantageous embodiment of the invention will be explained using the device of FIG. 3a as an example. The device 1 includes one or more processors 2 that execute programs, perform the functions of the device operating system, and control the operation of different functional blocks of the device. The device also includes a protected block 3 that handles most of the functions as follows. Execution of the function is a function related to an operation for keeping secret such as processing of a secret key. An example of the configuration of this protected block is shown in FIG. 3b, which will be described in detail below. The device also includes, for example, a memory 4 that stores software and information necessary for the operation of the device. Device 1 also includes a transmitter 5 and a receiver 6 so that device 1 can communicate with a communication network. The transmitter 5 and the receiver 6 are preferably for wireless communication. In this case, the device 1 can be used for communication with a wireless communication network such as a mobile communication network (not shown). The device 1 can also include local communication means 7 for communicating with other devices (not shown) around the device 1, for example. These local communication means 7 include a transceiver based on low power wireless transmission such as a Bluetooth (registered trademark) transceiver. Advantageously, the device operating system 8 includes a display 8.2, a keypad 8.1, an earphone / speaker 8.3, and a microphone 8.4. It will be appreciated that the device may also include more than one user interface, so one user interface may be configured primarily for data processing functions, for example, and another user interface may be You may be comprised mainly for a mobile telephone function. An example of such a device is the Nokia 9210i Communicator®. In addition, the device 1 advantageously includes a user identification card 9 such as a SIM (Subscriber Identity Module) and / or USIM (UMTS Subscriber Identity Module), which allows the device 1 to be turned on. The user is identified and the characteristics of the function of the mobile station granted to the user are determined.

  The protected block 3 according to FIG. 3b preferably comprises a read only memory 3.1, a random access memory 3.2, a processor 3.3, a bus connection 3.4, and a test connection 3.5. This protected block is preferably formed as a single integrated circuit in such a way that the internal connections of the protected block cannot be accessed from the outside. It is therefore almost impossible to find the signal transferred in this protected block. The read-only memory 3.1 contains stored information and software that do not need to be changed after the device 1 is manufactured. Read-only memory 3.1, for example, protected block identification information (chip ID), random numbers used to generate several keys, management function to load information, management for protected memory Includes functions, device controllers, etc. The protected block random access memory 3.2 is used, for example, to store the protected software during its execution, and also for temporary storage of information that is required and confidential during the execution of the software. It is also used for memory. The function of the protected block processor 3.3 is, for example, execution of protected software and control of the bus connection 3.4. Information can be transferred between the protected block 3 and the rest of the device 1 via the bus connection 3.4. If no information needs to be transferred over the interface, the processor 3.3 preferably sets the bus connection 3.4 in such a way that the internal signals of the protected block are not transferred to the bus connection. Therefore, even if the signal is monitored by the interface, the internal operation of the protected block cannot be determined.

  On the other hand, it will also be apparent that the device 1 can be implemented such that the functions of the protected block 3 as well as other functions are implemented in one processor. In this case, the protected block read-only memory 3.1, the random access memory 3.2, and the bus connection 3.4 are implemented as internal blocks of the processor and the processor performs the functions of the protected block. The internal bus signals can be prevented from being monitored via the connection pins of the processor.

  Furthermore, the protected block 3 can be implemented in a smart card 9 that can be connected to the device 1 such as a SIM card or in another suitable location that connects to the device 1.

  FIG. 2 simply shows the configuration of the software execution environment of the device 1. This configuration includes a protected environment 10 and an unprotected environment 11. The protected environment 10 is implemented in the protected block 3 of the device 1. Correspondingly, the unprotected environment 11 is implemented in other functional blocks of the device such as the processor 2 and the memory 4. The protected environment consists of a read-only memory 3.1, a random access memory 3.2, and a protected application interface (API) 10.1 provided therebetween. A protected application is related to a program that is intended to be executed in a protected environment in such a way that the operation of the program cannot be externally monitored. Such programs are programs that require a predetermined security level, such as some programs related to payment transactions and programs for encrypting / decrypting information processed in a format in which the secret encryption key is not encrypted. is there.

  Three connections 12.1, 12.2, 12.3 are formed between the protected environment 10 and the unprotected environment 11 and are hard-wired by the interface 3.4 bus (not shown) described above. It is preferably implemented on the wear level. The first connection 12.1 is for subroutine calls from a protected environment, where the called subroutine is placed in an unprotected environment. The called subroutines include, for example, operating system services 11.1 such as memory allocation and storage of protected (encrypted) data in the memory 4 outside the protected block. The second connection 12.2 is for an application interface from the unprotected environment 11 to the protected environment 10. For example, this second connection 12.2 can be applied to use services in a protected environment when there is no need to transfer confidential information outside the protected environment. The unprotected environment preferably includes operating system drivers (OS drivers) 11.2 through which the services can be invoked. As an example of such a service, the verification of a digital signature in which a digital signature to be verified and, if necessary, a public key is transferred from an unprotected environment 11 to a protected environment 10 will be described. This protected environment includes a program that performs the verification. The third connection 12.3 between the protected environment 10 and the unprotected environment 11 is for communication between a general (unprotected) application and a protected application.

  FIG. 1 a shows a simplified processing hierarchy of keys in the device 1. It will be apparent, however, that this is only a possible embodiment that can be utilized in connection with the present invention. In the key processing hierarchy of FIG. 1 a, there are a plurality of public keys that constitute a so-called public key header 101 of the device 1. The public key header 101 includes information about the public key of the device 1 and public keys 102 to 105. Here, the public key is, for example, a device unique key 102 (chip HW public key), a protected software signature key 103 (secure mode public key), a software signature key 104 (OEM1 software signature key), and a software test signature. Key 105 (OEM2R & D control key) is included. While the device 1 is in use, the public key can be read from the memory 4 and stored in the random access memory 3.2 in a protected environment. In connection with storage, the data is preferably verified by the device unique key 102. On the other hand, when the public key is required, the public key can be read from the memory 4 into the random access memory 3.2 in an environment protected. Even in this case, the data must be verified.

  Further, the hash value 106 calculated based on the device unique key 102, the chip unique internal key 107, and the authentication key 108 are stored in a circuit including the protected block. The hash value 106, the chip-specific internal key 107, and the authentication key 108 are preferably stored in the circuit at the stage of manufacturing the circuit. In this case, these cannot be changed later. The device unique key 102 is preferably stored in the circuit in connection with the manufacture of the circuit. In this case, it cannot be changed after storage. Further, it is preferable to store the test key in the device. A site R & D control public key 109 is used in connection with the test. This will be described in detail herein below.

  In addition to the keys shown above, FIG. 1a also shows other blocks related to device protection. The device includes programs 110 that are intended to be executed in a protected environment, and the authenticity check of these programs is performed using these protected software signing keys 103. This can be done by checking the digital signature stored in association with the. In addition, public keys 111 for using these programs internally may be stored in these programs. In this case, these public keys are stored in a protected environment in connection with loading of the programs. Load to random access memory 3.2. The device further includes a program 112 for execution in an unprotected environment, and digitally signs these programs using a private key corresponding to the software signature key 104. Test environment settings 113 include information about keys 115 and 116 that can be used in connection with the test. The test environment setting is digitally signed using a private key corresponding to the site R & D control public key 109. In addition, each device identification information 114 included in the device is digitally signed using a secret key corresponding to the device unique key 102.

  In the diagram of FIG. 1a, solid arrows indicate keys (trust check chains) used to verify various data. For example, the device unique key is used to verify the protected software signing key 103, the software signing key 104, and the software test signing key 105. Correspondingly, the hash value 106 can be used to verify the validity (consistency) of the device unique key 102.

  The public key header 101 is digitally signed so that data included in the header can be authenticated.

  The data that can be checked using the public key described above is preferably signed in a known manner using a private key corresponding to the public key at the manufacturing stage of the device 1 and / or program. If the public key corresponding to the private key is used only for authentication and not for signature or data encryption, the private key need not be stored on the device or the program itself.

FIG. 1b shows the key hierarchy of device 1 for symmetric keys. Symmetric keys are used based on the fact that the same key is used to encrypt or sign data and the signature is decrypted or verified in a known manner. Therefore, such symmetric keys should not be disclosed to outsiders. The authentication key 108 can be used, for example, to authenticate a circuit in a protected application 110 for use only with a given device 1. The circuit specific internal key 107 is preferably a circuit specific random number, and the key is used to ensure reliability and integrity when information is stored outside of the protected environment. To do. It is assumed that the circuit specific internal key 107 is formed based on the information about the circuit, and is a different key for different circuits. Each of the programs 110 that can be executed in a protected environment can also be accompanied by one or more application-specific keys 119 for use only within the program. In addition, an inter-application key 120 can be formed for a program, and the key is used for communication between two programs. Such an inter-application key is stored in each program that is to use the key.

  Each program preferably includes at least an application creator ID and an application ID in order to identify each application. These pieces of identification information are preferably stored in the application as hash values calculated based on the identification information using a secret key. In this method, the authenticity of the hash value can be checked with the public key corresponding to the secret key.

  The keys 119 and 120 usable for the program can be used for data encryption and decryption, data digital signature, digital signature authenticity check, and the like. The program can form a plurality of keys from one symmetric basic key in such a way that even if the generated key is disclosed, the secret of the basic key is not compromised. Thus, it is beneficial for a program to generate different keys for different purposes without using the same key for different purposes.

  In the solution according to the invention, the application-specific key 119 and the inter-application key 120 comprise information indicating the availability of the key for software testing, ie a security level. This security level may be program specific so that all keys used by the program are processed in the same way, or this information may be different in different ways, even if different keys are within the same program. It may be key specific so that it can be processed. In a solution according to an advantageous embodiment of the invention, a first security level and a second security level are determined, the first security level is a low security level and the second security level is a high security level. . The security level set for a key that is intended to be extremely reliable and kept completely secret is a high security level, and therefore this key cannot be used in connection with testing. Such a key has different values in the normal mode and the test mode. In other cases, the security level is set to the first security level. Such a key has the same value in both normal mode and test mode. The security level can be indicated by a 1-bit value, for example, and thus the value can be 0 or 1. The compiler of the program can store this security level in the program, for the entire program, or separately for each key.

  The use of keys associated with software testing is described below. In connection with powering on the device 1, it is preferable to verify the authenticity of the operating system stored and started in the device 1. This operation is performed, for example, by checking the digital signature stored in the operating system with the software signature key 104. If the result of the check indicates that the operating system is authentic, the operating system can be started. At this time, the device 1 is informed of the transition to the test mode. The tester preferably uses the interface 8 of the device 1 to indicate which program is to be started for testing. Based on this information, the program installation service checks whether or not an access right is granted to this program. When the access right is not granted, the program installation service informs the access right acquisition service that the access right needs to be acquired. The access right is acquired by the following method, for example. The device 1 sends a message containing information about the device 1 on which the test is performed and information about the program to which the access right is granted to a device manufacturer's server (not shown) or the like. The device information includes at least device identification information data such as a device ID, as well as information on the manufacturer of the program to be tested. In the server of the device manufacturer, the device ID from the received message is checked, and information on the device 1 and information on the manufacturer of the program are retrieved from the database of the server based on this ID. This information includes, for example, the device unique key 102, and the data can be encrypted with this key in a format that can be decrypted only by the device 1. The data of the manufacturer of the program includes information indicating what kind of access right can be given to the program of the manufacturer. These rights may be determined, for example, by agreement between the device manufacturer and the program manufacturer.

  If the device 1 can be authorized to test the program, a message granting access rights is transmitted to the device 1. The device 1 checks the received access right grant message, and verifies the authenticity and integrity of the device as necessary. It is useful that the access right grant message includes at least the following information. This is an access right parameter (access right vector) including information on a function permitted to be used in the program. These functions include, for example, functions related to handling of the SIM card, specific operating system functions, user interface functions, or the like. Further, the access right grant message includes identification information of a program to which the message relates. Thus, the software load program 10.2 can assign possible access rights extensions / restrictions to the correct program. At this stage, the access right granted to the program is recognized, whereby the program can be started, and the function of the program can be controlled within the determined access right.

  When performing the test, for example, the test connection 3.5 of the protected block is activated, at which time the connection signal (not shown) of the test connection can be used to find the signal inside the protected block 3. As a result, the procedure of the program executed in the protected block 3 can be traced and the program can be debugged. Preferably, at least two usable test modes are provided. One is a normal software test mode, and the other is a protected software test mode. However, before operating the test mode, it is first checked whether the device 1 is allowed to perform a test. This can be seen by checking information about the test modes that can be used included in the test environment settings 113.

  In the normal software test mode, the program signing key 104 and the corresponding test key 116 are used. In the protected software test mode, the corresponding test key 115 is used instead of the key 103 for signing the protected software. These test keys 115 and 116 are stored in the test environment setting 113, for example.

  In starting the test of the program, the following steps are adopted in the method according to an advantageous embodiment of the invention. The program to be tested is preferably stored in the normal memory 4 of the device. The program is also provided with a digital signature. A private key corresponding to the test keys 115 and 116 described above is used for the digital signature of the program to be tested.

  When device 1 is in test mode, loading of the program to protected block random access memory 3.2 is initiated. Load program 10.2 is stored in protected block read-only memory 3.1. The load program 10.2 verifies the authenticity of the loaded program with the software test signing key 105 before the program starts. In addition, the security level of the key associated with the program is checked. If the security level indicates that one key cannot be used for the test, the test key corresponding to this key is set so that it can be used by the program during the test. However, if the security level indicates that this key can also be used for testing, this key can also be used for testing as usual.

  In a configuration of the type described above, the tester cannot find the contents of the key having a second value, ie a security level set to a high security level. This is because these keys are not used in the test state, and test keys are used instead.

  In an actual application, there can be various ways of implementing the test function. For example, a normal mode and a test mode can be defined for the device. Accordingly, in the test mode, all programs operate in the test mode, and all important keys are replaced with corresponding test keys. In this embodiment, it is preferable to transmit information about the test mode to all programs that need to consider keeping the key secret. These programs can replace the secret key with a test key.

  The test function can also be implemented in a program-specific manner, preferably setting only one or more programs to be tested at this time to the test mode. In this case, other programs can operate as usual. As a result, in this embodiment, the test of the program does not affect the other programs, and the device 1 can be used as required as required except that the test is being performed. In practical terms, such a program-specific test function can be implemented, for example, by the following method. The protected kernel of the operating system or the like checks whether it is allowed to test the program under test on the device 1. An important part of the operation of this kernel or the like is not found by the test equipment even in the test state. If testing is allowed, the kernel sets the program to be tested to test mode. Correspondingly, after testing, the kernel can either set the program to normal mode or terminate the program.

  With the program-specific test options described above, it may be necessary to inform other programs about the program in test mode. This is necessary when it cannot be guaranteed that the secret key is kept secret in the test state. Therefore, a program in the normal mode can decide whether to replace this key with a test key.

  The test function can also be implemented so that the program is in the test mode as long as the normal access rights to the program are received or set at the device 1.

  The method according to the invention can be implemented largely by software. In this case, a set of program commands is generated to perform the functions of this method. These program commands can be stored in a storage means such as the memory 3.1, the memory 4, a CD-ROM, or a digital general purpose disk by a known method.

  Obviously, the invention is not limited to the embodiments presented above but may be varied within the scope of the appended claims.

It is a figure which shows the processing hierarchy of the key of a device simply. It is a figure which shows the processing hierarchy of the key of a device simply. FIG. 3 schematically illustrates the configuration of an execution environment for software implemented on a device according to an advantageous embodiment of the invention. FIG. 2 is a schematic block diagram of a device according to a preferred embodiment of the present invention. FIG. 5 is a schematic block diagram of a protected block of a device according to an advantageous embodiment of the invention.

Claims (12)

A method for testing the device (1), at least one program (110, 112) is loaded the the device (1), at least one of the keys used by the program (111) stored in said device In the method in which the processor of the device executes the program , and the mode of the program is set to the test mode or the normal mode, the processor of the device further executes the program,
Security level against the key to use in the device (1) or a high security level, it is determined whether a low security level,
A mode of the security level and the program that has been determined for the key is collated,
Based on collating, characterized in that the key is determined whether used mode of the program, further
A method of setting a test key to be usable during a test when it is determined that the key cannot be used in the mode of the program . The security level, characterized in that it is set to the same for all keys to be used in the program, The method of claim 1. The method according to claim 1 , wherein the security level is set independently for each key used in the program. Wherein the key security level Ru is determined, characterized in that it is a key for use within the system, method according to any one of claims 1 to 3. At least one of the key security level Ru is determined, characterized in that a key for use in two programs communicate with each other, the method according to any one of claims 1 4 . Said device (1) having at least a normal mode and a test mode, the program is characterized in that it operates in the device mode, the method according to any one of claims 1-5. A system for testing in a device (1), is configured to have at least one program (110, 112) is loaded, the mode of the program is set to the test mode or the normal mode, in the program in a system in which at least one key to be used (111) is stored in said system,
Said device (1) security level against the key used is whether the high level of security, or low security level is determined, the system comprising
And matching means (3.3) to match with the determined the security level and mode of said program to said key,
Based on collating, the key is characterized in that it comprises a determining means (119, 120) to determine if it can be used with the mode of the program, further
A system, wherein when it is determined that the key cannot be used in the mode of the program, the test key is set to be usable during the test . The system according to claim 7 , wherein the security level is set to be the same for all keys used in the program. 8. The system according to claim 7 , wherein the security level is set independently for each key used in the program. A device (1) comprising at least one processor (2, 3.3) for testing a program (110, 112) loaded in the device , wherein the mode of the program is set to a test mode or a normal mode is configured to be, in the device in which at least one key used (111) is stored (1) in said program (110, 112),
Security level against the key used in the device (1) or a high security level, it is determined whether a low security level, the device (1),
And matching means (3.3) to match with the determined the security level and mode of said program to said key,
Based on collating, the key is characterized in that it comprises a determining means (119, 120) to determine if it can be used with the mode of the program, further
A device, wherein when it is determined that the key cannot be used in the program mode, the test key is set to be usable during the test . Device according to claim 10 , characterized in that said device (1) comprises mobile communication means (5, 6). A computer-readable storage medium storing a machine- executable program for executing a test in the device (1), wherein at least one program (110, 112) is loaded and at least one key used in the program (111) is stored, by executing the program in the processor (2) of the device, in a computer-readable storage medium which mode of the program is set to the test mode or the normal mode, the said program device By further executing in the processor (2) of
Security level against the key used in the device (1) or a high security level, it is determined whether a low security level,
Collating the mode of the security level and the program that has been determined for the key,
Based on collating the key features and this determines whether used mode of the program, further
A computer-readable storage medium , wherein when it is determined that the key cannot be used in the program mode, the test key is set to be usable during the test .

Images