JP2018088574A - Method for protecting program image - Google Patents

Abstract

PROBLEM TO BE SOLVED: To prevent alteration of a program including updatable parameters.SOLUTION: A first storage, where writing by a user is prohibited, stores at least one reference hash value, and a second storage, where writing by a user is permitted, stores a current program image. The method acquires update data, generates a new program image by inputting the current program image and the update data, executes generation of at least one value of a predetermined length, executes comparison of at least one current hash value calculated by inputting the at least one value the new program image, and the at least one reference hash value, and overwrites the current program image in the second storage with the data coupling the value of the predetermined length, used for calculation of the current hash value matching the reference hash value, and the new program image.SELECTED DRAWING: Figure 9

Description

  The present invention relates to a technique for preventing unauthorized alteration of a program installed in a device.

  With the spread of mobile terminals and the advancement of Web services, the types of services are diversifying. In particular, in recent years, services such as mobile payments, where services related to payment and remittance that have conventionally been routed through ATMs, windows, and dedicated terminals, are running on mobile terminals. When using such a service, it is common to install a dedicated program (application) and use the service via the application.

  Also, user authentication (or terminal authentication) needs to be performed when using the service. At this time, secret information possessed only by the user (or terminal) is used. Such processing is desirably performed within the area on the SIM chip, but as described above, in most cases, confidential information is handled on the application. This is because the storage capacity and processing capacity of the SIM chip are low in order to install the service application.

  On the other hand, from the viewpoint of security of mobile terminals, there is a reality that about 10% of terminals are infected with malware, and the existence of malware specialized for financial services has also been confirmed. Therefore, the application needs to protect secret information (secret key and biometric information) required for user authentication and communication path encryption.

  In Patent Document 1, in order to detect falsification of an application, the hash value of the application is stored at the same time as the application, the hash value of the application is calculated when the program is executed, and matches the stored hash value. Only if you are running the app. However, if the malware can tamper with the application, it is also easy to tamper with the stored hash value.

  As a countermeasure against the above problems, an obfuscation technique is known that makes it difficult to read without retaining confidential information as it is. Therefore, it is considered that the risk of leaking confidential information can be reduced by obfuscating the application and key set. Many methods have already been examined for obfuscation.

JP 2010-102579 A

  The app image that obfuscates the app and key set is rewritten each time the key is updated. As described above, it is difficult to store a program including an updatable parameter in a system area where writing with a general user authority is prohibited. Therefore, a method of storing only the hash value of the program in a system area where a user program such as malware cannot write can be considered. However, with the general user authority, the hash value of the program after the parameter update cannot be written in the system area.

  Therefore, a technique for preventing falsification of a program including an updatable parameter stored in a user area where writing with general user authority is permitted is desired.

  An example is a method in which a computer storing a program image including updatable parameters protects the program image, the computer including a processor, a first storage area that is prohibited from being written by a user, A second storage area that is allowed to be written by a user, wherein the first storage area stores at least one reference hash value, the second storage area stores a current program image, and the current storage area The program image includes an updatable parameter, a program generation function unit that generates a new program image from the update data of the updatable parameter and the current program image, and the method includes: Update data, and the processor A generation function unit, generating the new program image by inputting the current program image and the update data, the processor executing generation of at least one value of a predetermined length, and the processor Performing a comparison between at least one current hash value calculated with one value and the new program image as input, and the at least one reference hash value, wherein the processor has a reference in the at least one reference hash value; Until the current hash value that matches the hash value is found, the generation of the at least one value and the comparison are repeated, and the processor uses the predetermined length value used to calculate the matching current hash value , The second memory with data combined with the new program image The in-frequency current to override the program image.

  According to one embodiment of the present invention, falsification of a program including an updatable parameter can be prevented.

1 is a diagram illustrating a system configuration in Embodiment 1. FIG. FIG. 6 is a sequence diagram illustrating a key initialization and update protocol in the first embodiment. 1 is a schematic diagram illustrating a device configuration in Embodiment 1. FIG. It is an image figure which shows the access authority with respect to the data preserve | saved at the memory | storage device of FIG. It is a flowchart showing the process from the download of the application in Example 1 to the storing to a terminal. It is a block diagram of a function required when performing the application in Example 1. FIG. FIG. 10 is a flowchart illustrating an application execution process according to the first embodiment. FIG. 3 is a diagram illustrating a functional configuration necessary when performing key update in the first embodiment. FIG. 6 is a flowchart illustrating a key update process in the first embodiment. FIG. 10 is a flowchart illustrating a key update process in the second embodiment. It is a figure showing the structural example 1 of the message authenticator algorithm in Example 3. FIG. It is a figure showing the structural example 2 of the message authenticator algorithm in Example 3. FIG.

  Embodiments of the present invention will be described below with reference to the accompanying drawings. It should be noted that this embodiment is merely an example for realizing the present invention, and does not limit the technical scope of the present invention. In each figure, the same reference numerals are given to common configurations.

  The apparatus of the present disclosure stores a hash value of an application image in a system area (which cannot be rewritten by malware) when an application program (hereinafter simply referred to as an application) is installed. When the application is executed, alteration of the application is detected by comparing the hash value of the application image at that time with the stored hash value.

  Furthermore, when updating the application image, the apparatus combines a numerical value with the updated application image so that the hash value of the updated application image matches the hash value stored in the system area. In order to find a collision between two hash values, the device repeatedly updates the combined numerical value and calculates the hash value.

  In order for the malware to tamper with the app image without being detected, the hash value of the tampered app must match the stored hash value. Malware requires less time to find a collision between two hash values because it has less computational resources available than a legitimate app. Thereby, the alteration of the application image by malware can be effectively prevented.

  FIG. 1 shows the system configuration of this embodiment. This system includes a user terminal 102 possessed by a user 101, an application distribution server 103 that distributes an application, and a service provider 104 that provides a service to the user via the application. Here, the service provider 104 indicates one or a plurality of servers. The service provider 104 entrusts the application distribution server 103 to distribute an application necessary for using the service.

  When using a service provided by the service provider 104, the user accesses the application distribution server 103 from the user terminal 102 owned by the user and downloads the application. Then, use the service through the installed application.

  Normally, the application download from the application distribution server 103 uses encrypted communication in order to prevent tampering during the communication. This communication is temporary, and the application distribution server 103 often does not authenticate the terminal 102.

  On the other hand, the service provider 104 confirms that the owner of the user terminal 102 is a valid service user when providing the service. The user terminal 102 proves that it has some secret information and indicates to the service provider 104 that it is a legitimate service user.

  The user terminal 102 stores secret information 105 such as a password, a secret key, or temporarily captured user biometric information for proving to the service provider 104 that the user terminal 102 is a legitimate user terminal. The user terminal 102 also holds an obfuscation parameter 106 used for obfuscation for protecting the secret information 105. Obfuscation encodes an app using obfuscation parameters 106, making analysis difficult. Details of the obfuscation and obfuscation parameter 106 will be described later.

  FIG. 2 is a sequence diagram illustrating a key initialization and key update protocol according to this embodiment. Hereinafter, the protocol will be described with reference to FIG. The service provider 104 performs obfuscation processing on the application using fixed parameters, and combines the application and the obfuscation function (201).

  The obfuscated application includes an application encoded for obfuscation and a program (at least a part thereof) for obfuscation (encoding / decoding of the application). In the following description, “function” indicates a program (program module) unless otherwise specified. Obfuscation is coded to protect the app. In the example described below, the obfuscation parameter is an obfuscation secret key. Obfuscation may use a different encoding than the encryption that uses the key.

  Next, the service provider 104 transmits an application registration request to the application distribution server 103, and registers the obfuscated application in the application distribution server 103 (202). Note that the service provider 104 may register the application in the application distribution server 103 without obfuscating the application.

  Next, the obfuscated application is downloaded from the application distribution server 103 to the user terminal 102 as described below. First, the user terminal 102 transmits an application download request to the application distribution server 103 (203). Furthermore, when receiving the application download request, the application distribution server 103 transmits the obfuscated application registered to the user terminal 102 (204).

  Next, the user terminal 102 initializes parameters for the downloaded application. In particular, the user terminal 102 receives the initialization parameters such as the terminal specific information, the system log, and the communication log, generates the obfuscated secret key 106, and performs the obfuscation process (205).

  In this example, the obfuscation secret key 106 is a key for encrypting / decrypting the application. The user terminal 102 decrypts the downloaded application using the fixed parameter, and further encrypts the application using the generated obfuscation secret key 106. The user terminal 102 generates image data of the obfuscated application including the encrypted application and the obfuscation function, and stores the image data in the storage device. The fixed parameter is preset in the user terminal 102 or transmitted from the application distribution server 103, for example.

  Next, user registration is performed as follows. First, the user 101 performs user registration with the service provider 104 via the user terminal 102 in which the application is installed (206). The user terminal 102 and the service provider 104 share a key for protecting the communication path (207). Further, the user terminal 102 updates the obfuscated secret key 106 using the shared key data and / or other data (208).

  After the user registration, the user 101 performs cryptographic communication with the service provider 104 via the user terminal 102 and uses the service (209).

  The key for using the service and the key for obfuscation are updated as follows. First, the user terminal 102 communicates with the service provider 104 to update a secret key for communication path protection (service use) (210). Further, the user terminal 102 updates the obfuscated secret key 106 using the updated key data and / or other data (211).

  The user terminal 102 uses the updated obfuscation secret key 106 to execute obfuscation processing on the application. Specifically, the user terminal 102 encrypts the application using the updated obfuscation secret key 106, and combines the encrypted application and the obfuscation function to obtain the image data of the obfuscated application. Generate and store in storage. The image data is an execution program or file.

  FIG. 3 is a diagram illustrating the hardware configuration of the system according to the present embodiment. The application distribution server 103 and the user terminal 102 communicate via the network 321. Each of the application distribution server 103 and the user terminal 102 can have a typical computer configuration. The service provider 104 server may similarly have a typical computer configuration.

  The application distribution server 103 includes a communication device 301, a CPU 302 that is a processor, a memory 303, and a storage device 304. The storage device 304 stores the obfuscated application 305. The application is a program that can be executed on the terminal 102. The memory 303 stores a program executed by the CPU 302 and data used for the program. The CPU 302 functions as a predetermined means by operating according to a program.

  The user terminal 102 includes a communication device 311, a CPU 312 that is a processor, a memory 313, and a storage device 314. The memory 313 stores a program executed by the CPU 312 and data used for the program. The CPU 312 realizes a predetermined function (not a program) by operating according to the program. In the following, unless otherwise specified, the processing by the user terminal 102 is executed by the CPU 312.

  The storage device 314 stores a terminal-specific application image 315 that is an obfuscated application and a hash value 317 of the application image 315. The user terminal 102 executes obfuscation processing on the application downloaded from the application distribution server 103, and stores the obfuscated application 315 in the storage device 314.

  In the obfuscation process, the obfuscation secret key (obfuscation parameter) 106 is generated using the initialization parameter 316. As described above, the initialization parameter 316 is, for example, terminal-specific information, and / or a system log and a communication log. The hash value 317 is calculated from the application image 315 by a predetermined hash function.

  FIG. 4 is a conceptual diagram showing access authority for data stored in the storage device 314. The storage area of the storage device 314 includes two storage areas. One is a first storage area 401 (system area) where a general user (or user program) can read data and execute a program. The other is a second storage area 402 (user area) in which general users have authority to read, write, and execute programs. Data writing (updating) by a user with general authority is prohibited in the first storage area 401 and allowed in the second storage area 402.

  A terminal-specific application image 315 is stored in the second storage area 402. In addition, the hash value 317 of the application image 315 unique to the terminal and the boot loader 411 and the hash function 412 included in the obfuscated application 305 are stored in the first storage area 401. The hash function 412 may be installed in the user terminal 102 in advance. Data or a program stored in the first storage area 401 is not rewritten by updating the obfuscated secret key. On the other hand, the data or program stored in the second storage area 402 is data that can be updated by updating the obfuscation secret key.

  FIG. 5 is a flowchart showing processing for downloading and storing an application in the user terminal 102. First, the user terminal 102 and the application distribution server 103 establish encrypted communication (501). As a communication method, for example, TLS (Transport Layer Security) may be used. Next, the user terminal 102 transmits an application download request to the application distribution server 103 (502).

  In response to the application download request from the user terminal 102, the application distribution server 103 transmits the target obfuscated application 305 to the terminal 102 (503). The user terminal 102 executes the installer of the application 305 (S504). The application 305 includes a boot loader 411 and a hash function 412.

  The user terminal 102 creates a terminal-specific application image 315 using the initialization value 316 using the unique value of the user terminal 102 such as the MAC address, CPU number, OS version information, current date / time information, and system log. (505). The user terminal 102 further calculates the hash value 317 of the generated application image 315 using the hash function 412.

  The user terminal 102 stores the generated application image 315 in the second storage area 402 (506). The user terminal 102 stores the generated hash value 317, boot loader 411, and hash function 412 in the first storage area 401.

  The security of the application image 315 depends on the length of the stored hash value 317. If the hash value 317 is too long, a legitimate program takes an unacceptable time for the processing described later to find a numerical value that matches the hash value. On the other hand, if the hash value 317 is too short, the malware can easily tamper with the application image 315.

  Therefore, the user terminal 102 (predetermined program) may perform a user terminal 102 benchmark test at the time of installation. In the benchmark test, for example, a time for executing the hash function 412 a predetermined number of times is calculated in order to calculate a hash value having a specific length. Based on the benchmark result and a predetermined security level, the user terminal 102 determines the length of the hash value 317 to be stored. For example, the length of the longest hash value whose measurement time is less than the threshold is selected.

  In generating the application image 315, the user terminal 102 generates the obfuscated secret key 106 using the initialization parameter 316. The user terminal 102 decrypts the encrypted application in the obfuscated application 305 and further encrypts the application using the obfuscated secret key 106. The user terminal 102 generates an application image 315 including an encrypted application and a function for obfuscation. For example, the installer of the user terminal 102 executes the above process.

  The installer inputs the initialization parameter 316 to a hash function such as SHA-256, uses the output as a seed for the random number generator, and executes randomization of the memory location of the dll using the obtained random number. May be. The installer may encrypt the application using the obtained random number as a secret key. Since the entity of the application image 315 obtained as a result is different for each terminal, the risk of attack by malware can be reduced.

  The installer may use a value derived from a secret key in encrypted communication as the initialization parameter. For example, when DH (Diffie-Hellman) key sharing is used, since the DH component is secret information known only to the terminal, the communication partner server cannot estimate the initialized application.

  Next, an application execution process in this embodiment will be described with reference to FIGS. FIG. 6 is a diagram illustrating a functional configuration example for executing an application in the present embodiment. The user terminal 102 includes a boot loader 411 that is activated when an application is executed, a hash function 412, an application image hash value 317, and an application image 315.

  Upon receiving the processing target data 601, the boot loader 411 executes the application image 315 and outputs a processing result 602 (details of the processing sequence will be described later). The boot loader 411 uses system information and time information 621 at the time of execution. The system information and time information 621 are stored in the first storage area 401, for example.

  The application image 315 includes obfuscated application data 611 and an expiration date 614 of the obfuscated secret key 616. The obfuscated application data 611 includes an obfuscated original application function 615, an obfuscated secret key 616, and a decoder 617.

  FIG. 7 is a flowchart showing application execution processing. The boot loader 411 acquires system information and time information 621 (701). The boot loader 411 compares the expiration date 614 of the obfuscated secret key 616 with the system information and the time information 621 to confirm whether the obfuscated secret key 616 is valid (702). When the obfuscation secret key 616 has expired (702: No), the boot loader 411 transmits an obfuscation secret key update request to the service provider 104 (703), and ends the processing.

  If the obfuscated secret key 616 is valid (702: Yes), the boot loader 411 calculates the hash value of the application image 315 using the hash function 412 (704).

  The boot loader 411 checks whether the calculated hash value matches the hash value 317 stored in the first storage area 401 (705). If the two hash values do not match (705: No), the boot loader 411 determines that the application image 315 has been tampered with, notifies the user (706), and ends the process.

  If the two hash values match (705: Yes), the boot loader 411 executes the decoder 617, and the decoder 617 decodes the original function 615 of the application and the obfuscated secret key 616 (707). . The decoded original function 615 of the application processes the processing target data 601 and outputs a processing result 602 (708).

  In this way, by calculating the hash value of the application image and comparing it with the hash value stored in the storage area where writing by malware is prohibited, it is possible to prevent alteration of the application image by malware. Start the app, compare the system time information with the expiration date of the obfuscated secret key, confirm that the expiration date has not expired, and replace the old app image by performing encrypted communication Can prevent attacks.

  Next, with reference to FIGS. 8 and 9, an application key update in the present embodiment will be described. FIG. 8 is a diagram illustrating a functional configuration example for performing key update in the present embodiment. The user terminal 102 includes a random number generation function 811, a hash function 412, and an application boot loader 411.

  The application image 315 is stored in the second storage area 402 of the storage device 314, and the hash value 317 is stored in the first storage area 401. The application image 315 includes an update data check function 812 and an application image generation function 813 in addition to the obfuscated application data 611, and holds the expiration date 821 of the obfuscated secret key 616 as data. .

  The random number 822 is data generated by the random number generation function 811. The update data 801 of the encryption communication / authentication function received via the network 321 includes update key data 823 and expiration date 2 (824) of the update key data 823.

  FIG. 9 is a flowchart showing key update processing in this embodiment. The user terminal 102 receives the update data 801 via the network 321 (901). The boot loader 411 uses the update data check function 812 to check that the received update key data 823 and the obfuscation private key expiration date 2 (824) have not been tampered with (902).

  The update data check function 812 uses, for example, a MAC (Message Authentication Code) function used in encrypted communication. When tampering is detected (902: unauthorized), the boot loader 411 notifies the service provider 104 of reception failure (903) and interrupts the update.

  When tampering is not detected (902: valid), the boot loader 411 inputs the old application image 315 and the update data 801 to the application image generation function 813 and generates a new application image 831 (904). The boot loader 411 generates a random number 822 using the random number generation function 811 (905).

  The random number 822 has a predetermined length. The boot loader 411 inputs the generated random number 822 and the new application image 831 generated in step 904 to the hash function 631, and calculates a hash value (906). For example, the hash function 412 calculates a hash value from the combined random number 822 and the application image 831. The hash function 412 may calculate a hash value from the random number 822, and may further calculate a hash value from the combined hash value and the application image 831.

  In one example, the random number 822 and the application image 831 are combined by placing the random number 822 before the application image 831. Accordingly, it is possible to prevent an attack in which malware transmits a hash value of an application image to the outside and calculates a hash value corresponding to a different random number using an external resource.

  If the generated hash value does not match the hash value 317 stored in the first storage area 401 (907: No), the boot loader 411 returns to Step 4. In the second storage area 402, the boot loader 411 overwrites the old application image 315 with data (the stored new application image) obtained by combining the random number 822 and the new application image 831 (908). The boot loader 411 notifies the service provider 104 of the successful key update (909).

  As described above, the boot loader 411 matches the hash value of the application image with the stored hash value by combining the random number with the updated application image. By using random numbers, security against tampering can be increased. The boot loader 411 may use a numerical value of a type different from the random number. For example, the boot loader 411 may use a predetermined function that outputs a value of a predetermined length or a counter that indicates a predetermined number of increments. These are stored in the first storage area 401, for example.

  Note that the boot loader 411, the random number generation function 811, the hash function 412, and the hash value 317 stored in the first storage area 401 are updated when the application acquires a privilege through a formal procedure (application update or the like). May be.

  When the malware tries to tamper with the application image in the system of this embodiment, it is necessary to perform a calculation with a large amount of hash functions. Therefore, in one example, the user terminal 102 (specific program thereof) uses a CPU monitor to monitor a program in which the total CPU usage time exceeds a predetermined value during a period in which one obfuscated secret key is continuously used. Thereby, malware can be detected.

  When detecting the falsification of the update data 801, the boot loader 411 compares the new obfuscation secret key expiration date 2 (824) with the system time information (indicating the current date and time) to determine a new obfuscation secret. The validity of the key may be checked. As a result, it is possible to prevent an attack that attempts to update the program using the old update data.

  The above example uses a hash value to prevent tampering with an obfuscated app image that includes a private key as an updatable parameter. The present embodiment and other embodiments described below can be applied to a program including an updatable parameter different from an obfuscated application image including a secret key.

  In the first embodiment, a single hash value is generated and stored when an application image is installed. Instead, the second embodiment generates and stores a plurality of hash values at the time of installation. As a result, the number of calculations of the hash value at the time of updating the application image can be reduced, or the hash value can be lengthened to improve safety.

  In step 505 of FIG. 5, the application image installer does not calculate the hash value of the application image, but generates k random numbers (k is an integer of 2 or more), and hashes each random number and application image as input. The function is calculated, and a list of random number / hash value pairs is stored in the first storage area 401. If the hash values of different random numbers are the same value, the installer leaves only one pair in the list. Note that random numbers may be omitted from the list. As in the first embodiment, a numerical value different from the random number may be used.

  The installer combines the random number of one entry selected from the list and the application image, and stores them in the second storage area 402. The installer stores the identifier (for example, the number in the list) of the current hash value in the second storage area 402, for example.

  When executing the application, the boot loader 411 calculates a hash value of the application image 135 stored in the second storage area 402, and compares the calculated hash value with the current hash value of the list in the first storage area 401. Check if the app image has been tampered with.

  FIG. 10 is a flowchart illustrating an application update flow according to the second embodiment. The update flow of the second embodiment conforms to the update flow shown in FIG. 9 of the first embodiment, but this update flow is different in the processing of steps 905, 906, and 907 of the update flow shown in FIG. In the following, differences from the first embodiment will be mainly described.

  In step 1004 (corresponding to step 904 in the first embodiment), the boot loader 411 inputs the old application image 315 and the update data 801 to the application image generation function 813 and generates a new application image 831.

  In step 1005, the boot loader 411 uses the random number generation function 811 to generate m random numbers (m is an integer equal to or greater than 1). In step 1006, the boot loader 411 inputs each of the m random numbers 822 generated and the new application image 831 generated in step 1004 to the hash function 412, and calculates m hash values.

  In step 1007, the boot loader 411 collects the m hash values generated in step 1006 and the stored k hash values in one list, and sorts them in ascending or descending order using the hash values as keys. In addition to the hash value, the entry of this list includes a random number value and a flag indicating whether the value is a newly generated value.

  In step 1008, the boot loader 411 searches for an entry having the same hash value from the list sorted in step 1007. If not found (1008: No), the boot loader 411 returns to Step 1005. In addition, even when found, if both are newly generated hash values, the boot loader 411 returns to Step 1005.

  When a newly generated hash value that matches one stored hash value is found (1008: Yes), in step 1009, the boot loader 411 replaces the old application image 315 with a random number 822 corresponding to the found hash value. Overwrite with new combined application image 831 data.

  In this embodiment, by comparing a plurality of stored hash values with one or more hash values of the updated application image, a random number combined with the updated application image can be determined efficiently. The number of calculations can be reduced or the hash value can be lengthened with the same calculation amount. By comparing a plurality of hash values of the updated application image with a plurality of stored hash values, it is possible to determine a random number to be combined with the updated application image more efficiently.

  The present embodiment can improve safety by using the fact that there is a difference in the amount of available memory between a regular user program and malware. For example, since the amount of memory that can be used when sorting the list of hash values in step 1007 is different, the malware executes the loop processing of steps 1005 to 1008 many times compared to the regular user program. Since the restriction on the amount of memory is converted into the time required for the attack, even if the length of the hash value is the same as in the first embodiment, the difference in time required for the malware and the authorized user to find a collision becomes large.

  In one example, the list of hash values stored at the time of installation is maintained in an unsorted state (an order different from the sorted order). Not being sorted increases the user load at the time of update (if the length of the hash value is fixed), but further increases the cost for the malware to succeed in tampering. That is, the calculation load of the user program is relatively reduced.

  When the malware tries to tamper with the application image in the system of this embodiment, it is necessary to perform a large amount of hash function calculation and at the same time place a large amount of data on the memory for sorting. Some search algorithms use only a small amount of memory, but suffer from the penalty of increasing the overall computational cost.

  In one example, the user terminal 102 (specific program) uses a memory monitor to monitor a program whose memory occupancy × time exceeds a predetermined value during a period in which one obfuscation key is continuously used. Thereby, malware can be detected.

  Furthermore, by combining the information obtained from the CPU monitor and measuring the CPU load when the memory consumption exceeds a predetermined value, it is possible to detect malware that attempts to tamper more appropriately. There are other common apps that consume a lot of CPU and memory, such as web browsers, but these apps can be whitelisted in advance to reduce the possibility of false detection of malware. Can be made.

  Next, consider the case where malware can communicate with an external attacker. An attacker can use more computational resources than a single large number of terminals such as the cloud. Only the methods described in the first and second embodiments may not guarantee sufficient safety against an attacker such as the above.

  In other words, the malware may send a pair of app image and hash value to an external attacker, and the external attacker may be able to find a random number to be granted using abundant computational resources. As a more effective countermeasure against such an attacker, a technique based on the property that “if a malware transmits and receives a large amount of data, it can be detected (incompressibility)” is known.

  In the first and second embodiments, the configuration using the hash function has been described. However, since a normal hash function does not have secret information, in principle, incompressibility is not satisfied. When a block cipher and a CMAC, which is a general MAC (Message Authentication Code) configuration method, are combined, this configuration also does not satisfy incompatibility.

  In the present embodiment, a configuration using a message authenticator that uses secret information to detect a feature value of data will be described with reference to FIG. In the present embodiment, a hash value is calculated using a keyed hashing for Message Authentication Code.

  In FIG. 11, the block cipher 1101 is a program that satisfies the incompressibility of a block cipher having a block length of 2n bits. The user terminal 102 (CPU 312) performs appropriate padding on the input data (here, the application image 315), sets the data length to a multiple of n bits, and sets n-bit data blocks M [1], M [2],. . . , M [k].

  A predetermined n-bit constant C1102 and the first data block M [1] 1103 are combined. The user terminal 102 inputs the combined data to the block cipher 1101 and discards the lower n bits of the output.

  The user terminal 102 combines the upper n bits of the output with the next data block M [2] 1103 and inputs the combined data to the block cipher 1101. Hereinafter, the user terminal 102 repeatedly inputs data obtained by combining the upper n bits of the output of the block cipher 1101 and the next data block 1103 to the block cipher 1101. The user terminal 102 outputs the upper n bits of the output of the last block cipher 1101 as the MAC value T (hash value) 1104.

  In order for an attacker to calculate a MAC value, a secret key for block cipher is required. However, since the block cipher program 1101 in the user terminal 102 satisfies incompressibility, the secret key cannot be completely extracted. Therefore, even if the attacker obtains the hash value 317 of the application image 315 or the intermediate state of the cryptographic process via malware, the attacker only applies the MAC value to a specific input (which has been calculated so far). It can be calculated. Thus, an attacker cannot find a MAC value collision even if he spends computational resources.

  By substituting the hash function 412 of the first embodiment with the MAC value calculation algorithm described in the present embodiment, it is possible to more effectively prevent tampering with malware using external calculation resources.

  In the process of the last block, a predetermined constant (not zero) may be added to the upper n bits. Thereby, length extension attack can be prevented. Instead of addition, other operations that are bijective, such as subtraction or exclusive OR, may be used.

  As shown in FIG. 12, instead of discarding half of the output of the block cipher process, an exclusive OR with the next data block may be calculated. Specifically, the user terminal 102 and the user terminal 102 (CPU 312) perform appropriate padding on the input data, the data length is a multiple of n bits (n is a natural number), and an n-bit data block M [1], M [2],. . . , M [k].

  The user terminal 102 combines a predetermined n-bit constant C1, the n-bit constant C2 and the exclusive OR of the first data block M [1], and inputs them to the block cipher. The user terminal 102 calculates the exclusive OR of the lower n bits of the block number output and the next data block. The user terminal 102 combines the upper n bits of the block cipher and the exclusive OR, and inputs them to the block cipher. The user terminal 102 repeatedly calculates the block cipher of the data obtained by combining the upper n bits, the lower n bits and the exclusive OR of the next data block, and finally outputs the lower n bits as a MAC value (hash value). To do.

  In addition, this invention is not limited to an above-described Example, Various modifications are included. For example, the above-described embodiments have been described in detail for easy understanding of the present invention, and are not necessarily limited to those having all the configurations described. Further, a part of the configuration of one embodiment can be replaced with the configuration of another embodiment, and the configuration of another embodiment can be added to the configuration of one embodiment. Further, it is possible to add, delete, and replace other configurations for a part of the configuration of each embodiment.

  Each of the above-described configurations, functions, processing units, and the like may be realized by hardware by designing a part or all of them, for example, by an integrated circuit. Each of the above-described configurations, functions, and the like may be realized by software by interpreting and executing a program that realizes each function by the processor. Information such as programs, tables, and files for realizing each function can be stored in a memory, a hard disk, a recording device such as an SSD (Solid State Drive), or a recording medium such as an IC card or an SD card. In addition, the control lines and information lines are those that are considered necessary for the explanation, and not all the control lines and information lines on the product are necessarily shown. In practice, it may be considered that almost all the components are connected to each other.

101 user, 102 user terminal, 103 application distribution server, 104 service provider, 105 secret information, 301 communication device, 302 CPU, 303 memory, 304 storage device, 305 obfuscated application, 311 communication device, 312 CPU, 313 memory 314 storage device, 315 application image, 316 initialization parameter, 317 hash value, 401 first storage area, 402 second storage area, 411 boot loader, 412 hash function, 601 processing target data, 602 processing result, 614 obfuscation Expiration date of private key 616, 611 obfuscated application data, 615 original application function, 617 decoder, 801 key data for update of encryption communication / authentication function, 812 update data check function, 821 for obfuscation Expiration Mitsukagi 616, 824 of the update key data 823 expiration 2,1101 block cipher, 1103 data blocks, 1104 MAC value T

Claims (11)

A computer storing a program image containing updatable parameters is a method for protecting the program image,
The calculator is
A processor;
A first storage area in which writing by a user is prohibited;
A second storage area that is allowed to be written by the user,
The first storage area stores at least one reference hash value;
The second storage area stores a current program image,
The current program image includes an updatable parameter, a program generation function unit that generates a new program image from update data of the updatable parameter and the current program image,
The method
The processor obtains update data of the updatable parameter;
The processor calls the program generation function unit, inputs the current program image and the update data, generates a new program image,
The processor performs generation of at least one value of a predetermined length;
The processor performs a comparison of the at least one current hash value calculated with the at least one value and the new program image as input and the at least one reference hash value;
The processor repeats the generation of the at least one value and the comparison until a current hash value is found that matches a reference hash value in the at least one reference hash value;
The method, wherein the processor overwrites the current program image in the second storage area with data obtained by combining the new program image with the predetermined length value used to calculate the matching current hash value. The method of claim 1, comprising:
The method wherein the predetermined length value is a random number. The method according to claim 1 or 2, wherein
The current program image further includes a check function unit that checks the validity of the update data,
The method
When the processor obtains the update data of the updatable parameter, it calls the check function unit to check the validity of the update data,
The method further comprising: if the update data is valid, the processor generates the new program image. The method according to claim 1, 2 or 3,
The current program image includes data indicating an expiration date of a current value of the updatable parameter;
The method
The method further comprising: stopping the execution of the current program image if a current date and time has passed the expiration date. The method of claim 1, comprising:
The method in which the first storage area stores a plurality of reference hash values. The method of claim 1, comprising:
The first storage area stores a plurality of reference hash values,
The method
The processor generates a plurality of values of the predetermined length;
The method, wherein the processor performs a comparison of a plurality of current hash values calculated with the plurality of values and the new program image as input and the plurality of reference hash values. The method according to claim 5 or 6, comprising:
The plurality of reference hash values are listed in an order different from the sorted order in the first storage area. A method according to any one of claims 1 to 7, comprising
The method
The processor monitors memory usage of the processor and the computer;
A method in which the processor determines that a program whose load on the processor and consumption of the memory exceed a threshold is malware. A method according to any one of claims 1 to 8, comprising
The reference hash value and the current hash value are calculated by a keyed hash function,
The keyed hash function is
Padding the input data to generate initial data whose data length is a multiple of n bits, dividing the initial data into blocks of n bits;
Combine the n-bit constant and the first block to generate combined data,
Input the combined data to the block cipher, discard the lower n bits of the output of the block cipher, and obtain the upper n bits;
Combining the upper n bits with the next block to generate the next combined data;
Inputting the next combined data into the block cipher, discarding the lower n bits of the output of the block cipher, and obtaining the upper n bits;
Repeating the generation of the next combined data and obtaining the upper n bits of the output of the block cipher with the next combined data as input. A method according to any one of claims 1 to 8, comprising
The reference hash value and the current hash value are calculated by a keyed hash function,
The keyed hash function is
Padding the input data to generate initial data whose data length is a multiple of n bits, dividing the initial data into blocks of n bits;
combining the exclusive OR of the n-bit first constant, the n-bit second constant, and the first block to generate combined data;
Input the combined data into a block cipher, obtain an output of the block cipher,
Combining the upper n bits of the output with the exclusive OR of the next block and the lower n bits of the output to generate the next combined data;
Inputting the next combined data into the block cipher and obtaining the next output of the block cipher;
Repeating the generation of the next combined data and the acquisition of the next output of the block cipher with the next combined data as input. A device for protecting a program image containing updatable parameters,
A processor;
A first storage area in which writing by a user is prohibited;
A second storage area that is allowed to be written by the user,
The first storage area stores at least one reference hash value;
The second storage area stores a current program image,
The current program image includes an updatable parameter, a program generation function unit that generates a new program image from update data of the updatable parameter and the current program image,
The processor is
Obtaining update data of the updatable parameter;
Call the program generation function unit, input the current program image and the update data to generate a new program image,
Perform generation of at least one value of a predetermined length;
Performing a comparison between at least one current hash value calculated with the at least one value and the new program image as input, and the at least one reference hash value;
Repeating the generation of the at least one value and the comparison until a current hash value matching a reference hash value in the at least one reference hash value is found;
An apparatus for overwriting the current program image in the second storage area with data obtained by combining the new program image with the predetermined length value used to calculate the matching current hash value.