KR20200097416A - Processor including isolated interrupt handler for securing input channel on sgx and interrupt processing method thereof - Google Patents

Abstract

Provided is a processor including an isolated interrupt handler (I2H), which can access to an enclave area associated with an application executed by the processor, and includes an interface with an input device used for inputting data.

Description

Processor including an isolated interrupt handler to protect the input channel on the SGX and an interrupt handling method {PROCESSOR INCLUDING ISOLATED INTERRUPT HANDLER FOR SECURING INPUT CHANNEL ON SGX AND INTERRUPT PROCESSING METHOD THEREOF}

The embodiments relate to security of data input through an input device, and to an apparatus and method for safely protecting an application executed by a processor and an input channel through which data input through an input device is input for an application.

Recently, interest in security of an application (eg, an application code) executed by a processor or data input through an input device for an application is increasing.

In this regard, Intel's processors have developed protection functions such as cSoftware Guard Extensions (SGX). SGX is a function to separately encrypt and protect areas that are vulnerable or sensitive to attacks by software, and it is necessary to establish an encryption area called enclave, which is a separate space inside the processor where related contents cannot be identified even with the extended authority of the CPU. It is characterized. Through this, it is possible to increase the security strength for data processed by the application, and to prevent the application-related code from being exposed or modified.

Current commercial TEE (trusted execution environment) solutions protect pieces of application logics (PAL) or the entire OS and security apps. In the case of protecting only PALs like Intel's SGX, security is not guaranteed for I/O corresponding to the input/output channel of data, so its practicality is limited. On the other hand, in the case of a solution (eg, ARM TrustZone) that protects the entire OS and security apps, an enormous TCB (Trusted Computing Base) is required. In this case, one bug in the security OS can corrupt all components residing in the same system.

Accordingly, there is a need for a method and a structure of a processor that can economically reduce TCB while safely protecting input/output channels of data.

In Korean Patent Publication No. 10-2009-0130121 (published date: December 17, 2009), an apparatus for establishing and implementing a secure computing environment in order to execute a portion of software, In relation to a system and a method, a technology for providing a security processor that executes a part of software in an environment that provides limited access to a computing environment resource is disclosed.

The information described above is for illustrative purposes only, may include content that does not form part of the prior art, and may not include what the prior art may present to a person skilled in the art.

In one embodiment, an isolated interrupt handler configured such that an enclave area associated with an application executed by a processor is accessible, includes an interface with an input device, and cannot be accessed from software such as an OS. ; A processor including I2H) is provided.

In one aspect, in the processor, an enclave area associated with an application executed by the processor is accessible, and an isolated interrupt handler comprising an interface with an input device used to input data for the application ( Isolated Interrupt Handler; I2H), wherein the I2H is configured to be inaccessible from system software associated with the processor.

The I2H may provide at least one security driver for the input device.

The security driver may be used to provide an isolated execution environment for a critical region of a kernel.

An enclave area may exist in association with each of a plurality of applications executed by the processor.

Enclave areas associated with the plurality of applications may share and use the security driver.

The enclave area includes an interface for accessing the I2H, the I2H includes a shared data region, and the enclave area is the phosphorus to obtain data input through the input device. The shared data area can be accessed through the interface of the clave area.

The enclave area may control the shared data area using a predetermined security command so that a rootkit cannot access it during data transfer between the enclave area and the I2H.

The interface is an I/O port for the input device, the I/O port is locked or unlocked according to a predetermined instruction for the I2H, and the I/O port is locked while the I/O port is locked. The O port can be used exclusively through the I2H.

When access to the I/O port is requested while the I/O port is locked, a garbage value may be returned for the request.

The operation of generating the I2H, the operation of adding contents to the generated I2H, and the operation of jumping into the I2H may each be performed according to a predetermined command.

When an interrupt according to the input of data through the input device occurs, detection information indicating that the flow associated with the I2H does not proceed may be generated if the flow associated with the I2H does not proceed.

In another aspect, a processor for executing an application and a memory for temporarily storing at least data required to execute the application are included, wherein the processor has access to an enclave area associated with the application, and the application An Isolated Interrupt Handler (I2H) comprising an interface with an input device used to input data for, wherein the I2H is configured to be inaccessible from system software associated with the processor, A computer is provided.

In another aspect, in a method of processing an interrupt according to data input through an input device performed by a processor, an enclave area associated with an application executed by the processor is accessible, and the input device and Generating an Isolated Interrupt Handler (I2H) including an interface of-The I2H is configured to be inaccessible from system software associated with the processor -, based on a predetermined instruction, the Locking or unlocking an I/O port as an interface-When the I/O port is locked, the I/O port is exclusively used through the I2H-and data input through the input device through the I2H A method of handling an interrupt is provided, comprising receiving a code corresponding to.

The method of handling the interrupt includes the steps of returning a garbage value for the request when access to the I/O port is requested without entering the I2H while the I/O port is locked. It may further include.

The enclave area includes an interface for accessing the I2H, the I2H includes a shared data region, and the enclave area is used to obtain the data input through the input device. Access the shared data area through the interface of the clave area, but access the shared data area using a predetermined security command so that the rootkit cannot access during data transfer between the enclave area and the I2H can do.

In yet another aspect, in an architecture for a processor that executes an application, the processor is an interface with an input device that is accessible to an enclave area associated with the application and is used to input data for the application An architecture is provided that includes an Isolated Interrupt Handler (I2H), wherein the I2H is configured to be inaccessible from system software associated with the processor.

Compared to Intel's SGX, which is not properly protected for input/output channels, by using I2H, the enclave area is accessible, includes the interface with the input device, and is not accessible from system software such as OS. It can properly protect the input channel from attackers or rootkits.

By sharing security drivers for multiple enclaves (enclave areas) through I2H, protection for input/output channels can be realized in an economical manner without the need to redundantly deploy the same driver for each enclave.

1 shows a computer system according to an embodiment.
2 shows a comparison between an exemplary general system and a security system.
3 illustrates a method of disposing drivers in each exemplary enclave area and protecting an input/output channel using a hypervisor.
4 illustrates a method of protecting an input/output channel using I2H according to an embodiment.
5 shows the configuration of I2H according to an example.
6 shows an operation of a processor in response to an access attack on an I/O port of an exemplary rootkit.
7 illustrates an operation of a processor using I2H against an attack on an I/O port of a rootkit according to an example.
8 shows how an Enclave accesses data entered through an exemplary input device.
9 illustrates a method in which an enclave accesses data input through an input device through a shared data area of I2H according to an example.
10 illustrates an interrupt processing method when an interrupt occurs due to data input through an input device according to an example.
11 is a flowchart illustrating a method of processing an interrupt according to data input through an input device by a processor including I2H according to an exemplary embodiment.

Hereinafter, embodiments will be described in detail with reference to the accompanying drawings. The same reference numerals in each drawing indicate the same members.

1 shows a computer system according to an embodiment.

The computer system 100 may include a computing device (computer or server) capable of executing applications and/or programs. The application and/or program executed through the computer system 100 may be software that requires security in input and/or output of data. For example, it may be an application and/or program executed through the computer system 100 and software used for financial services and transactions.

The computer system 100 is a smart phone, a personal computer (PC), a laptop computer, a laptop computer, a tablet, an Internet of Things (Internet Of Things) device, or a wearable computer. It may be a terminal (or part of it) used by a user such as Alternatively, the computer system 100 may be a server or a part thereof. The computer system 100 may be a device operating in an Internet of Things (IoT) environment.

That is to say, the computer system 100 may be any computing device or a part thereof including a processor capable of implementing a method for protecting an input/output channel according to embodiments to be described later.

Computer system 100 may include a processor 110 and a memory 120.

The processor 110 may be configured to process instructions of a computer program and/or an application to be executed by performing basic arithmetic, logic, and input/output operations. The instructions may be provided to the processor 110 by the memory 120 or a communication module (not shown). For example, the processor 110 may be configured to execute a command received according to a program code stored in a recording device such as the memory 120.

The processor 110 can manage the components of the computer system 100 and processes operations necessary for execution of programs and/or applications and processing of data, and may be a configuration such as a CPU or GPU, or Alternatively, it may be at least one core of the GPU.

The memory 120 may be a component for at least temporarily storing data required to execute an application and/or a program executed by the processor 110. The memory 120 is a non-transitory computer-readable recording medium, such as a random access memory (RAM), read only memory (ROM), a disk drive, a solid state drive (SSD), a flash memory, etc. It may include a permanent mass storage device. Here, a non-destructive mass storage device such as a ROM, SSD, flash memory, disk drive, etc. may exist in the computer system 100 as a separate permanent storage device that is separate from the memory 120. In addition, an operating system and at least one program code may be stored in the memory 120. These software components may be loaded from a computer-readable recording medium separate from the memory 120. Such a separate computer-readable recording medium may include a computer-readable recording medium such as a floppy drive, disk, tape, DVD/CD-ROM drive, and memory card. In another embodiment, software components may be loaded into the memory 120 through a communication module other than a computer-readable recording medium. For example, at least one program may be loaded into the memory 120 based on a computer program installed by files provided through a file distribution system (eg, an external server) for distributing the installation files of developers or applications. May be.

A communication module, not shown, may provide a function for the computer system 100 to communicate with other electronic devices or servers through a network. The communication module may be a hardware module such as a network interface card, a network interface chip, and a networking interface port of the computer system 100, or a software module such as a network device driver or a networking program.

Computer system 100 may include or be connected to an input device 130. The input device 130 may include devices such as a keyboard, a mouse, a microphone, and a camera. Meanwhile, the computer system 100 may include an output device (not shown) or may be connected to an output device. The output device may include a device such as a display, a speaker, a haptic feedback device, or the like.

Alternatively, the input device 130 may be a device in which functions for input and output are integrated into one, such as a touch screen. As shown, the input device 130 may be a separate device from the computer system 100 or may be a component included in the computer system 100. The computer system 100 may further include an input/output interface as a means for an interface with the input device 130. Similarly as described, computer system 100 may be configured to be connected with or to include an output device.

The processor 110 may be provided with an enclave area associated with an application to be executed, the enclave area is accessible, and an isolated interrupt handler (I2H) including an interface with the input device 130 is provided. Can be provided. I2H may be configured to be inaccessible from system software (eg, such as OS). In embodiments, by providing the I2H in the processor 110, protection for an input/output channel associated with the input device 130 may be enhanced.

A more specific method of enhancing protection for the input/output channel associated with the input device 130 using I2H will be described in more detail with reference to FIGS. 2 to 11 to be described later.

2 shows a comparison between an exemplary general system and a security system.

The left figure of FIG. 2 shows an example in which a security function is not applied to an application executed in a processor and data input to an application. The illustrated application represents an application executed by a processor. As illustrated, the OS may include a processor manager for managing a processor, device drivers for devices that enable data input/output in association with an application, a memory manager for managing memory, and a file system.

The right diagram of FIG. 2 shows an embodiment in which a security function is applied to an application executed in a processor and data input to an application. The application executed by the processor is shown as a security application, and the OS is shown as a security OS. The security OS may include a processor manager and a memory manager and security drivers for devices that enable data input/output in association with an application. Although not shown, the security OS may further include a file system. As shown, the security application can access data input through an input device using a secure path through a security driver.

The architecture using the security function shown in the right figure of FIG. 2 may correspond to the architecture to which the above-described TrustZone of ARM is applied.

For other commercial TEEs (eg, Intel's SCX), the architecture to which TrustPath is applied and the architecture to which I2H is applied in embodiments will be described in more detail with reference to FIGS. 3 to 11 to be described later.

3 illustrates a method of disposing drivers in each exemplary enclave area and protecting an input/output channel using a hypervisor.

In FIG. 3, an architecture in which TrustedPath is applied to SGX may be shown (eg, also referred to as SGXIO). A processor including such an architecture will be described with reference to the processor 300. The processor 300 may include an enclave area 310 for each of the executed applications 305. The enclave area 310 may be a space separately provided inside the processor 300 to separately encrypt and protect the vulnerable or sensitive area. Access to the enclave area 310 may be restricted so that related contents cannot be recognized even with the extended authority of the processor 300.

The enclave area 310 associated with each application 305 may include a driver 312. The driver 312 may be a security driver of the device 130-2 for inputting (or outputting) data to an application.

The processor 300 may include a hypervisor 330. The hypervisor 330 may be software (thin layer) that controls how various computer resources, such as processor 300 or memory, access the OS 320.

A trusted path may be established between the application 305 and the device 130-2 using the hypervisor 300 and the enclave area 310. Accordingly, an input channel (or output channel) to the application 305 for data input (or output) through the device 130-2 may be protected.

In the case of the device 130-1 that does not require a protection function, the input/output channel to the application 305 through the driver 322 included in the OS 320 as described above in FIG. 2 is used as an ordinary path. Can be built.

As shown in FIG. 3, there may be the following problems in applying TrustedPath to SGX:

1) First, there may be basic barriers to the design of SGX. For example, in the case of SGX, there are no privileged instructions (priviledged instructions) related to device input/output inside the enclave (ie, there is no device interface). In addition, AEX (Asynchronous Enclave Exit) prevents interrupt handlers from being executed in the enclave. Also, since the enclave area operates with user authority, a driver (I/O driver) operating with the authority of the kernel cannot be placed inside.

2) There may be a problem of I/O monopolization (that is, there is no resource release until the security application 305 is terminated)

3) In a multi-processor environment, double costs can occur. For example, since one driver 312 is required per each enclave area 310 (ie, a driver must be included for each PAL), the incurred cost may be excessive.

In addition, the shaded portions of the architecture correspond to the TCB, and the architecture shown in FIG. 3 may require a relatively larger and more complex TCB.

Given this point, it may not be desirable to apply TrustedPath for commercial TEEs such as SGX.

In the above, descriptions of the technical features described above with reference to FIGS. 1 and 2 may be applied to FIG. 3 as they are, and thus redundant descriptions will be omitted.

Referring to FIG. 4, an architecture capable of solving problems arising in applying the TrustedPath to SGX will be described.

4 illustrates a method of protecting an input/output channel using I2H according to an embodiment.

The architecture illustrated in FIG. 4 can provide secure I/O by extending the isolation for PAL while excluding other OS components from the TCB. In the illustrated architecture, a new isolation area called I2H (Isolated Interrupt Handler) 430 (or I2H area) for selectively arranging and operating drivers for providing PAL security I/O is provided.

In FIG. 4, an architecture in which I2H is applied to SGX may be shown. A processor including such an architecture will be described with reference to the processor 400. The processor 400 may include an enclave area 410 for each of the executed applications 305. The enclave area 410 may be a space separately provided inside the processor 400 to separately encrypt and protect the vulnerable or sensitive area. The enclave area 410 may be encrypted so that related contents cannot be recognized even by the processor 400 or its extended authority.

The isolated interrupt handler (I2H) 430 may be configured such that the enclave area 410 associated with the application 305 executed by the processor 400 is accessible. In addition, I2H 430 may include an interface 434 with an input device 130 used to input data for an application 305. The I2H 430 may be an isolated space created in the processor 400.

The I2H 430 may be configured to be inaccessible from system software (eg, OS 420) associated with the processor 400.

The I2H 430 may provide at least one security driver for the input device 130. That is, the I2H 430 may include at least one security driver for the input device 130.

The I2H 430 may provide an isolated execution environment for a critical region of the kernel. In other words, the secure driver can be used to provide an isolated execution environment for the critical region of the kernel.

As illustrated, when there are a plurality of applications 305 executed in the processor 400, an enclave area 410 may exist in association with each of the plurality of applications 305. Enclave areas 410 associated with a plurality of applications 305 may share and use a security driver. That is to say, the enclave areas 410 may share the same security drivers, and each may not own its own driver. Unlike the architecture of FIG. 3, the enclave area 410 does not duplicate the same driver, and multiple enclave areas 410 can share one security driver, so that the cost of implementing the architecture can be reduced. have.

In the illustrated architecture, the enclave region 410 may include an interface 412 for accessing the I2H 430. Meanwhile, the I2H 430 may include a shared data region 432. The enclave area 410 may access the shared data area 432 through the interface 412. In other words, the enclave area 410 may access the shared data area 432 through the interface 412 of the enclave area 410 in order to acquire data input through the input device 130. At this time, the enclave area 410 accesses the shared data area using a predetermined security command so that the rootkit cannot access during data transfer between the enclave area 410 and the I2H 430 can do.

As shown, trust between the application 305 and the device 130 using the I2H 430 including the enclave area 410, the security driver and the shared data area 432 and interfaces 412 and 434 A trusted path can be established. Thus, an input channel (or output channel) to the application 305 for data input (or output) through the device 130 may be protected.

The interface 434 for the input device 130 provided by the I2H 430 may be an I/O port, for example. I2H 430 may configure exclusive access to interface 434 for input device 130.

Compared to the architecture described above with reference to FIG. 3, since unnecessary kernel components can be removed by using the I2H 430, TCB can be reduced.

Through the architecture described in Figure 4, security against the following threats can be provided:

1) SGX intrinsic threat model (threat due to untrusted OS and hypervisor).

2) Attack on device I/O interfaces (PIO and MMIO), for example, I/O port or MMIO mapping attack.

3) Attack on kernel space data areas (driver allocated memory areas), for example, a threat in which a rootkit reads target input data (scan code, key code, key event, etc.).

4) Attack on user space data areas.

In the above, descriptions of the technical features described above with reference to FIGS. 1 to 3 may be applied to FIG. 4 as they are, and thus redundant descriptions will be omitted.

5 shows the configuration of I2H according to an example.

In FIG. 5, the configurations of the I2H 430 described above with reference to FIG. 4 will be described in more detail. Contents of the illustrated I2H 430 are illustrated for the case of a Linux system. It is assumed that the input device 130 is a keyboard. The keyboard may be a keyboard including physical keys or a virtual keyboard.

The I2H 430 may include an input core system 510, a keyboard driver 520, a keyboard controller driver 530, an LDISC 540, a bus driver 550, and an event handler 560. The keyboard driver 430 and the keyboard controller driver 530 may be included in a security driver for the input device 130.

For example, an operation of generating an I2H 430 as shown, an operation of adding contents such as components 510 to 56 to the generated I2H 430, and jumping into I2H Each operation may be performed according to a predetermined command. For example, commands such as icreate, iadd, and ienter may be used for each operation, respectively.

By configuring the I2H 430 as shown, the input/output channel can be protected from access by the kernel. For example, memory management unit (MMU) protection may be applied. In addition, as I2H 430 includes drivers and input subsystem for input device 130, thus, enclave regions 410 securely secure data input through input device 130. Can receive.

The I2H 430 may perform access control on the I2H 430 to protect important assets (eg, input data) related to input/output from the kernel. For example, the kernel cannot access the I2H 430, but the I2H 430 can access the kernel.

In the above, descriptions of the technical features described above with reference to FIGS. 1 to 4 may be applied to FIG. 5 as they are, and thus redundant descriptions will be omitted.

6 shows an operation of a processor in response to an access attack on an I/O port of an exemplary rootkit.

As described with reference to FIG. 5, it is assumed that the input device 130 is a keyboard. When an interrupt according to data input through the input device 130 occurs, the keyboard controller driver 530 may request data from the keyboard controller 610 (1. i8042_read_data() {Inb(0x60)}). Accordingly, the keyboard controller 610 may transmit a key scan code corresponding to the input data to the keyboard controller driver 530 (2. Key scancode). The keyboard driver 520 may transmit an input event of data to the input core system 510 according to communication with the keyboard controller driver 530 (3. Input_event()). Meanwhile, when data input is requested from the rootkit 620 or access to the input data is requested (4. Inb(0x60)), the rootkit 620 may take a corresponding key scan code (5. Key). scancode).

That is to say, in the architecture of FIG. 6, when data is received from the input device 130, the rootkit 620 can freely access/modify the input data. That is, protection of the input channel of data input from the input device 130 is not performed. Since the I/O port for the input device 130 corresponds to a shared medium, the rootkit 620 may also initiate an I/O port requesting attack.

Meanwhile,'Inb(0x60)' may represent receiving an input from the 0x60 input port used by the PS2 keyboard, for example. For example,'Inb(0x60)' can perform read/write as much as byte size to the designated input/output (I/O) port through the inb/outb command among CPU privilege commands, and execute the command for 0x60 port. Can indicate that. As the rootkit 620 can execute a privileged command like a general kernel, it can accept input from a keyboard. The blocks on the left side of FIG. 6 (drivers 520 and 530 and the input core system 510) operate in the kernel, and the rootkit 620 can read the internal memory of the kernel, so the corresponding blocks (drivers 520 and 530 ) And the input core system 510) while the input data from the keyboard is being processed.

On the other hand, the input core system 510 is a code module located inside the Linux kernel and manages to receive input events from various types of input device drivers and deliver them to an appropriate event handler (eg, keyboard event handler 560). It may be a system that does.

An architecture capable of solving the problem of the architecture of FIG. 6 will be described in more detail with reference to FIG. 7.

In the above, descriptions of the technical features described above with reference to FIGS. 1 to 5 may be applied to FIG. 6 as they are, and thus redundant descriptions will be omitted.

7 illustrates an operation of a processor using I2H against an attack on an I/O port of a rootkit according to an example.

Operations described below may be performed in association with the I2H 430 described above with reference to FIGS. 4 and 5 or within the I2H 430.

When an interrupt according to data input through the input device 130 occurs, the keyboard controller driver 530 may request data from the keyboard controller 610. The interface 434 of the I2H 430 may be an I/O port for the input device 130, and the I/O port is locked according to a predetermined instruction (ie, a command) for the I2H 430 Or it can be unlocked (1. i8042_read_data() {Port_unlock(0x60); Inb(0x60); Port_lock(0x60);}). While the I/O port is locked, the I/O port can be used exclusively through I2H 430. The keyboard controller 610 may transmit a key scan code corresponding to the input data to the keyboard controller driver 530 (2. Key scancode). The keyboard driver 520 may transmit an input event of data to the input core system 510 according to communication with the keyboard controller driver 530 (3. Input_event()). On the other hand, when data input is requested from the rootkit 620 or access to the input data is requested (4.Inb(0x60)), a garbage value other than the corresponding key scan code will be returned for the rootkit 620. Can (5. Garbage value). That is, a request for access from the rootkit 620 to a locked medium (a state in which the I/O port is locked) returns a garbage value.

In the architecture of FIG. 7, the rootkit 620 cannot access or modify the input data, and the input channel of the data input from the input device 130 is protected. That is to say, the rootkit 620 has no access to (input) data transfers within the area of I2H 430 and through I2H 430. This prevents access to the I2H 430 internal code and data area from the privileged mode, and at the same time provides a command to lock/unlock the use of a specific I/O port corresponding to the interface 434 within the I2H 430. It can be made according to use. For example, when access to an I/O port is requested while the I/O port is locked, a garbage value may be returned for the request.

In the case of the embodiment described in FIG. 7, the drivers 520 and 530) and the input core system 510 are enclosed by the I2H 430 (that is, they exist inside the I2H 430 ), and the I2H 430 Unlike the normal kernel memory, since the rootkit 620 is an isolated area that cannot be accessed, the rootkit 620 cannot steal input data while the data is being processed inside the I2H 430.

In the above, descriptions of the technical features described above with reference to FIGS. 1 to 6 may be applied to FIG. 7 as they are, and thus redundant descriptions will be omitted.

8 shows how an Enclave accesses data entered through an exemplary input device.

For example, FIG. 8 shows a method of accessing the enclave area 310 for data input through the input device 130 in a general enclave input interface (eg, Intel's SGX). The enclave area 310 may request reading of data input through the input device 130 through an untrusted host process 810 (1. OCALL(read)) , The untrusted host process 810 requests a line discipline (LDISC) 540 to read data (2. Read()), and the TTY 540 is sent to the untrusted host process 810. Data can be returned (3. ldisc.read(); copy_to_user()). The returned data may be transmitted from the input core system 510 through the keyboard event handler 560 (ldisc.receive_buf()).

In the illustrated structure of FIG. 8, an untrusted host process 810 is used as an interface of the enclave area 310, so that the rootkit can freely access input data while data is transferred between the process and the kernel. Input data can be modified.

On the other hand, "OCALL" is an interface provided by the Intel SGX SDK, and because the system call cannot be processed inside the enclave, the outside of the enclave (ie, " “O” indicates “O” of Out) and may mean to request and process a system call instead using the untrusted host process 810.

"Read" is a response to a system call, and the Line Discipline module 540 waits for input data to arrive (ldisc.read), and when it receives input data from the keyboard event handler 560 (ldisc.receive_buf)" The keyboard input data in the kernel may be transmitted to the host process 810 through "copy_to_user". "copy_to_user" may represent copying data from the kernel area to the user process area.

The right blocks of FIG. 8 (input core system 510, event handler 560, and TTY 540) operate in the kernel, and the rootkit is the kernel internal memory (including the process internal memory area corresponding to the left). Can be read, the input data can be intercepted while the input data is being processed by the corresponding blocks (the input core system 510, the event handler 560, and the TTY 540 ).

An architecture capable of solving the problem of the architecture of FIG. 8 will be described in more detail with reference to FIG. 9.

In the above, descriptions of the technical features described above with reference to FIGS. 1 to 7 may be applied to FIG. 8 as they are, and thus redundant descriptions will be omitted.

9 illustrates a method in which an enclave accesses data input through an input device through a shared data area of I2H according to an example.

In the illustrated architecture, the enclave area 410 can access the I2H 430 according to a predetermined instruction. For example, the interface 412 of the enclave area 410 may access the shared data area 432 of the I2H 430 according to a predetermined command (i2h_read() {copy_from_i2h();}). Accordingly, the enclave area 410 may access data input through the input device 130.

Unlike the untrusted host process 810 in the architecture of FIG. 8, in the architecture of FIG. 9, the interface 412 of the enclave area 410 and the shared data area 432 of the I2H 430 and the shared data area By using a predetermined command for access to 432, the rootkit may be unable to access data while (input) data is being transferred between enclave area 410 and I2H 430. Accordingly, the stealing and modification of data by the rootkit can be prevented. The command may be, for example, based on the SGX command (a modification of the command used in SGX).

Meanwhile, as described above, the operation of generating the I2H 430, the operation of adding contents such as components 510 to 56 to the generated I2H 430, and jumping into the I2H (jump into) Each operation may be performed according to a predetermined command. For example, commands such as icreate, iadd and ienter may be used for each operation.

Unlike described in FIG. 8, "i2h_read", which can be executed immediately without having to go out from the enclave through "OCALL", directly transfers data from the I2H 430 to the inner area of the enclave through "copy_from_i2h" without going through the kernel. I can.

As described in FIG. 7, the input core system 510, the event handler 560, and the TTY 540 are wrapped by the I2H 430 (that is, they exist inside the I2H 430), and the I2H 430 Unlike general kernel memory, since the rootkit is an isolated area that cannot be accessed by the rootkit, the rootkit cannot steal input information while data is being processed inside the I2H 430.

In the above, descriptions of the technical features described above with reference to FIGS. 1 to 8 may be applied to FIG. 9 as they are, and thus redundant descriptions will be omitted.

10 illustrates an interrupt processing method when an interrupt occurs due to data input through an input device according to an example.

Referring to FIG. 10, when the input device 130 is a keyboard, data is input through the keyboard, and a key scan code corresponding to the data input to the keyboard controller 610 arrives, and an interrupt generated accordingly is Explain how it is handled.

When an interrupt is generated and received (for example, interrupt #1 is received), the kernel of the processor can process the interrupt through the flow using the I2H 430 described above or the flow not using the I2H 430. have. Which flow the kernel will jump into can be determined by the kernel.

However, if the I2H flow is not reached by hijacking, for example, this fact can be detected by the user (if the interrupt is not processed through the flow using the I2H 430). For example, access/non-access to the locked medium may be detected by the user.

That is, when an interrupt according to data input through the input device 130 occurs, detection information indicating that the flow associated with the I2H 430 does not proceed may be generated if the flow associated with the I2H 430 does not proceed. have. Such detection information may be transmitted to a user (eg, output through an output device), for example through an output device associated with a processor (or through a communication module). Accordingly, the user can check the hijacking or modulation of the I2H 430.

As described above, the description of the technical features described above with reference to FIGS. 1 to 9 may be applied to FIG. 10 as it is, and thus a duplicate description will be omitted.

11 is a flowchart illustrating a method of processing an interrupt according to data input through an input device by a processor including I2H according to an exemplary embodiment.

Referring to FIG. 11, a method of processing an interrupt according to data input through the input device 130 performed by the processor 400 described above will be described in more detail.

In step 1110, the processor 400 has an enclave area 410 associated with the application 305 executed by the processor 400 is accessible, and the isolation including an interface 434 with the input device 130. An Isolated Interrupt Handler (I2H) 430 can be created. The I2H 430 may be configured to be inaccessible from system software associated with the processor 400, such as the OS 420. The I2H 430 may be created as an internal space of the processor 400 according to a predetermined command.

In step 1120, the processor 400 may set the I/O port as the interface 434 to lock or unlock based on a predetermined instruction. That is, the processor 400 may lock or unlock the I/O port according to the predetermined command. According to the lock command, when the I/O port is locked, the I/O port can be used exclusively through the I2H 430.

In step 1130, the processor 400 may receive a code corresponding to data input through the input device 130 through the I2H 430. For example, when the input device 130 is a keyboard, the code may be a key scan code and/or a key code.

In step 1140, when the I/O port is locked and the access to the I/O port is requested without entering the I2H 430, the processor 400 is a garbage value for the request. Can be returned. That is, access to or modification of data from an attacker such as a rootkit can be prevented.

The enclave area 410 may be configured to include an interface 412 for accessing the I2H 430. The I2H 430 may be configured to include a predetermined shared data region 432.

The enclave area 410 may access the shared data area 432 through the interface 412 of the enclave area 410 in order to acquire data input through the input device 130, and a rootkit The shared data area 432 may be accessed using a predetermined security command so that the data cannot be accessed during the transfer of the data between the enclave area 410 and the I2H 430.

Accordingly, an input channel (or output channel) to the application 305 for data input (or output) through the device 130 may be securely protected from an attacker such as a rootkit.

Through the architecture using the I2H 430 of the embodiment, isolation for PALs while minimizing TCB can be achieved with isolation for selected kernel parts to provide safe input (input data). I2H 430, which is an isolation area provided for this, may be characterized by access of the exclusive (input/output) device 130 and direct access of the enclave area 410 as described above.

By modifying the x86 architecture in such a way that the I2H 430 is used, security problems for input (or output) data and input/output channels of the SGX can be solved.

The apparatus described above may be implemented as a hardware component, a software component, and/or a combination of a hardware component and a software component. For example, the devices and components described in the embodiments include, for example, a processor, a controller, an arithmetic logic unit (ALU), a digital signal processor, a microcomputer, a field programmable array (FPA), It can be implemented using one or more general purpose computers or special purpose computers, such as a programmable logic unit (PLU), a microprocessor, or any other device capable of executing and responding to instructions. The processing device may execute an operating system (OS) and one or more software applications executed on the operating system. In addition, the processing device may access, store, manipulate, process, and generate data in response to the execution of software. For the convenience of understanding, although it is sometimes described that one processing device is used, one of ordinary skill in the art, the processing device is a plurality of processing elements and/or a plurality of types of processing elements. It can be seen that it may include. For example, the processing device may include a plurality of processors or one processor and one controller. In addition, other processing configurations are possible, such as a parallel processor.

The software may include a computer program, code, instructions, or a combination of one or more of these, configuring the processing unit to behave as desired or processed independently or collectively. You can command the device. Software and/or data may be interpreted by a processing device or to provide instructions or data to a processing device, of any type of machine, component, physical device, virtual equipment, computer storage medium or device. , Or may be permanently or temporarily embodyed in a transmitted signal wave. The software may be distributed over networked computer systems and stored or executed in a distributed manner. Software and data may be stored on one or more computer-readable recording media.

The method according to the embodiment may be implemented in the form of program instructions that can be executed through various computer means and recorded in a computer-readable medium. The computer-readable medium may include program instructions, data files, data structures, and the like alone or in combination. The program instructions recorded on the medium may be specially designed and configured for the embodiment, or may be known and usable to those skilled in computer software. Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks, and magnetic tapes, optical media such as CD-ROMs and DVDs, and magnetic media such as floptical disks. -A hardware device specially configured to store and execute program instructions such as magneto-optical media, and ROM, RAM, flash memory, and the like. Examples of the program instructions include not only machine language codes such as those produced by a compiler but also high-level language codes that can be executed by a computer using an interpreter or the like. The hardware device described above may be configured to operate as one or more software modules to perform the operation of the embodiment, and vice versa.

Although the embodiments have been described by the limited embodiments and drawings as described above, various modifications and variations are possible from the above description to those of ordinary skill in the art. For example, the described techniques are performed in an order different from the described method, and/or components such as a system, structure, device, circuit, etc. described are combined or combined in a form different from the described method, or other components Alternatively, even if substituted or substituted by an equivalent, an appropriate result can be achieved.

Claims (15)

In the processor,
An enclave area associated with an application executed by the processor is accessible, and includes an isolated interrupt handler (I2H) including an interface with an input device used to input data for the application, ,
The I2H is configured to be inaccessible from system software associated with the processor. The method of claim 1,
Wherein the I2H provides at least one secure driver for the input device. The method of claim 2,
The secure driver is used to provide an isolated execution environment for a critical region of a kernel. The method of claim 2,
An enclave region exists in association with each of a plurality of applications executed by the processor,
Enclave areas associated with the plurality of applications share and use the security driver. The method of claim 1,
The enclave region includes an interface for accessing the I2H,
The I2H includes a shared data region,
Wherein the enclave area accesses the shared data area through an interface of the enclave area to obtain data input through the input device. The method of claim 5,
Wherein the enclave area accesses the shared data area using a predetermined security command such that a rootkit cannot access during data transfer between the enclave area and the I2H. The method of claim 1,
The interface is an I/O port for the input device,
The I/O port is locked or unlocked according to a predetermined instruction for the I2H,
The I/O port is used exclusively through the I2H while the I/O port is locked. The method of claim 7,
When the I/O port is locked and access to the I/O port is requested, a garbage value is returned for the request. The method of claim 1,
An operation of generating the I2H, adding contents to the generated I2H, and an operation of jumping into the I2H are each performed according to a predetermined instruction. The method of claim 1,
When an interrupt according to the input of data through the input device occurs, if the flow associated with the I2H does not proceed, detection information indicating that the flow associated with the I2H does not proceed is generated. A processor executing an application; And
Memory for at least temporarily storing data required to execute the application
Including,
The processor includes an Isolated Interrupt Handler (I2H) including an interface with an input device that is accessible to an enclave area associated with the application and is used to input data for the application,
The I2H is configured to be inaccessible from system software associated with the processor. A method of processing an interrupt according to data input through an input device, performed by a processor,
Generating an Isolated Interrupt Handler (I2H) including an interface with the input device in which an enclave area associated with the application executed by the processor is accessible-The I2H is a system associated with the processor It is configured to be inaccessible from software -;
Locking or unlocking an I/O port as the interface based on a predetermined instruction-the I/O port is exclusively used through the I2H while the I/O port is locked; And
Receiving a code corresponding to the data input through the input device through the I2H
Including, how to handle the interrupt. The method of claim 12,
When the I/O port is locked and access to the I/O port is requested without entering the I2H, returning a garbage value for the request
Further comprising, a method of handling an interrupt. The method of claim 12,
The enclave region includes an interface for accessing the I2H,
The I2H includes a shared data region,
The enclave area accesses the shared data area through the interface of the enclave area in order to acquire data input through the input device, but a rootkit transfers data between the enclave area and the I2H A method of handling an interrupt by accessing the shared data area by using a predetermined security command so that the user cannot access it during the period. In the architecture for the processor running the application,
The processor includes an Isolated Interrupt Handler (I2H) including an interface with an input device that is accessible to an enclave area associated with the application and is used to input data for the application,
The I2H is configured to be inaccessible from system software associated with the processor.

Images