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

Abstract

According to an embodiment of the present invention, a method of operating a mobile device may include performing a first XOR operation on first data and a first token in an application of a rich execution environment (REE), wherein the first token and the first token are used in the application. Determining whether two tokens are equal, performing a second XOR operation on the second XOR operation with a result value of the first XOR operation in an integrity guarantee program, and TEE (trusted) the result value of the second XOR operation; execution environment).

Description

MOBILE DEVICE APPLYING CLARK-WILSON MODEL AND OPERATING METHOD THEREOF}

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

TEE (trusted execution environment) 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 trusted application integrity and asset confidentiality. In general, TEEs have an execution space that provides a higher level of security than a rich execution environment (REE) mobile operating system (mobile OS) and more functionality than a secure element (SE). TEE is a kind of virtualization space based on a system of chip (SoC) of a mobile device.

Publication No. 10-2016-0008012, published date: January 21, 2016, the title: user authentication method in a mobile terminal. United States Patent Application Publication US 2017/0083882, Publication No. March 23, 2017 Title: Secure Payment Method and Electronic Device Adapted Thereto. Publication No. 10-2016-0140159, Publication date: December 7, 2016, Title: Electronic Devices and Kernel Data Access Methods.

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 a method of operation thereof for improving 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 the same in the application; Performing a second XOR operation on the result value of the first XOR operation and the second token in an integrity guarantee program; And transmitting a result value of the second XOR operation to a trusted execution environment (TEE).

The mobile device and its operation method according to an embodiment of the present invention does not store data generated in the REE directly in the secure area, but stores the data verified by the integrity guarantee program (IAP) in the secure area. Can ensure the integrity of

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

BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings are provided to facilitate understanding of the present embodiment, and provide embodiments with a detailed description. 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 a diagram illustrating a mobile device 100 according to an embodiment of the present invention.
3 is a diagram illustrating the integrity guarantee operation of the IAP 150 according to an embodiment of the present invention.
4 is a diagram illustrating an integrity verification process (IVP) of the IAP 150 according to an embodiment of the present invention.
5 is a ladder diagram illustrating a token issuance process in an integrity guarantee operation according to an embodiment of the present invention.
6 is a diagram conceptually illustrating the application of the Clark Wilson model to a mobile device according to an embodiment of the present invention.
7 is a diagram illustrating a method of operating the mobile device 100 according to an embodiment of the present disclosure.
8 is a diagram illustrating a method of operating the mobile device 100 according to another embodiment of the present disclosure.

DETAILED DESCRIPTION Hereinafter, the contents of the present invention will be described clearly and in detail so that those skilled in the art can easily implement the drawings.

As the inventive concept allows for various changes and numerous embodiments, particular embodiments will be illustrated in the drawings and described in detail in the text. However, this is not intended to limit the present invention to a specific disclosed form, it should be understood to include all modifications, equivalents, and substitutes included in the spirit and scope of the present invention. Terms such as first and second 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 component. For example, without departing from the scope of the present invention, the first component may be referred to as the second component, and similarly, the second component may also be referred to as the first component. When a component is referred to as being "connected" or "connected" to another component, it may be directly connected to or connected to that other component, but it may be understood that another component may be present in the middle. Should be. On the other hand, when a component is said to be "directly connected" or "directly connected" to another component, it should be understood that there is no other component in between.

Other expressions describing the relationship between components, such as "between" and "immediately between" or "neighboring to" and "directly neighboring", should be interpreted as well. The terminology used herein is for the purpose of describing particular example embodiments only and is not intended to be limiting of the invention. Singular expressions include plural expressions unless the context clearly indicates otherwise.

In this application, the terms "comprise" or "having" are intended to indicate that there is a feature, number, step, action, component, part, or combination thereof that is implemented, and that one or more other features or numbers are present. It should be understood that it does not exclude in advance the possibility of the presence or addition of steps, actions, components, parts or combinations thereof. Unless defined otherwise, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by one of ordinary skill in the art. Terms such as those defined in the commonly used dictionaries should be construed as meanings consistent with the meanings in the context of the related art and shall not be construed in ideal or excessively formal meanings unless expressly defined in this application. .

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

Clark Wilson's integrity model provides the foundation for analyzing integrity policies for specified and computing systems. This model is primarily concerned with formulating the concept of information integrity. Information integrity is maintained by preventing data items in the system from being corrupted due to errors or malicious intentions.

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 a three-part relationship of subjects / programs / objects (programs can interchange with transactions), known as triples or access control triples. Within this relationship, the subject cannot directly access the object, but only through the program.

This model includes many basic constructs that represent both data items and the processes that operate on them. 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). TP generates CDI by receiving CDI or unconstrained data item (UDI). The TP must transition the system from one valid state to another. UDI stands for system input. The TP must ensure (via authentication) that all possible values of UDI are converted to "safe" CDI.

At the heart of the model is the concept of a relationship between an authenticated user (i.e. user) operating on a series of data items (e.g. UDI and CDI) and a series of programs (e.g. TP). The components of such a relationship are taken together and called the Clark Wilson Triple. The model must also ensure that other subjects 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 should not be able to run the program specified in that relationship.

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

Once C1-IVP is executed, you should check that the CDI is valid.

In the case of a C2-associated CDI set, the TP must transition the CDI from valid state to another state. These TPs must be E1 and E2 because they must be certified to work with a particular CDI.

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

The E2 system must associate a user with each TP and CDI set. The TP may access CDI on behalf of the user if it is "legal". This requires keeping track of the triples (user, TP, {CDI}) called "permitted relationships".

C3- Permitted relationships must meet the requirements of "segregation of duties". To track this, authentication is required.

The E3 system must authenticate all users attempting TP. This is a login, not a TP request. Logs should be kept for security purposes.

C4-All TPs should add enough information to the log to reconstruct their work. Once the information is entered into the system, it doesn't need to be trusted or restricted (i.e. it can be UDI).

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

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

On the other hand, a mobile having a trust zone may assume that the device is a multi level security system. For example, a first level security system may be interpreted as a trusted execution environment (TEE), and a second level security system may be interpreted as a rich execution environment (REE).

The mobile device according to an embodiment of the present invention may be implemented to apply the Clark Wilson model to such a multi-level security system to ensure integrity. In this case, TEE and REE of a mobile device are general concepts and will be interpreted as a subject, not an object. In the following, REE is referred to as a first-level virtual subject, and TEE is referred to as a second-level virtual subject.

2 is a diagram illustrating a mobile device 100 according to an embodiment of the present invention. Referring to FIG. 2, the mobile device 100 may include an 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, the TEE 140, and the IAP 150 illustrated in FIG. 2 may be implemented with at least one processor.

The processor may be implemented to control at least one internal components of the mobile device 100 or to execute processing / data relating to communication. In an embodiment, the processor may include at least one of a central processing unit (CPU), a graphic processing unit (GPU), an application processor (AP), and a communication processor (CP).

The 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 operating system 122.

The application APP may be implemented to provide a service required by the user. The application APP of the present invention generates the normal data ND to be stored in the normal area 162 of the memory device 160 and the security data SD to be stored in the security area 164 of the memory device 160. Can be implemented.

Although not shown, the REE 120 may include a user authentication application. For example, a user authentication application can be driven in the REE 110 to perform an authentication operation on the user. The authentication operation may be performed in various forms or in various combinations based on the user's selection or the service provider's selection. Authentication operations include what the user knows (e.g. a password), what the user has (e.g. digital fingerprints, tokens, certificates, etc.), user characteristics (physiological, psychological, behavioral, etc.); Fingerprint, face, iris, heart rate, etc.), or a combination of at least two of them. In other words, the user authentication application may be implemented to perform multi-factor authentication. The user authentication application may be implemented to securely process the authentication operation 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 a service to a user in the REE 120. For example, the normal OS 122 may be Android, Android Wear, Symbian OS, Windows OS family, Tizen, Unix, Linux, or the like. . In an embodiment, the normal OS 122 may be updated from a third party after the mobile device 10 is manufactured. In an embodiment, the normal OS 122 may include a virtual platform (eg, a hypervisor) capable of simultaneously driving a plurality of operating systems.

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

The TEE 140 may consist of hardware, software, or firmware, and may be implemented to provide a level of protection from software attacks generated by the REE 120. The TEE 140 may control access / execution of sensitive applications, ie, at least one trusted application, that need to be isolated from the REE 120. The trusted application may be a security application (DRM (digital right management), bank, payment, corporate, etc.) that requires security running in the TEE 140. For example, the security 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 secure application (TAPP) and a secure OS 142. The security application TAPP may be implemented to securely process data necessary to perform an authentication operation of the REE 120. De-identification processing, encryption, comparison, and the like of authentication data required for the authentication operation may 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 security OA 142 may run a security application (TAPP) in the TEE 140. The security OA 142 includes a security kernel, and since the security kernel is operated in a physical / software protected state from malicious users, the security OA 142 is used for tasks requiring security such as key management. The secure kernel may include a virtual file system. When a file application of a virtual file system is called by a security application (TAPP), the virtual file system may safely store / load / delete the file system of the REE 120 after performing operations such as encryption / decryption internally. .

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

IAP 150 may be a program trusted by TEE 140. The guarantee of trust of IAP 150 may be determined by communication with a secure application (TAPP) of TEE 140. In an embodiment, IAP 150 may be driven on normal OA 122 of REE 120. In another embodiment, the IAP 150 may run on a 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 this OA. A separate OA for driving the IAP 150 may be provided.

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

In an embodiment, the IAP 150 receives the modified security data TSD and the token transmitted from the APP of the REE 120, verifies the security data SD, and generates the verified security data VSD. It can be implemented to. The modified security data TSD is a modification of the security data SD using a token in the APP of the REE 120.

In an embodiment, the IAP 150 receives the modified security data TSD and the token in the APP of the REE 120 and uses the token to convert the security data SD included in the modified security data TSD. Integrity can be verified.

The memory device 160 may be implemented as a volatile / nonvolatile memory device. In an embodiment, 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 memroy (SRAM), a dual line memory module (DIMM), or the like. In another embodiment, the memory device 160 may be a nonvolatile memory device. For example, the memory device 160 may include NAND flash memory, vertical NAND (VNAND), NOR flash memory, and resistive random access memory (RRAM). Phase-Change Memory (PRAM), Magnetoresistive Random Access Memory (MRAM), Ferroelectric Random Access Memory (FRAM), Spin Transfer Torque Random Access Memory (STT) RAM), 3D Xpoint memory, and so on. In another embodiment, the memory device 160 may be a hybrid memory device including a volatile memory device and a nonvolatile 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 security area 164 may include a security area for storing secure data (SD) or storing encrypted data.

In some embodiments, the normal data ND generated in the APP of the REE 120 may be stored in the normal region 162 via the normal OS 122.

In an embodiment, the security data SD of the REE 120 may be indirectly stored in the security area 164 with the help of the IAP 150. In this case, 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.

On the other hand, when considering the mobile device 100 in terms of security level, as shown in FIG. 2, the REE 120 is a first level virtualization entity, the normal area 162 is a first level virtualization object, and the TEE ( 140 is a second level virtualization subject, and security zone 164 is a second level virtualization object. The first level virtualization subject (REE) may transmit data (VSD) that guarantees integrity to the second level virtualization subject (TEE) by using an integrity guarantee program (IAP). The second level virtualization subject TEE may store this guaranteed data VSD in a second level virtualized object (security area).

In general, mobile devices were able to freely access the security domain only by being legally authenticated in the TEE environment in the REE environment. For example, a typical mobile device is only performing access control in modules such as trust zones on normal OAs. However, even with legitimate authentication, data sent to the REE can contain malicious information (viruses, spyware, malware, etc.). In this case, the TEE environment can be compromised by hackers.

On the other hand, the mobile device 100 according to an embodiment of the present invention does not directly store the data SD generated in the REE 120 in the security area 164, but the data VSD verified by the IAP 150. ) Can be stored in the secure area 164 to ensure the integrity of the transmitted data. Mobile device 100 of the present invention can prevent the potential activity of the hacker accordingly, and can maximize the security.

On the other hand, the integrity guarantee operation described above may be implemented by an XOR (exclusice or) operation.

3 is a diagram illustrating the integrity guarantee operation of the IAP 150 according to an embodiment of the present invention. 2 to 3, the integrity guarantee operation may proceed as follows.

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

Thereafter, the APP of the REE 120 may transmit the modified data TSD and the token to the IAP 150. The IAP 150 receives the modified data TSD and the token from the APP of the REE 120 and generates the verified data CSD VSD by performing a second XOR operation on the received modified data TSD and the token. Can be. The verified data VSD will be the original data. The verified data VSD may be stored in the security area 164.

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

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

The APP of the REE 120 may request the IAP 150 to access the secure area 164. The IAP 150 may receive an access request of the APP and transmit an authentication request to the APP. The APP may transmit the biometric code to the IAP 150 by ID / password writing or biometric in response to the authentication request. The IAP 150 may request issuance of a token while transmitting the received ID / password or biometric code to the TAPP of the TEE 140. In response to this request, the TAPP may first authenticate whether the APP is a legitimate user, and issue and store tokens if the APP is a legitimate user. The fact that the APP is a legitimate user may be performed by checking ID / password or biometric code. Authentication related information related thereto 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 transmit the transmitted token to the APP of the REE 120.

6 is a diagram conceptually illustrating the application of the Clark Wilson model to a mobile device according to an embodiment of the present invention. Referring to FIG. 6, the first subject S1 may be an REE 120 and may have an unconstrained data item (UDI) and a token. By performing the integrity verification procedure in the IAP 150, the first constrained data item CDI1 of the first subject S1 may be generated. The first restricted data item CDI1 may be stored in the objects 0 and 164. In addition, the second restricted data item CDI2 of the second subject S1 may be stored in the object O. FIG.

Meanwhile, the function of the IAP 150 shown in FIG. 2 described above may be performed in the TEE.

7 is a diagram illustrating a method of operating the mobile device 100 according to an embodiment of the present disclosure. 2 to 7, a method of operating the mobile device 100 is as follows.

In response to the request for access to the secure area 164 from the APP of the REE 120, the TEE 140 may perform an authentication operation (S110). The TEE 140 may receive a 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 a diagram illustrating a method of operating the mobile device 100 according to another embodiment of the present disclosure. 2 to 8, a method of operating the mobile device 100 is as follows.

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

The steps and / or actions according to the invention may occur simultaneously in different embodiments in different order, in parallel, or for other epochs, etc., as would be understood by one of ordinary skill in the art. Can be.

In some embodiments, some or all of the steps and / or actions may be directed to instructions, programs, interactive data structures, clients, and / or servers stored on one or more non-transitory computer-readable media. At least some may be implemented or performed using one or more processors. One or more non-transitory computer-readable media may be illustratively software, firmware, hardware, and / or any combination thereof. In addition, the functionality 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 used in application-specific integrated circuits (ASICs), standard integrated circuits, A controller that performs appropriate instructions, including a microcontroller, and / or an embedded controller, field-programmable gate arrays (FPGAs), complex programmable logic devices (CPLDs), and the like. Does not.

On the other hand, the content of the present invention described above is only specific embodiments for carrying out the invention. The invention will include not only specific and practically available means per se, but also technical ideas as abstract and conceptual ideas that may be utilized in future technology.

100: mobile device
120: REE
122: normal OS
140: TEE
142: Secure OS
150: IVP
160: memory device

Claims (5)

In the method of operation of a mobile device:
(a) performing a first XOR operation on the first data and the first token in an application of a rich execution environment (REE);
(b) transmitting a result value of the first XOR operation and the first token from the application to an integrity assurance program;
(c) determining whether the first token and the second token are the same in the integrity guarantee program;
(d) performing a second XOR operation on the resultant value of the first XOR operation and the second token in the integrity guarantee program; And
(e) transmitting, at the integrity guarantee program, a result of the second XOR operation to a trusted execution environment (TEE).
The method of claim 1, wherein before step (a),
Requesting a token issuance from the application to the integrity guarantee program; And
In response to the request for issuing the token, the integrity guarantee program issuing the first token.
The method of claim 2,
Issuing the first token,
Transmitting an access request to a security area of the integrity guarantee program in the application;
In response to the access request, transmitting an authentication request from the integrity guarantee program to the application;
In response to the authentication request, transmitting authentication related information to the integrity guarantee program in the application;
Transmitting a request for issuing the authentication related information and a token to the security application in the integrity guarantee program; And
Authenticating the application using the authentication related information in the security application, generating the first token, and transmitting the generated first token to the integrity guarantee program;
Way.
The method of claim 1,
The second token means the first token generated by the security application and then transmitted to the integrity guarantee program.
Way.
A mobile device comprising at least one processor and a non-transitory computer readable storage medium storing a set of instructions executed by the at least one processor, the mobile device comprising:
The instruction set is
An instruction set for performing a first XOR operation on the first data and the first token in an application of the REE;
An instruction set for transmitting the result of the first XOR operation and the first token from the application to an integrity guarantee program;
An instruction set for determining, by the integrity guarantee program, whether the first token and the second token are the same;
An instruction set for causing the integrity guarantee program to perform a result of the first XOR operation and a second XOR operation on the second token; And
And an instruction set for transmitting the result of the second XOR operation to a TEE in the integrity guarantee program.
Mobile devices.

Images