KR20170095780A - Mobile device applying clark-wilson model and operating method thereof - Google Patents

Abstract

A method for operating a mobile device according to an embodiment of the present invention includes the steps of: performing a first XOR operation on first data and a first token in an application of a rich execution environment (REE); determining whether the first token is identical to the first token in the application; performing a second XOR operation on the second token and the result of the first XOR operation in an integrity assurance program; and determining the result of the second XOR operation to a trusted execution environment (TEE). Accordingly, the present invention can improve the reliability of the data.

Description

TECHNICAL FIELD [0001] The present invention relates to a mobile device employing a Clark Wilson model, and a mobile device employing the Clark Wilson model.

The present invention relates to a mobile device employing a Clark Wilson model and a method of operating the same.

The trusted execution environment (TEE) is the security area of the main processor. TEE protects internally loaded code and data with respect to confidentiality and integrity. An isolated execution environment, TEE provides security features such as the integrity of trusted applications and the confidentiality of assets. In general, TEE provides a higher level of security than a rich execution environment (REE) mobile operating system (mobile OS) and has an execution space that provides more functionality than a secure element (SE). TEE is a kind of virtualization space based on mobile device chips (SoCs).

Open Patent: 10-2016-0008012, Publication date: Jan. 21, 2016 Title: User authentication method in a mobile terminal. U.S. Published Patent: US 2017/0083882, Pub. No.:23, 2013, Title: Secure Payment Method and Electronic Device Adapted Thereto. Public number: 10-2016-0140159, Public date: December 07, 2016 Title: Electronic device and kernel data access method.

Ning Zhang and Kun Sun and Deborah Shands and Wenjing Lou and Y. Thomas Hou, "TruSpy: Cache Side-Channel Information Leakage from the Secure World on ARM Devices", http://eprint.iacr.org/2016/

It is an object of the present invention to provide a mobile device and an operation method thereof that improve the reliability of data.

A method of operating a mobile device according to an embodiment of the present invention includes: performing a first XOR operation on first data and a first token in an application of a rich execution environment (REE); Determining whether the first token and the second token are identical in the application; Performing a second XOR operation on the result of the first XOR operation and the second token in an integrity assurance program; And transmitting the result of the second XOR operation to a trusted execution environment (TEE).

The mobile device and its operation method according to the embodiment of the present invention store the data generated by the REE in the security area without storing the data directly in the security area and verified by the integrity guarantee program (IAP) Can be guaranteed.

In addition, the mobile device of the present invention and its method of operation can prevent potential hacker activity according to the method described above, and can maximize security.

BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings, which are included to provide a further understanding of the invention and are incorporated in and constitute a part of this application, illustrate embodiments of the invention and, together with the description, serve to explain the principles of the invention. However, the technical features of the present embodiment are not limited to the specific drawings, and the features disclosed in the drawings may be combined with each other to constitute a new embodiment.
1 is a diagram for explaining a general clark wilson model.
2 is an exemplary illustration of a mobile device 100 in accordance with an embodiment of the present invention.
3 is an exemplary diagram illustrating an integrity assurance operation of an IAP 150 according to an embodiment of the present invention.
4 is an exemplary diagram illustrating an integrity verification procedure (IVP) of an IAP 150 according to an embodiment of the present invention.
5 is a ladder diagram illustrating an exemplary token issuance process in an integrity assurance operation according to an embodiment of the present invention.
6 is a conceptual illustration of applying a Clark Wilson model to a mobile device according to an embodiment of the present invention.
FIG. 7 is an exemplary illustration of a method of operation of a mobile device 100 in accordance with an embodiment of the present invention.
8 is an exemplary illustration of a method of operation of a mobile device 100 in accordance with another embodiment of the present invention.

BRIEF DESCRIPTION OF THE DRAWINGS The above and other objects, features and advantages of the present invention will be more apparent from the following detailed description taken in conjunction with the accompanying drawings, in which: FIG.

The present invention is capable of various modifications and various forms, and specific embodiments are illustrated in the drawings and described in detail in the text. It is to be understood, however, that the invention is not intended to be limited to the particular forms disclosed, but on the contrary, is intended to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the invention. The terms first, second, etc. may be used to describe various components, but the components should not be limited by the terms.

The terms may be used for the purpose of distinguishing one component from another. For example, without departing from the scope of the present invention, the first component may be referred to as a second component, and similarly, the second component may also be referred to as a first component. It is to be understood that when an element is referred to as being "connected" or "connected" to another element, it may be directly connected or connected to the other element, . On the other hand, when an element is referred to as being "directly connected" or "directly connected" to another element, it should be understood that there are no other elements in between.

Other expressions that describe the relationship between components, such as "between" and "between" or "neighboring to" and "directly adjacent to" should be interpreted as well. The terminology used in this application is used only to describe a specific embodiment and is not intended to limit the invention. The singular expressions include plural expressions unless the context clearly dictates otherwise.

In this application, the terms "comprises" or "having" are intended to specify the presence of stated features, integers, steps, operations, components, parts, or combinations thereof, wherein one or more other features, , Steps, operations, components, parts, or combinations thereof, as a matter of course. Unless otherwise defined, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. Terms such as those defined in commonly used dictionaries should be construed as meaning consistent with meaning in the context of the relevant art and are not to be construed as ideal or overly formal in meaning unless expressly defined in the present application .

1 is a diagram for explaining a general clark wilson model.

Clark Wilson's integrity model provides the basis for analyzing integrity policies for designation and computing systems. This model is primarily concerned with formulating the concept of information integrity. Maintain information integrity by preventing data items of the system from being damaged due to errors or malicious intent.

The Clark Wilson model defines each data item and can be modified only through a small set of programs to enhance data integrity. This model uses the three-part relationship of a subject / program / object (the program is interchangeable with the transaction) known as a triple or access control triple. Within this relationship, a subject can not access an object directly, but only through a program.

This model contains many basic configurations that represent both data items and the processes that operate on those data items. The primary data type of the Clark Wilson model is the constrained data item (CDI). An integrity verification procedure (IVP) ensures that all CDIs in the system are valid in a particular state. A transaction that enforces an integrity policy is represented by a transformation procedure (TP). The TP receives the CDI or unconstrained data item (UDI) and generates the CDI. The TP must transition the system from one valid state to another valid state. The UDI represents the system input. The TP must ensure that all possible values of the UDI are converted (through authentication) to a "secure" CDI.

At the heart of the model is the concept of the relationship between an authenticated user (ie, a user) and a set of programs (eg, TP) that operate on a set of data items (eg, UDI and CDI). The components of such a relationship are taken together and are called the Clark Wilson triple. The model should also ensure that other entities are responsible for manipulating the relationships between subjects, transactions, and data items. As a simple example, a user who can authenticate or create a relationship must not be able to execute the program specified in that relationship.

The model consists of two rules: the authentication rule (C) and the enforcement rule (E). The following nine rules ensure the external and internal integrity of data items.

When the C1- IVP is executed, it is necessary to check that the CDI is valid.

For a C2-associated CDI set, the TP must translate the CDI from its valid state to another state. These TPs must be certified to work with a specific CDI, so there must be E1 and E2.

The E1- system must maintain a list of certified relationships and ensure that only the TPs authorized to run the CDI change the CDI.

The E2 system must associate users with each TP and CDI set. If the TP is "legitimate", you can access the CDI on your behalf. To do this, you need to keep track of the triple (user, TP, {CDI}) called "allowed relationships".

The C3- permissive relationship must meet the requirements of "separation of obligations". Authentication is required to track this.

The E3 system must authenticate all users attempting the TP. This is a login, not a TP request. You should keep logs for security purposes.

C4 - Every TP must add enough information to the log to reconstruct the operation. Once information is entered into the system, it does not need to be trusted or limited (that is, it may be a UDI).

A TP using C5 - UDI as input can only perform valid transactions for all possible UDI values. The TP accepts the CDI or rejects the UDI.

Finally, to prevent people from accessing the TP by changing their credentials: The authenticator of E4 - TP can change the list of entities associated with that TP.

Meanwhile, a mobile device having a trust zone can be assumed as a multi-level security system. For example, the first level security system may be interpreted as a trusted execution environment (TEE), and the second level security system may be interpreted as a rich execution environment (REE).

A mobile device according to an embodiment of the present invention may be implemented to apply a Clark Wilson model to such a multi-level security system for ensuring integrity. At this time, TEE and REE of the mobile device will be interpreted as a subject rather than an object as a general concept. In the following, REE will be called a 1-Level Virtual Subject and TEE will be a 2-Level Virtual Subject.

2 is an exemplary illustration of a mobile device 100 in accordance with an embodiment of the present invention. Referring to FIG. 2, mobile device 100 may include a REE 120, a TEE 140, an integrity assurance program (IAP) 150, and a memory device 160. The mobile device 10 may be, for example, a smartphone, a tablet personal computer, or a wearable device.

The REE 120, TEE 140, and IAP 150 shown in FIG. 2 may be implemented with at least one processor.

The processor may be configured to control at least one of the internal configurations of the mobile device 100 or to perform operations / data processing on the communication. In an embodiment, the processor may include at least one of a central processing unit (CPU), a graphics processing unit (GPU), an application processor (AP), and a communication processor (CP).

REE 120 may be implemented in hardware, software, or firmware, and may be implemented to provide a general execution environment. The REE 120 may include at least one application (APP), and a normal OS (operating system) 122.

The application (APP) can be implemented to provide the necessary service to the user. The application APP of the present invention is adapted to generate normal data ND to be stored in the normal area 162 of the memory device 160 and secure data SD to be stored in the secure area 164 of the memory device 160 Can be implemented.

Although not shown, the REE 120 may include a user authentication application. For example, the user authentication application may be run in the REE 110 to perform an authentication operation to the user. Here, the authentication operation can be performed in various forms or in various combinations based on the selection of the user or the choice of the service provider. The authentication action may be performed by a user (e.g., a password), what the user has (e.g., a digital fingerprint, a token, an authentic certificate, etc.), a user characteristic (physiological, psychological, A representative fingerprint, a face, an iris, a heart rate, etc.), or a combination of at least two of them. That is, the user authentication application can be implemented to perform multi-factor authentication. The user authentication application may be implemented to securely perform authentication operations through at least one security application (TAPP) of the TEE 140.

The normal OS 122 is a kernel that executes at least one application that provides services to the user in the REE 120. [ For example, the normal OS 122 may be an Android, an Android Wear, a Symbian OS, a Windows OS family, a Tizen, a Unix, a Linux, etc. . In an embodiment, the normal OS 122 may be updated from a third party after manufacturing the mobile device 10. In an embodiment, the normal OS 122 may include a virtual platform (e.g., a hypervisor) capable of running multiple operating systems simultaneously.

In addition, the normal OS 122 may include a trustzone driver (TZ). TZ is a kernel module loaded into the normal OS 122 and can relay communications between the application (APP) of the REE 120 and the application (TAPP) of the TEE 140. TZ may be implemented to allow secure access of TEE 140 by REE 120. It should be understood that a secure approach can basically meet the requirements of confidentiality, integrity, availability, and the like.

The TEE 140 may be implemented in hardware, software, or firmware and may be implemented to provide a level of protection against software attacks generated by the REE 120. The TEE 140 may control access / execution of sensitive applications that need to be isolated from the REE 120, i.e., at least one trusted application. The trusted application may be a security application (digital right management (DRM), bank, payment, corporate, etc.) that requires security running in the TEE 140. For example, a secure application (TAPP) may include a preloaded application, a native application, or a third party application.

In addition, the TEE 140 may include at least one security application (TAPP), and a secure OS 142. The secure application (TAPP) may be implemented to securely process the data required to perform the authentication operation of the REE 120. A non-identification processing operation of the authentication data, an encryption operation, a comparison operation, and the like necessary for the authentication operation can be performed in the security application (TAPP). On the other hand, it should be understood that the operation of the security application (TAPP) is not limited thereto.

In addition, the security application (TAPP) may perform a close operation with the IAP 150 to ensure the integrity of the data transmitted from the REE 120 to the TEE 140.

The secure OA 142 may drive the secure application (TAPP) at the TEE 140. Since the security OA 142 includes a secure kernel and the secure kernel is operated in a state of being physically / software protected from a malicious user, it is used for tasks requiring security such as key management. The secure kernel may include a virtual file system. When the security application (TAPP) calls the file function of the virtual file system, the virtual file system can safely store / load / delete the file system of the REE 120 after performing the operation such as encryption / decryption internally .

The integrity assurance program (IAP) 150 may be implemented to ensure the integrity of data when data generated in the REE 120 is transmitted to the TEE 140. For example, the IAP 150 may be implemented to apply the Clark Wilson model described in FIG.

The IAP 150 may be a program trusted by the TEE 140. The trustworthiness of the IAP 150 may be determined by communication with the security application (TAPP) of the TEE 140. In an embodiment, the IAP 150 may be driven on the normal OA 122 of the REE 120. In another embodiment, the IAP 150 may be run on the virtualized OA implemented by the normal OA 122 of the REE 120. On the other hand, it should be understood that the driving of the IAP 150 is not limited to such OA. A separate OA for driving the IAP 150 may be provided.

In an embodiment, the IAP 150 may issue a token to assist integrity assurance in conjunction with the TAPP of the TEE 140.

In an embodiment, IAP 150 receives modified security data (TSD) and tokens transmitted from the APP of REE 120, verifies security data SD, and generates verified security data (VSD) . ≪ / RTI > The modified security data TSD is a modification of the secure data SD using the token in the APP of the REE 120. [

The IAP 150 receives the modified TSD and the token in the APP of the REE 120 and uses the token to decrypt the secure data SD contained in the modified secure data TSD Integrity can be verified.

The memory device 160 may be implemented as a volatile / non-volatile memory device. In an implementation, the memory device 160 may be a volatile memory device. For example, the memory device 160 may be a dynamic random access memory (DRAM), a static random access memory (SRAM), a dual line memory module (DIMM), or the like. In another embodiment, the memory device 160 may be a non-volatile memory device. For example, the memory device 160 may be a NAND flash memory, a vertical NAND (VNAND), a NOR flash memory, a resistive random access memory (RRAM) A phase change memory (PRAM), a magnetoresistive random access memory (MRAM), a ferroelectric random access memory (FRAM), a spin transfer random access memory (STT) -RAM), 3D Xpoint memory, and the like. In yet another embodiment, the memory device 160 may be a hybrid memory device comprised of a volatile memory device and a non-volatile memory device. For example, the memory device 160 may be a nonvolatile dual line memory module (NVDIMM), a hybrid memory cube (HMC), or the like.

In addition, the memory device 160 may include a normal area 162 and a security area 164. The normal area 162 is an area that can be accessed by the REE 120 and the security area 164 is an area that can be accessed by the TEE 140. [ In addition, the secure area 164 may include a secure area for storing secure data (SD) or for storing encryption / decryption data.

In practice, the normal data (ND) generated in the APP of the REE 120 in the normal area 162 may be stored via the normal OS 122.

In an embodiment, security data SD of the REE 120 may be stored indirectly with the help of the IAP 150 in the secure area 164. The stored security data SD is not the original security data SD generated by the REE 120 but the verified security data VSD verified by the IAP 150.

2, REE 120 is a first level virtualization subject, normal area 162 is a first level virtualization object, and TEE ( 140 is a second level virtualization subject, and security area 164 is a second level virtualization object. The first level virtualization entity (REE) can transmit integrity guaranteed data (VSD) to a second level virtualization entity (TEE) using an IAP (integrity assurance program). The second level virtualization entity (TEE) can store the thus guaranteed data (VSD) in the second level virtualization object (security area).

In a REE environment, a typical mobile device can access the security area freely only if it receives legitimate authentication in a TEE environment. For example, a typical mobile device is performing access control only in a module such as a trust zone on a normal OA. However, legitimate authentication may also contain malicious information (viruses, spyware, malware, etc.) in the data sent to the REE. In this case, the TEE environment can be disabled by a hacker.

The mobile device 100 according to the embodiment of the present invention does not store the data SD generated in the REE 120 directly in the secure area 164 but transmits the data verified by the IAP 150 May be stored in the secure area 164 to ensure the integrity of the transmitted data. The mobile device 100 of the present invention can block potential hacker activity and maximize security.

On the other hand, the above-described integrity assurance operation can be implemented by an XOR (exclusively or) operation.

3 is an exemplary diagram illustrating an integrity assurance operation of an IAP 150 according to an embodiment of the present invention. 2 to 3, the integrity assurance operation can proceed as follows.

The APP of the REE 120 may generate the original data SD to be stored in the secure area 164. At this time, the APP of the REE 120 can request token issuance for integrity guarantee from the IAP 150 and receive the issued token. The APP of the REE 120 may generate modified data (UDI: TSD) by performing a first XOR operation on the original data SD and the token. Here, the process of generating the modified data TSD is referred to as a transformation process TP.

The REE 120's APP may then send the modified data (TSD) and the token to the IAP 150. IAP 150 receives modified data (TSD) and tokens from the APP of REE 120 and generates validated data (CDI: VSD) by performing a second XOR operation on the received modified data (TSD) and tokens . The verified data (VSD) will be the original data. Verified data (VSD) may be stored in security area 164.

4 is an exemplary diagram illustrating an integrity verification procedure (IVP) of an IAP 150 according to an embodiment of the present invention. Referring to FIG. 4, IAP 150 may perform integrity verification of received data by comparing a first token received from an APP of REE 120 with an internal second token.

5 is a ladder diagram illustrating an exemplary token issuance process in an integrity assurance operation according to an embodiment of the present invention. 2 to 5, the token issuing process for the integrity assurance operation may proceed as follows.

The REE 120's APP may request the IAP 150 to access the secure area 164. IAP 150 may receive an access request for this APP and send an authentication request to APP. The APP may send the biometric code to the IAP 150 via ID / password entry or biometrics by the user in response to the authentication request. The IAP 150 may request token issuance while transmitting the received ID / password or biometric code to the TAPP of the TEE 140. [ TAPP responds to these requests by first authenticating that the APP is a legitimate user and issuing and storing the token if the APP is a legitimate user. The legitimate user of the APP can be accomplished through an ID / password or biometric code verification process. The related authentication information may be stored in the TEE 140. In an embodiment, the issued token may include valid time information. The token issued by the TAPP may be sent to the IAP 150. The IAP 150 may send the transmitted token to the APP of the REE 120.

6 is a conceptual illustration of applying a Clark Wilson model to a mobile device according to an embodiment of the present invention. Referring to FIG. 6, the first subject S1 is the REE 120 and may have unconstrained data items (UDIs) and tokens. By performing an integrity verification procedure at the IAP 150, a constrained data item (CDI1) of the first subject S1 can be generated. The first restricted data item (CDI1) may be stored in object (0, 164). In addition, the second restricted data item CDI2 of the second subject S1 may be stored in the object O.

On the other hand, the function of the IAP 150 shown in FIG. 2 described above may be performed within the TEE.

FIG. 7 is an exemplary illustration of a method of operation of a mobile device 100 in accordance with an embodiment of the present invention. 2 to 7, a method of operating the mobile device 100 is as follows.

In response to an access request from the APP of the REE 120 to the secure area 164, the TEE 140 may perform an authentication operation (S110). The TEE 140 may receive the corresponding token (S120). The APP of the REE 120 may transform the data using the token (S130). The APP of the REE 120 may transmit the modified data and the token to the TEE 140 (S140).

8 is an exemplary illustration of a method of operation of a mobile device 100 in accordance with another embodiment of the present invention. 2 to 8, a method of operating the mobile device 100 is as follows.

In response to the token issue request of IAP 150, TEE 140 may generate a token (S210). The generated token may be sent to the REE 120 (S220). The TEE 140 may receive modified data and tokens from the REE 120 (S230). It may be determined whether the received token is the same as the generated token (S240). If the received token is the same as the generated token, the original data may be extracted from the modified data using the token (S250).

The steps and / or operations in accordance with the present invention may occur in different orders, in parallel, or concurrently in other embodiments for other epochs or the like, as may be understood by one of ordinary skill in the art .

Depending on the embodiment, some or all of the steps and / or operations may be performed on one or more non-transitory computer-readable media, including instructions, programs, interactive data structures, At least some of which may be implemented or performed using one or more processors. The one or more non-transitory computer-readable media can be, by way of example, software, firmware, hardware, and / or any combination thereof. Further, the functions of the "module" discussed herein may be implemented in software, firmware, hardware, and / or any combination thereof.

One or more non-transitory computer-readable media and / or means for implementing / performing one or more operations / steps / modules of embodiments of the present invention may be implemented as application-specific integrated circuits (ASICs), standard integrated circuits, But are not limited to, controllers that perform appropriate instructions, including microcontrollers, and / or embedded controllers, field-programmable gate arrays (FPGAs), complex programmable logic devices (CPLDs) .

The above-described contents of the present invention are only specific examples for carrying out the invention. The present invention will include not only concrete and practical means themselves, but also technical ideas which are abstract and conceptual ideas that can be utilized as future technologies.

100: mobile device
120: REE
122: Normal OS
140: TEE
142: Security OS
150: IVP
160: memory device

Claims (1)

A method of operating a mobile device, comprising:
Performing a first XOR operation on the first data and the first token in an application of a rich execution environment (REE);
Determining whether the first token and the second token are identical in the application;
Performing a second XOR operation on the result of the first XOR operation and the second token in an integrity assurance program; And
And sending the result of the second XOR operation to a trusted execution environment (TEE).

Images