KR102543267B1 - Method and apparatus for white box cryptography - Google Patents

Abstract

An encryption/decryption method using white box encryption is provided. An encryption/decryption method using a white box cryptography according to an embodiment of the present invention includes: loading, by a computing device, a white box cryptographic module into a memory provided in the computing device; determining start data for starting encryption/decryption of the whitebox cryptographic module at run-time of a module, using data obtained at run-time; and, by the computing device, using the start data and starting an encryption/decryption operation of the white box cryptographic module.

Description

Encryption/decryption method and apparatus using white box cryptography {Method and apparatus for white box cryptography}

The present invention relates to an encryption/decryption method and apparatus using white box encryption. More specifically, it relates to a method and device for compensating for a problem in which security is weakened when encryption/decryption is performed using a general-purpose processor and a general-purpose storage space without using a secure element composed of hardware.

Encryption technology is a technology that converts plain text into cipher text. Such encryption technology may be implemented as software code or as a hardware device. Encryption techniques include white box encryption methods and black box encryption methods.

Referring to FIG. 1 , the white box encryption method will be described in comparison with the black box encryption method.

The encryption key 36 of the black box encryption method 30 is contained inside the encryption device 38 assumed to be a black box. A black box means that 'the inside cannot be seen.' That is, the design of the black box encryption method 30 starts from the assumption that a cracker cannot look inside the encryption device. However, a cracker can find out a certain pattern by continuously observing the plain text 32 input to the black box-based encryption device and the cipher text 34 output, and if the encryption device itself is breached, the encryption key may be leaked as it is.

The white box encryption method (40) is more secure than the black box encryption method (30). The white box 42 means a transparent box through which one can look inside. The white box encryption method 40 starts from the assumption that since the cracker can look into the inside of the white box 42, it can see all the software execution processes related to encryption/decryption.

Assuming that the encryption device is a white box, the encryption key 36 cannot be easily stored in the device. Therefore, in the white box encryption method 40, the algorithm is made into a look-up table, and the encryption key is hidden inside the look-up table in a state mixed with the encryption algorithm implemented in software, even if the operation of the software is analyzed. It prevents the encryption key from being easily guessed.

The white box encryption technology has many advantages in that it is a security technology implemented only with software, unlike a technology using existing security hardware. Only software can protect encryption keys and intermediate operation values of cryptographic algorithms. The distribution and installation of the key and the module to protect it are easy and cost effective. Also, when an error occurs, it has the advantage that it can be corrected remotely through software update or patch transmission.

This encryption technology is applied to e-commerce related payments using mobile devices. In order to explain the existing hardware-based security method used for mobile payment, refer to FIGS. 2 and 3 .

2 is a diagram for explaining a payment technology using a secure element composed of hardware. As the hardware security element 15 that provides a security area to the mobile device, a USIM issued by a carrier and an embedded SE (eSE) embedded in the device are largely used. The security area of the USIM is composed of a small CPU and memory. The CPU identifies the user with encryption/decryption functions, and the memory is used as a storage space for additional services. That is, the security area may serve as a security token (Hardware Security Module, HSM). An eSE built into a manufacturing terminal can also perform the same role.

Payment through a mobile device stores supplement-related data such as encryption keys and electronic certificates in the hardware security element 15 including the USIM and eSE described above, and stores and installs programs such as mobile payment-related applets to perform encryption and decryption. By doing so, exposure of important data is prevented and security strength is increased.

The encryption module based on the hardware security element 15 has an advantage of high security strength, but due to the nature of the hardware, it is difficult to develop a security module based thereon. In the case of USIM, since the communication company has the right to control, each communication company must obtain permission to use it. In the case of eSE, the mobile device manufacturer has the right to control, and the eSE type is different for each manufacturer. Therefore, it is necessary to develop an applet suitable for each SE type, and collaboration with carriers and hardware manufacturers is essential. In addition, when a vulnerability of the hardware SE in use is discovered, it is not easy to respond, making maintenance difficult. There is no other way than to replace it with a new product that compensates for the vulnerability. Also, protection against actions that occur outside the hardware SE is not possible. For example, since it cannot protect operations that occur outside the SE, such as PIN input, important user input values or important data inside the mobile APP may be exposed to attackers.

3 is a diagram for explaining a case in which the payment server 20 performs encryption/decryption functions related to payment. When the payment server 20 performs the encryption/decryption function as shown in FIG. 3, network communication between the server 20 and the mobile device 100 is essential, so when the mobile device 100 is in a location where network access is impossible. In this case, the use of the payment system becomes unavailable. For example, it is impossible to pay a bus fare in a communication shaded area.

Therefore, instead of performing the security logic by the hardware security element 15 or the external payment server 20, a method of performing security logic using a software security element that increases security while using a general-purpose processor and a general-purpose memory And it is required to provide an encryption/decryption method or a payment authentication method using the method.

A technical problem to be solved by the present invention is to provide a method for performing encryption/decryption through a software security element that provides a security environment with enhanced security without the help of a hardware security element, and an apparatus for performing the method.

Another technical problem to be solved by the present invention is an attack in which encryption or decryption is unauthorized without obtaining an encryption key by extracting the entire whitebox encryption module in a first device and performing the whitebox encryption module in a second device. It is to provide an encryption/decryption method capable of preparing for and an apparatus for performing the method.

Another technical problem to be solved by the present invention is to overcome the hardware dependence and constraints of existing security methods and to provide an encryption/decryption method with versatility applicable to all computing devices and a device for performing the method. will be.

Another technical problem to be solved by the present invention is to provide a method and apparatus for supporting secure payment using a computing device not equipped with a hardware security element.

The technical problems of the present invention are not limited to the technical problems mentioned above, and other technical problems not mentioned will be clearly understood by those skilled in the art from the description below.

An encryption/decryption method using a white box cryptography according to an embodiment of the present invention for solving the above technical problem includes loading a white box cryptographic module into a memory provided in the computing device, and Determining, at run-time, starting data for starting encryption/decryption of the white-box cryptographic module using data obtained at run-time; Initiating an encryption/decryption operation.

In one embodiment, the data obtained at the runtime may include pre-designated information to be inquired at the runtime and information input through a user interface at the runtime.

In one embodiment, the data obtained at runtime may include information dependent on the computing device and information dependent on a user of the computing device. The information subordinate to the device may be a unique identifier of the computing device, and the information subordinate to the user may be at least one of security information pre-registered by the user and biometric information of the user.

In one embodiment, initiating the encryption/decryption operation of the whitebox cryptographic module may include deriving an initialization vector (IV) of the whitebox cryptographic module using the start data, and deriving an initialization vector (IV) of the whitebox cryptographic module; Initiating an encryption/decryption operation of the whitebox cryptographic module using

In one embodiment, the step of loading into the memory includes loading the whitebox cryptographic module into a non-secure address area of the memory, and the whitebox cryptographic module is a general-purpose processor provided in the computing device. -purpose processor). At this time, the general purpose processor does not have a hardware secure element for the white box cryptographic module.

In one embodiment, the whitebox cryptographic module may include an anti-debugging operation for preventing data obtained at runtime from being replaced with other data.

According to another embodiment of the present invention for solving the above technical problem, a payment authentication method performed by a general-purpose processor of a computing device is provided. The payment authentication method according to the present embodiment includes the steps of receiving payment request information including payment amount information from an external device, loading a white box cryptographic module into a memory provided in the computing device, and the white box cryptographic module. deriving, at run-time of a module, an initialization vector for starting encryption of the whitebox cryptographic module using an identifier of the computing device obtained at run-time and user input data for the computing device; and performing encryption on at least some of the payment request information of the white box encryption module using the initialization vector and generating payment authentication data using the encrypted data; and transmitting to an external device.

In one embodiment, the generating of the payment authentication data may include, when the identifier of the computing device and the user input data for the computing device are correct data, the first payment authentication data successfully processed by the external device. generating, and when at least one of an identifier of the computing device and user input data for the computing device is incorrect data, generating second payment authentication data for which payment is rejected by the external device. there is. At this time, the first payment authentication data and the second payment authentication data are digital data different from each other by at least one bit.

A computing device according to another embodiment of the present invention for solving the above technical problem is provided with a memory having a non-secure address area into which a white box cryptographic module is loaded and a security element for the white box cryptographic module. A general-purpose processor and a short-range communication interface capable of communicating with a payment terminal, wherein the white-box cryptographic module includes, at run-time, an identifier of the computing device obtained at run-time and a user input to the computing device. An operation of deriving an initialization vector for starting encryption of the white box cryptographic module using data, and an operation of performing encryption of at least some data among payment request information of the white box cryptographic module by using the initialization vector and generating payment authentication data using encrypted data, wherein the short-distance communication interface receives the payment request information from the payment terminal and transmits the payment authentication data to the payment terminal.

In one embodiment, the whitebox cryptographic module may generate incorrect payment authentication data when the identifier of the computing device is not correct or the user input data is not correct. At this time, the short-distance communication interface may receive an approval rejection signal from the payment terminal.

A computing device according to another embodiment of the present invention for solving the above technical problem is provided with a memory having a non-secure address area into which a white box cryptographic module is loaded and a security element for the white box cryptographic module. A general-purpose processor and a network interface for network connection, wherein the white-box cryptographic module uses, at run-time, an identifier of the computing device obtained at run-time and user input data for the computing device, an operation of deriving an initialization vector for starting encryption of the whitebox encryption module, an operation of performing encryption of at least some data among payment request information of the whitebox encryption module using the initialization vector, and and generating payment authentication data using data, wherein the short-distance communication interface receives the payment request information from a payment server connected through the network, and transmits the payment authentication data to the payment server.

In one embodiment, the whitebox cryptographic module may generate incorrect payment authentication data when the identifier of the computing device is not correct or the user input data is not correct. At this time, the network interface may receive an approval rejection signal from the payment server.

According to some embodiments of the present invention, an effect capable of providing an encryption method and apparatus that can be performed in various devices can be achieved.

According to some embodiments of the present invention, it is possible to achieve the effect of increasing the security strength by supplementing the weakness of the white box encryption technology.

According to some embodiments of the present invention, it is possible to achieve an effect of providing a general-purpose and easy-to-maintain payment authentication solution using white-box encryption technology.

The effects of the present invention are not limited to the effects mentioned above, and other effects not mentioned will be clearly understood by those skilled in the art from the description below.

1 is a diagram for explaining a white box encryption technology compared to a black box encryption technology.
2 is a diagram for explaining a mobile payment method performed through a hardware security element.
3 is a diagram for explaining a mobile payment method in which security logic is performed on the payment server side.
4 is a flowchart of an encryption/decryption method using white box encryption according to an embodiment of the present invention.
5 is a detailed flowchart for explaining some operations of FIG. 4 in more detail.
6 is a first block configuration diagram of a white box encryption apparatus according to an embodiment of the present invention.
7 is a second block diagram of a white box encryption device according to an embodiment of the present invention.
8 is a diagram illustrating a first signal flow of an encryption method using a white box password according to an embodiment of the present invention.
9 is a third block diagram of a white box encryption device according to an embodiment of the present invention.
10 is a diagram illustrating a second signal flow of an encryption method using a white box password according to an embodiment of the present invention.
11 is a hardware configuration diagram of a white box encryption device according to an embodiment of the present invention.

Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings. Advantages and features of the present invention, and methods for achieving them, will become clear with reference to the embodiments described below in detail in conjunction with the accompanying drawings. However, the present invention is not limited to the embodiments disclosed below, but may be implemented in various different forms, and only the present embodiments make the disclosure of the present invention complete, and common knowledge in the art to which the present invention belongs. It is provided to fully inform the holder of the scope of the invention, and the present invention is only defined by the scope of the claims. Like reference numbers designate like elements throughout the specification.

Unless otherwise defined, all terms (including technical and scientific terms) used in this specification may be used in a meaning commonly understood by those of ordinary skill in the art to which the present invention belongs. In addition, terms defined in commonly used dictionaries are not interpreted ideally or excessively unless explicitly specifically defined. Terminology used herein is for describing the embodiments and is not intended to limit the present invention. In this specification, singular forms also include plural forms unless specifically stated otherwise in a phrase.

As used herein, "comprises" and/or "comprising" means that a stated component, step, operation, and/or element is the presence of one or more other components, steps, operations, and/or elements. or do not rule out additions.

Prior to the description of the invention through the drawings, the disadvantages of the white box encryption technique to be supplemented in some embodiments of the present invention will be described. The white box encryption technology can safely store the encryption key with only software, and prevents the encryption key from being revealed even if the encryption algorithm is executed on an untrusted terminal. Therefore, it is evaluated that it is implemented safely against an attack to extract an encryption key. However, the white box cryptographic module is vulnerable to an attack that extracts the entire module and uses it as a whole. If the entire encryption/decryption code using the whitebox encryption can be extracted, and the cracker can know the interface for executing the encryption/decryption code, it is not necessary to extract the encryption key, but it is included in the logic of the whitebox encryption. It is possible to utilize a cryptographic key.

According to some embodiments of the present invention, even when the entire whitebox cryptographic module is extracted by a cracker's attack, the extracted whitebox cryptographic module is prevented from operating normally in another device, thereby compensating for the above-described disadvantage.

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

An encryption/decryption method using a white box password according to an embodiment of the present invention may be executed by a computing device. Hereinafter, 'encryption/decryption' in this specification means encryption or decryption. The computing device includes a processor loaded into a memory, a memory into which an operation performed by the processor is loaded, and a storage for storing the operation regardless of power supply. However, the configuration of the computing device is only an example, and the computing device includes various types of devices having an arithmetic function.

4 is a flowchart of an encryption/decryption method using white box encryption according to an embodiment of the present invention. Hereinafter, an encryption/decryption method using white box encryption will be briefly described. Hereinafter, for convenience of understanding, when the subject of each operation is a computing device, it should be noted that description thereof may be omitted.

The computing device obtains information to be encrypted or decrypted (S100). The information may be stored in a storage device of the computing device, received through a network interface provided in the computing device, or input through a user interface such as a touch screen provided in the computing device.

The computing device loads a white box cryptographic module for encrypting/decrypting the information into a memory provided in the computing device (S105). 4 shows that the memory load of the white box cryptographic module is performed after obtaining information to be encrypted or decrypted. action may be performed. That is, the white box cryptographic module may be a temporarily loaded module that is temporarily loaded into the memory only when necessary, or a constantly loaded module that maintains a state of being always loaded into the memory. Even if the white box cryptographic module is a always-loaded module, it will go through a process of being loaded into a memory during a booting process of the computing device.

When the white box cryptographic module is operated in the form of an always-loading module, according to an embodiment, the whitebox cryptographic module may be loaded in a kernel area of a memory. The kernel area is a memory area used by the operating system, and user applications other than the operating system cannot invade the kernel area. Therefore, the code of the white box cryptographic module loaded in the kernel area of memory can be prevented from being leaked. In addition, by loading the whitebox cryptographic module in the booting process, it is possible to prevent a user application for cracking, which can operate only after booting is completed, from obtaining binary data of the whitebox cryptographic module.

Considering that the binary of the whitebox cryptographic module occupies a considerable memory space due to the size of the lookup table, etc., according to some embodiments of the present invention, the whitebox cryptographic module is configured according to the binary size of the whitebox cryptographic module. It can be operated as a constant load module or as a temporary load module. For example, the computing device checks the data size of the white box cryptographic module binary during the operating system booting process, and if the data size is less than a reference value, loads the white box cryptographic module into the kernel area of memory during the booting process and maintains booting. It maintains the loaded state as long as possible (constant loading module), and does not load the whitebox cryptographic module during booting if the data size is greater than the reference value (temporary loading module).

When the white box cryptographic module is operated in the form of a temporary load module, memory capacity can be saved by the size of binary data of the white box cryptographic module. However, in the process of loading the white box cryptographic module into the memory, there is a risk that the binary of the white box cryptographic module is copied by a cracking application.

The cracking application creates a situation in which the white box cryptographic module is required (eg, execution of a payment APP in which the whitebox cryptographic module is used), hooks a system function for memory load, obtains a memory address, and the like , you will be able to get the binary of the whitebox cryptographic module (using a memory dump technique). In order to prevent this behavior, a binary of the white box cryptographic module may be generated using various anti-debugging, code obfuscation, and anti-memory dump technologies. However, even if the binary of the white box cryptographic module is leaked despite the security technology, some embodiments of the present invention can prevent unauthorized execution of encryption/decryption using the leaked white box cryptographic module. The reason for this is explained below.

It will be described with reference to FIG. 4 again. A processor provided in the computing device executes the white box cryptographic module loaded into the memory (S110). The execution time of the white box cryptographic module of the processor is determined by the scheduler of the operating system installed in the computing device. For example, the white box cryptographic module is a library that is a set of functions that can be called by a user application. In this case, the processor executes the whitebox cryptographic module at a time when a user application such as a payment APP calls a function included in the library.

The computing device determines start data at runtime of the whitebox cryptographic module (S120). 'Run-time' refers to the point at which software is executed through a processor, which is distinct from compile time and load time. Accordingly, determining start data at run time of the white box cryptographic module indicates that the operation of determining the start data is also executed through the processor while the white box cryptographic module is being executed through the processor.

The computing device determines the starting data using data obtained at runtime of the whitebox cryptographic module. For example, the computing device determines the start data using data input or retrieved at the runtime.

In order to prevent starting data determined by an operation outside the whitebox cryptographic module from distorting or deceiving an execution environment of the whitebox cryptographic module, an operation for determining the starting data may be included in the whitebox cryptographic module.

The starting data is data required when the white box cryptographic module performs encryption/decryption. More specifically, the start data is data required when the whitebox encryption module starts encryption/decryption. For example, the start data is an initialization vector or a nonce.

The computing device performs an encryption/decryption operation of the white box encryption module using the start data (S125).

According to the embodiment described with reference to FIG. 4, start data, which is data necessary when the whitebox cryptographic module performs encryption/decryption, is determined at runtime of the whitebox cryptographic module and determined using data obtained at runtime. . Accordingly, when the entire binary of the whitebox cryptographic module is leaked to the outside, an operation for determining start data to be different from before the leak may be implemented. In this case, even if the entire binary of the whitebox cryptographic module is leaked to the outside, the encryption/decryption operation will not be performed properly. Therefore, according to the present embodiment, the weakness of the white box encryption technique is supplemented without using a hardware security element (SE).

In one embodiment, the starting data may be generated using data input by a user to the computing device at runtime of the whitebox cryptographic module.

In one embodiment, the start data may be generated using data retrieved at run time of the white box cryptographic module in a computer readable recording medium included in the computing device. The recording medium may be, for example, ROM (Read Only Memory). Since the ROM cannot be modified after data is recorded, the starting data is generated using the data retrieved from the ROM of the computing device at runtime of the whitebox cryptographic module, so that the starting data sets the execution environment of the whitebox cryptographic module. You can point to it accurately. The inquired data may be a unique identifier of the computing device. The unique identifier may be, for example, a medium access control (MAC) address or an international mobile equipment identity (IMEI).

In one embodiment, the start data may be generated using data received at runtime of the white box cryptographic module through a short-range communication interface provided in the computing device. The short-range communication interface is, for example, for RFID (Radio Frequency Identification), NFC (Near Field Communication), ZIGBEE, Bluetooth, or other short-range communication. It could be for an interface.

In one embodiment, the starting data may be generated using data received at runtime of the whitebox cryptographic module through a network interface included in the computing device.

In one embodiment, the starting data is data input by a user to the computing device at runtime of the whitebox cryptographic module, and data retrieved from a computer-readable recording medium included in the computing device at runtime of the whitebox cryptographic module. At least two of data, data received at runtime of the white-box cryptographic module through a short-range communication interface provided in the computing device, and data received at runtime of the white-box cryptographic module through a network interface provided in the computing device. can be created using

By determining the start data at run time using various data obtained at run time of the white box cryptographic module, it is more difficult to deceive as if the white box cryptographic module has not been leaked. This effect complements the weakness of the white box encryption technology (encryption/decryption is possible even without the encryption/decryption key if the binary of the white box encryption module is leaked in its entirety).

The determination of start data will be described in more detail with reference to FIG. 5 .

As shown in FIG. 5, the start data may be determined using both device-dependent information and user-dependent information (S122 and S124). The device refers to a computing device on which the whitebox cryptographic module is performed. The information dependent on the device may be a unique identifier of the computing device, for example, a MAC address, an IMEI value, or a serial number assigned by a device manufacturer. The information subordinate to the user may include, for example, at least one of security information pre-registered by the user and biometric information of the user. The biometric information includes face recognition information, fingerprint information, iris recognition information, and the like.

The reason why the start data is determined using the information dependent on the device is to reflect whether the computing device on which the whitebox cryptographic module is executed is an incorrect device such as a device that is not allowed or registered. In addition, the reason for determining the start data using the information dependent on the user is to prevent an unauthorized person from performing an encryption/decryption operation by the white box cryptographic module even when the computing device is stolen or lost. It is for

The computing device derives an initialization vector IV by using both device-dependent information and user-dependent information (S126). An initialization vector is a bit line, and is a value used when executing a stream cipher or block cipher in any encryption-enabled mode. In particular, it is used when encrypting the first block in block ciphers. It can be used in CBC, CFB, and OFB, respectively. A block cipher is an encryption method in which an encryption key and an algorithm are applied in blocks of data to produce ciphertext. The ciphertext of the previous cipherblock is applied in sequence to the next block in order to ensure that identical blocks of plaintext do not result in the same ciphertext in a message. In general, next blocks generate different ciphertext from the previous ciphertext by combining the initialization vector by the random number generator with the first block of plaintext so that identical messages encrypted at the same time do not produce the same ciphertext.

In one embodiment, in order to prevent the information dependent on the device and the information dependent on the user from leaking through the initialization vector, the hash value of the information dependent on the device and the information dependent on the user The initialization vector may be derived using a hash value, or the initialization vector may be derived using a hash value for concatenation of device-dependent information and user-dependent information.

The computing device initiates encryption/decryption of the whitebox cryptographic module using the initialization vector (S128). Since the encryption/decryption of the whitebox cryptographic module cannot be performed unless the initialization vector is created, the operation of the whitebox cryptographic module can be temporarily stopped before information dependent on the user is input.

So far, encryption/decryption methods using white box cryptography according to some embodiments of the present invention have been described. The encryption/decryption methods using the white box encryption may be performed by executing a computer program implemented as a computer readable code. The computer program may be transmitted from the first computing device to the second computing device through a network such as the Internet, installed in the second computing device, and thus used in the second computing device. The first computing device and the second computing device include both a server device, a stationary computing device such as a desktop PC, and a mobile computing device such as a notebook computer, a smart phone, and a tablet PC.

The computer program loads a white box cryptographic module into a memory provided in the computing device, and starts data for starting encryption/decryption of the white box cryptographic module at run-time of the white box cryptographic module. It may be to determine , using data obtained at runtime, and to execute an operation that initiates an encryption/decryption operation of the whitebox cryptographic module using the start data. The computer program may be stored in a recording medium such as a DVD-ROM or a flash memory device, but may also be distributed over a network.

The computer program may be implemented as a module in a mobile device operating system such as Android or iOS.

Hereinafter, the configuration and operation of the white box encryption apparatus 200 according to another embodiment of the present invention will be described with reference to FIG. 6 . Referring to FIG. 6 , the white box encryption device 200 according to the present embodiment includes a communication interface 205, a data input/output unit 210, a white box encryption unit 215, a hardening unit 220, and a user information interface ( 225) may be included.

The communication interface 205 receives data to be encrypted or decrypted from an external device and provides it to the data input/output unit 210 . Also, the communication interface 205 receives encrypted or decrypted data from the data input/output unit 210 and transmits it to an external device.

The data input/output unit 210 connects data transmission and reception between the communication interface 205, the user interface 225, the white box encryption unit 215, and the hardening unit 220.

The white box encryption unit 215 may encrypt or decrypt data provided from the data input/output unit 210 using a white box encryption method. The white box encryption unit 215 generates an initialization vector necessary for starting encryption/decryption through the white box encryption unit at runtime when the white box encryption unit is executed, and generates the initialization vector using data obtained at runtime. can do. User-dependent data input to the runtime through the user interface 225 may be used to generate the initialization vector. Since the generation of the initialization vector has already been described in detail, a redundant description will be omitted.

The hardening unit 220 includes a module for supplementing the white box encryption method. The hardening unit 220 may include an anti-debugging module 222 , an obfuscation module 224 , and an integrity verification module 225 . The hardening unit 220 can bring the effect of enhancing security by supplementing the weakness of the white box encryption technology.

The anti-debugging module 222 may perform a function of preventing debugging and analysis when a cracker application attempts to debug the operation of the white box encryption unit 215 . If the binary of the white box encryption unit 215 is being debugged, analysis may be interrupted using various methods such as terminating the corresponding debugger program or generating an error.

Debuggers usually stop program execution by setting breakpoints in desired code, examine values stored in memory, resume execution, or step through code. When a cracker debugs a whitebox cryptographic module, it can stop performing encryption and decryption and view the values loaded into memory. In this case, start data received at runtime may be leaked. If the starting data is leaked, the cracker will be able to load the entire whitebox cryptographic module into the memory of another computing device and input the leaked starting data while running the whitebox cryptographic module in debugging mode. The anti-debugging module 222 detects such an operation of the debugger and immediately performs an operation such as stopping the execution of the white box cryptographic module.

The obfuscation module 224 performs a binary obfuscation function of obfuscating the binary of the white box cryptographic module. The binary of the whitebox cryptographic module may be obfuscated by the obfuscation module 224 and then loaded into the memory. At this time, even if the operation of the anti-debugging module 222 is disabled and the white box cryptographic module operates in the debugging mode, it is difficult to decipher the obfuscated binary. Therefore, the obfuscation module 224 prevents a cracker from leaking the start data by decrypting the binary of the white box cryptographic module through reverse engineering technology or the like.

The integrity verification module 225 verifies whether the binary of the white box cryptographic module is original. That is, the integrity verification module 225 verifies whether the binary of the white box cryptographic module has been manipulated by a cracker.

The integrity verification module 225 may verify integrity at least once during runtime of the white box cryptographic module. For example, integrity may be verified before and after determining the start data, integrity may be verified before and after induction of an initialization vector, or integrity may be verified before and after performing encryption/decryption. The integrity verification module 225 stores evaluation information on the original binary of the white box cryptographic module, for example, a hash value, and uses the stored evaluation information to store the integrity of the binary of the white box cryptographic module loaded into the memory. can be verified.

So far, security enhancement embodiments that can be additionally applied to some embodiments of the present invention to compensate for the weakness of the white box encryption technology have been looked at. Each module of the above-described hardening unit 220 may be updated in response to a software update or may be replaced with a new module. When security logic such as encryption/decryption is executed by relying on a hardware security element according to the prior art, even if a vulnerability is found in the hardware security element, it is not easy to compensate. On the other hand, according to some embodiments of the present invention, since the security logic is performed through a software security element implemented through a general-purpose processor and a general-purpose memory without using a hardware security element at all, the security element implemented in software is vulnerable to vulnerabilities. Complementary to this is possible through the distribution and installation of software, which has the advantage of easy maintenance.

A software architecture in which a method according to some embodiments of the present invention is implemented is described below with reference to FIG. 7 .

The method according to some embodiments of the present invention described with reference to FIGS. 4 to 6 includes all modules in one application, and may be implemented in an application-dependent manner.

However, according to some embodiments of the present invention, the white box cryptographic module is provided in the form of an application-independent library, and each application (or, in this specification, the term APP indicating an application executed on a mobile device) Also used) may be implemented in a form of performing security logic by calling an application programming interface (API) provided by the library. 7 shows a white box encryption library 240 as an example of the library.

In the software architecture shown in FIG. 7, the security logic is performed in the whitebox cryptographic library 240, and other operations, such as user interface and communication with external devices through the network interface 250, are performed by each app. (230a, 230b, 230c) is in charge.

At the request of the apps 230a, 230b, and 230c, the whitebox cryptographic library 240 determines start data, performs an operation to initiate encryption/decryption using the start data, and returns the result to the app 230a. , 230b, 230c).

The whitebox cryptographic library 240 may include cryptographic functions. When the apps 230a, 230b, and 230c call the encryption function, the encryption function queries the identifier of the whitebox encryption device 200, obtains user-dependent information through the apps 230a, 230b, and 230c. , deriving an initialization vector using at least one of the identifier and the user-dependent information, starting encryption of the original text using the initialization vector, and performing a return operation when the encryption of the original text is completed.

The whitebox encryption library 240 may further include a decryption function. When the apps 230a, 230b, and 230c call the decryption function, the decryption function searches for the identifier of the white box encryption device 200, obtains user-dependent information through the apps 230a, 230b, and 230c. , deriving an initialization vector using at least one of the identifier and the user-dependent information, starting decryption of ciphertext using the initialization vector, and returning when decryption of the ciphertext is completed.

The encryption function and the decryption function may be provided in various types according to the type of start data used to derive the initialization vector. As already described above, according to some embodiments of the present invention, various data are obtained at runtime of the whitebox encryption library 240, and the starting data is determined at runtime of the whitebox encryption library 240 using the obtained data. do. Security can be strengthened as the data obtained at runtime is used more, but the required level of this security will vary depending on the apps 230a, 230b, and 230c. Accordingly, various types of encryption/decryption functions may be provided to satisfy various security requirements.

For example, in the case of an APP having a transportation card payment function, it is important to quickly complete fare payment and the amount to be paid is relatively small, so it is only necessary to prevent unauthorized use by multiple mobile devices by cracking. will be. That is, the starting data may be determined using only the identifier of the whitebox encryption device 200 without user-dependent information such as a password. Therefore, in the case of an APP having a transportation card payment function, an encryption/decryption function of a type that determines the starting data using only the identifier of the device may be used.

Illustrates a situation that requires a high level of security. For example, considering a situation in which a large amount of money is transferred in a mobile banking APP, it is desirable to check a plurality of information to confirm that the transfer is not fraudulent even if the user is somewhat uncomfortable. For example, it may be desired to perform encryption/decryption by reflecting all of the identifier of the user's mobile device, a password designated by the user in advance, and the user's biometric information. Even in this case, the mobile banking APP uses a type of encryption/decryption function that determines start data by reflecting all of the identifier of the user's mobile device, a password pre-specified by the user, and the user's biometric information, thereby satisfying a high security level. can make it

The above operation is performed by the whitebox cryptographic library 240 itself without involvement of the apps 230a, 230b, and 230c. In addition, as already described, the whitebox cryptographic library 240 has various anti-cracking functions such as anti-debugging, obfuscation, and integrity verification. Accordingly, it is very difficult for the apps 230a, 230b, and 230c to manipulate the initialization vector.

The whitebox encryption library 240 is a content encryption/decryption application or data encryption/decryption application that requires an encryption/decryption function, and an e-commerce payment application that performs an authentication procedure based on the encryption/decryption function. Alternatively, it may be used for an application having a user authentication function.

The whitebox cryptographic library 240 may be embedded and installed together with the applications, or may be dynamically called and used by the applications while already installed in the whitebox cryptographic device 200 separately from the applications. there is.

Also, in some embodiments, the whitebox cryptographic library 240 may be configured as one of specialized modules of an operating system installed in the whitebox cryptographic device 200 .

Hereinafter, some embodiments of the present invention in which white box encryption/decryption is applied to a payment process will be described. As shown in FIG. 7 , the white box encryption device 200 may perform a payment process by being connected to the payment server 20 through a network. Hereinafter, it will be described with reference to FIG. 8 . 8 shows that when the user of the white box cryptographic device 200 performs a payment process with the payment server 20 using the mobile payment apps 230a, 230b, and 230c, the whitebox cryptographic device 200 It is a signal flow diagram indicating what operation each component of is performing for the payment process.

First, the network interface 250 receives a payment request and payment information from the payment server 20 (S300). The payment information includes information on a payment amount. The payment information may additionally include additional information about an affiliated store name, a product name, and the like. The network interface 250 transmits the payment request and payment information to the mobile payment apps 230a, 230b, and 230c (S305). The mobile payment app (230a, 230b, 230c) may obtain the user's confirmation of the progress of the payment process while displaying a user message requiring confirmation (confirm) for the payment information (S310). At this time, the user can check payment information including product name information and price information in response to the confirmation request, and input payment method information including payment card type.

Mobile payment apps (230a, 230b, 230c) are payment information including product information, payment amount, installment month number or payment member information, user's identity information, card company information, card number, expiration date, CVV (Card Verification Value) ) and the like, and generates payment request information including at least one of user identity information, and requests the whitebox cryptographic library 240 to generate payment authentication data using the payment request information. . That is, the mobile payment apps 230a, 230b, and 230c provide the payment request information to the whitebox cryptographic library 240 (S315).

The whitebox cryptographic library 240 verifies the integrity of the whitebox cryptographic library binary or verifies whether a software platform such as an operating system is the same as a licensed one (S320). If there is a problem in the process of checking the security environment, data indicating failure may be provided to the mobile payment apps 230a, 230b, and 230c.

The whitebox cryptographic library 240 must determine starting data to perform whitebox cryptography. As already described above, the start data may be determined using at least one of user dependent information and identifier information of a white box encryption device. The user-dependent information may be a password previously registered in the payment server 20 or biometric information. The whitebox cryptographic library 240 obtains the user-dependent information through the mobile payment apps 230a, 230b, and 230c (S325, S330, and S335), or the whitebox cryptographic library 240 itself obtains the user-dependent information. It is possible to obtain the user-dependent information by generating a user interface for input of (not shown).

The whitebox cryptographic library 240 additionally queries device-dependent data to determine the starting data. For example, the whitebox encryption library 240 searches identifier information of the whitebox encryption device 200, such as MAC address and IMEI information.

What is important here is that the acquisition of the user-dependent information and the acquisition of the device-dependent data must be performed at runtime of the whitebox encryption library 240 .

Next, the whitebox cryptographic library 240 generates an initialization vector using the start data (S345). Since the function of the initialization vector has already been described, redundant description will be omitted. What is important here is that the generation of the initialization vector must also be performed at runtime of the whitebox cryptographic library 240. In an embodiment, the whitebox cryptographic library 240 may apply a hash function to at least some data of the starting data and generate the initialization vector using the hash value.

The whitebox encryption library 240 generates payment authentication data by performing whitebox encryption using the initialization vector (S350). For example, the payment authentication data may be encrypted text of the payment request information or data encoded according to a rule shared with the payment server 20 in addition to the encrypted text.

Before providing the payment authentication data to the mobile payment apps 230a, 230b, and 230c, the whitebox cryptographic library 240 additionally performs a security environment check procedure (S355), and determines that there is a problem with the secure environment check procedure. If determined, a signal indicating failure may be output without providing the payment authentication data. The additional security environment confirmation procedure may include at least one of procedures such as verifying the integrity of the whitebox cryptographic library binary or verifying whether a software platform such as an operating system is the same as a licensed one.

When the starting data is determined, the mobile device may execute white box encryption and encrypt the payment request information. Accordingly, encrypted payment authentication data may be generated (S335). When the mobile device generates encrypted payment authentication data, it can transmit the payment authentication data to the outside (S340).

The payment authentication data is transmitted to the payment server 20 (S360, S365, S370). Although not shown in FIG. 8 , the mobile payment apps 230a , 230b , and 230c may additionally provide the payment request information to the payment server 20 . The payment server 20 verifies the payment authentication data, and approves or rejects the payment according to the result (S375). For example, when the start data is entered correctly and when at least one of the start data is entered as an incorrect value, the payment authentication data is generated with a different value of 1 bit or more, and the payment server ( 20) will be able to verify this. This is because the payment server 20 may have previously registered device-dependent information and user-dependent information for each user.

Hereinafter, a process in which an off-line payment is performed will be described with reference to FIGS. 9 to 10 . The payment process described with reference to FIGS. 7 to 8 assumes an online situation. However, for example, if you want to pay a bus fare, you must be able to pay the fare even if the bus is in a communication shaded area. Several embodiments of the present invention described with reference to FIGS. 9-10 make this possible.

What is needed for offline payment is a short-range communication interface 260 and offline payment apps 230a, 230b, and 230c implemented to perform offline payment using the short-range communication interface 260. The operation of the whitebox cryptographic library 240 is not different from that previously described.

A process of paying with a mobile device through an offline payment terminal will be described as an example. The payment terminal 150 and the white box encryption device 200 may communicate through communication means such as NFC, Bluetooth, RFID, and BLE. For example, in the case of card payment through NFC communication, the payment terminal 150 performs APDU (Application Protocol Data Unit) communication defined in ISO/IEC 7816-4 to form a communication channel with the short-range communication interface 260 to A payment request and payment information may be transmitted to the white box encryption device 200 .

10 shows a signal flow diagram similar to that of FIG. 8 . It can be seen that only the payment server 20 of FIG. 8 has been replaced with the payment terminal 150, and other signal flows are the same. However, in relation to the operation of receiving information dependent on the user (S325, S330, S335), depending on the security level required by the mobile payment apps 230a, 230b, 230c, receiving the information dependent on the user is repeated. being can be alleviated. Requiring user input for each transaction may be inconvenient for the user and may cause payment delay, so for a certain time after user input or during a certain number of transactions in consideration of the target environment, information dependent on the user was previously stored Information can be reused.

Hereinafter, the hardware configuration and operation of the white box encryption apparatus 200 according to an embodiment of the present invention will be described. The whitebox encryption device 200 may be, for example, a computing device such as a mobile device or a PC. Hereinafter, a case where the whitebox encryption device 200 is a mobile device such as a smart phone, a smart watch, or a wearable device will be described as an example.

The white box encryption device 200 includes a processor 290 such as a general-purpose AP, a network interface 250 responsible for access to the Internet and a wireless mobile communication network, and a short-range communication interface 260 responsible for short-range communication such as NFC. ), a storage 270 and a RAM 295 for storing binaries of software according to some embodiments of the present invention and data referenced or recorded during the execution of the binaries.

The RAM 295 includes binaries 297 of the whitebox cryptographic library and binaries of one or more mobile apps 230a, 230b, and 230c that perform operations requiring data encryption/decryption using the binaries 297 of the whitebox cryptographic library. can be loaded. The binary loaded into the RAM 295 is fetched and executed by the general purpose AP 290 .

The whitebox cryptographic library 297 is loaded into the non-secure address area of the RAM 295, and the whitebox cryptographic library 297 does not have a hardware secure element for the whitebox cryptographic library 297. It runs on the general purpose AP 290.

As already described, the white box cryptographic library 297 generates an initialization vector necessary for performing a white box encryption/decryption operation at runtime of the white box cryptographic library 297, and the initialization vector stores data obtained at runtime. induce using

In some embodiments, it has already been described that the white box cryptographic library 297 may be configured in the form of some modules of an operating system (not shown) installed in the white box cryptographic device 200 .

Although the embodiments of the present invention have been described with reference to the accompanying drawings, those skilled in the art to which the present invention pertains can be implemented in other specific forms without changing the technical spirit or essential features of the present invention. you will be able to understand Therefore, the embodiments described above should be understood as illustrative in all respects and not limiting.

Claims (11)

loading, by a computing device, a white box cryptographic module into a memory provided in the computing device;
Where the computing device determines start data for starting encryption/decryption of the whitebox cryptographic module using data related to an execution environment of the whitebox cryptographic module obtained at run-time of the whitebox cryptographic module. step - the data related to the execution environment is information subordinate to the computing device and is irrelevant to data subject to encryption/decryption; and
Initiating, by the computing device, an encryption/decryption operation of the whitebox cryptographic module using the start data,
Encryption/decryption method using whitebox password. According to claim 1,
The execution environment related data obtained at the runtime,
Further comprising information input through a user interface at the runtime,
Encryption/decryption method using whitebox password. According to claim 1,
The execution environment related data obtained at the runtime,
Further comprising information dependent on the user of the computing device,
Encryption/decryption method using whitebox password. According to claim 1,
Information dependent on the computing device,
A unique identifier of the computing device,
Encryption/decryption method using whitebox password. According to claim 3,
Information dependent on the user of the computing device,
Including at least one of the user's pre-registered security information and the user's biometric information,
Encryption/decryption method using whitebox password. According to claim 1,
The step of initiating the encryption/decryption operation of the white box cryptographic module,
deriving an initialization vector (IV) of the whitebox cryptographic module using the starting data; and
Initiating an encryption/decryption operation of the white box cryptographic module using the initialization vector,
Encryption/decryption method using whitebox password. According to claim 1,
The step of loading into the memory is,
loading the whitebox cryptographic module into a non-secure address area of the memory;
The white box cryptographic module is executed in a general-purpose processor included in the computing device,
The general purpose processor does not have a hardware secure element for the white box cryptographic module,
Encryption/decryption method using whitebox password. According to claim 1,
The white box cryptographic module includes an anti-debugging operation for preventing the execution environment related data obtained at runtime from being replaced with other data.
Encryption/decryption method using whitebox password. In the payment authentication method performed by a general-purpose processor of a computing device,
Receiving payment request information including payment amount information from an external device;
loading a white box cryptographic module into a memory provided in the computing device;
Deriving an initialization vector for starting encryption of the white-box cryptographic module using execution environment-related data of the white-box cryptographic module obtained at run-time of the white-box cryptographic module - the execution environment-related data contains an identifier of the computing device unrelated to the target data of the encryption and user input data for the computing device, the user input data being data subordinate to a user of the computing device;
encrypting at least some of the payment request information of the white box encryption module using the initialization vector, and generating payment authentication data using the encrypted data; and
Transmitting the payment authentication data to the external device,
Payment verification method. According to claim 9,
The step of generating the payment authentication data,
generating first payment authentication data that is successfully processed by the external device when the identifier of the computing device and the user input data are correct data; and
If at least one of the identifier of the computing device and the user input data is incorrect data, generating second payment authentication data for which payment is rejected by the external device,
The first payment authentication data and the second payment authentication data are digital data different from each other by at least one bit,
Payment verification method. According to claim 9,
The step of loading into the memory is,
loading the whitebox cryptographic module into a non-secure address area of the memory;
The general purpose processor does not have a hardware secure element for the white box cryptographic module,
Payment verification method.

Images