Embedded trusted network security perimeter in computing systems based on ARM processors

Abstract

The invention relates to a method for computer systems based on the ARM processor, for example mobile devices, wherein the ARM processor provides fully hardware isolated runtime environments for an operating system (OS) and Trusted Execution Environment (TEE) including an embedded trusted network security perimeter. The isolation is performed by hardware ARM Security Extensions added to ARMv6 processors and greater and controlled by TrustWall software. The invention therefore comprises an embedded network security perimeter running in TEE on one or more processor cores with dedicated memory and storage and used to secure all external network communications of the host device. The invention addresses network communications control and protection for Rich OS Execution Environments and describes minimal necessary and sufficient actions to prevent unauthorized access to or from external networks. The present invention uses hardware platform security capabilities which significantly increase protection of the embedded network security perimeter itself from targeted attacks, in contrast to existing, and representing an improvement of, end-point software firewalls. In addition, embodiments of the invention do not require any modification to the OS system code or network application software.

Claims

1. A computing system with embedded network security perimeter that incorporates capabilities to secure all external network communications comprising: a. a computer system based on multi-core ARM processor with integrated Security Extensions; b. embedded network security perimeter running in Trusted Execution Environment (TEE) on one or more cores with dedicated memory and storage; c. an Operating System (OS) running in a Rich OS Execution Environment on one or more cores with dedicated memory and storage; d. TEE and Rich OS Execution Environment which are hardware isolated from each other using security extensions of the hardware platform; e. Wherein only the embedded network security perimeter has an access to physical network interfaces; f. Wherein all network traffic from a Rich OS to external networks goes through security checks and transformations performed by embedded network security perimeter in TEE; g. Wherein the embedded network security perimeter is controlled by management service; and h. Wherein the management service uses security policies as a primary source of configuration data.

2. The embedded network security perimeter as described in clam 1 consisting of a network firewall, VPN gateway and management service wherein: a. the management service may use additional input data from devices controlled by TEE and b. both local and remote security policies can be used to manage embedded network security perimeter described in claim 1; c. 3.A system described in claim 1 wherein the security policies of claim 1 are protected using encryption and digital signatures such that cryptographic keys used for decryption and digital signature of the security policies are accessible from TEE only.

3. The computing system as claimed in claim 1 where software running in TEE performs access control of storage, other devices and external interfaces.

4. The computing system as claimed in claim 1 where data exchange between TEE and Normal world is performed using SMC, IRQ or FIQ.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0021] FIG. 1 illustrates a preferred embodiment of the invention, a computing system with a multi-core processor and fully hardware isolated runtime environments for TEE and Rich OS Execution Environments. The isolation inside a computing system is performed by hardware and controlled by the TrustWall software. One or more processor cores are dedicated to run Rich OS and other one or more processor cores are dedicated to run TEE code. This allows pure parallel execution without any Virtual Machines or Hypervisors running inside a computer system.

[0022] FIG. 2 illustrates the high level model of the invention. Embedded network security perimeter is running inside TEE. Access to physical network interfaces is allowed from TEE only. All network traffic from a Rich OS which is running in Normal World to external networks passes through security checks and transformations performed by TrustWall software in TEE.

[0023] FIG. 3 illustrates a more detailed view of TEE. Software modules in TEE have an access to physical network interfaces and perform checks and transformations of the network traffic required by a security policy.

[0024] FIG. 4 illustrates the management system of the invention. All critical parts of the management system are located inside the TEE. Security policies are used as primary source of configuration data. Cryptographic keys used for decryption and digital signature verification of the security policies is accessible from TEE only.

[0025] FIG. 5 illustrates hardware enforced memory, storage and devices access control modules. All described modules are located in TEE and perform access control for both Secure and Normal World. Access control rules can be fixed or dynamic (configured via security policies).

DETAILED DESCRIPTION

[0026] This section describes the present invention with reference to the accompanying drawings. The detailed description of these corresponding drawings and the exemplary embodiments are intended to make it apparent to one of ordinary skill in the art how to construct these exemplary embodiments. Various modifications may become apparent to those skilled in the art, such as other types of security technology, processors, memories, programming techniques, or protocols. Consequently, the invention is not limited to these exemplary embodiments because the same result may be accomplished with other technologies. The appended claims present the scope of the invention accordingly to encompass application of the invention to all applicable technologies.

[0027] Preferred embodiments of the present invention should have a hardware-enforced mechanism that can be configured by relatively simple and easily verified trusted boot procedure and also can uniquely identify each environment which restrains only its own resources.

[0028] This can be achieved using a trusted system boot loader mechanism that is currently implemented in most ARM processors and described in prior art, for example in Patent No. US20090204801A1. Such a system based on ARM processors uses a first stage system boot loader that is located inside on-chip read-only memory (ROM) to ensure integrity and authenticity of the external boot code and prevents system start using unauthorized code. This creates a trusted computing base where after boot completion, the system is in a determined state that cannot be altered. After initial boot completion other critical system components are loaded and could be protected with a “chain-of-trust” procedure i.e., a next component is loaded, verified and only after the successful completion of these steps is then executed.

[0029] FIG. 1 illustrates a preferred embodiment of the invention, a computing system with multi-core (101-102) processor (103) and fully hardware isolated runtime environments for TEE and Rich OS Execution Environment. One or more processor cores (101) are dedicated to run Rich OS and other one or more processor cores (102) are dedicated to run TEE code. These environments may run in parallel. The embodiment presented uses dedicated processor cores for Rich OS and TEE and significantly decreases context switch cost in terms of time and processor resources comparing to Virtual Machine embodiments. It is obvious to one skilled in the art that depending on system workload, the number of dedicated processors for one of the environments could be changed dynamically, including the borderline situation when TEE is shut down and use zero processor cores.

[0030] FIG. 2 illustrates the high level model of the present invention where all network traffic (202) from an Rich OS running in Normal World Execution Environment (201) to external networks (210) goes through security checks (207) and transformations (207) performed by software modules running in Secure World TEE (206). The described approach does not require any modification to the OS system code or network application software and provides a standard network stack (202) for the software.

[0031] Communication (211) between Rich OS and TEE is performed using IRQ or FIQ hardware signals and dedicated shared memory segments. Optionally, Secure Monitor Calls (SMC) instruction can be used to switch between Secure and Normal World within one processor core.

[0032] Embedded network security perimeter running in TEE has an access to physical network interfaces (208) and Virtual Network Interface (209) while the network stack of the Rich OS can use Virtual Network Interface (203) only and does not have any access to physical network interfaces (208) on the hardware level.

[0033] TrustWall software (207) is fully transparent for the software of Rich OS and can be configured from TEE only according to security policy.

[0034] FIG. 3 illustrates a detailed model of the TEE. Virtual Network Interface (302) is used for communications with the Rich OS Execution Environment. All connections from Rich OS to external networks are forwarded to embedded network security perimeter (305) which includes Firewall, IDS, IPS and audit. Optionally, depending on security policy, connections may be forwarded through a VPN gateway (304) first. Only after the successful competition of the security checks and transformations data goes to physical Hardware Network Interface (303). All components of the TrustWall are managed by the Management System (306).

[0035] FIG. 4 illustrates the management system of the invention. All critical parts (405 408) of the management system are located inside TEE (402). Security policies (408) are used as primary source of configuration data. Cryptographic keys (407) used for decryption and digital signature verification of the security policies (408) are accessible from TEE (402) only.

[0036] Non-critical parts (403, 404) of the management system are located in Rich OS Execution Environment. TrustWall Management User Interface (404) provides a user with a tool to interact with TrustWall Management Service (405) where a user can locally view or modify some of security policy settings. Other security policy settings can be changed by a Network Management Agent (403) using remote Management Service (406).

[0037] In the present invention, cryptographic keys used for decryption and digital signature verification of the security policies are managed by KeyStore and Crypto Provider (407) and accessible from TEE only.

[0038] Crypto Provider allows indirect and controlled work with cryptographic keys. For example, TPM as it described in prior art, Patent No. US008375221B1 or other implementations could be used. Also Crypto Provider can be used to simplify integrity and authenticity checks and provide hardware accelerated encryption for Rich OSs.

[0039] FIG. 5 illustrates hardware-enforced memory (506), storage (508) and devices (510) access control modules. All described modules are located in TEE (502) and perform access control both for resources (507, 509, and 511) of Secure and resources (503-505) of Rich OS Execution Environment (501). It is critically important that no hardware resources should be left for shared use from different environments without access control modules management. Access control rules can be fixed or dynamic (configured via security policies).

[0040] Access control modules utilize ARM processor Security Extensions such as TZPC or hardware Virtualization Extensions to control access level to particular hardware resources such as internal hardware devices, hardware interfaces and external peripheral devices from OSs that are running in the Normal World.

[0041] Security and Virtualization Extensions of current ARM processors allows isolated runtime environments to be established using the method presented in this invention.

[0042] General purpose RAM access control is configured through TZASC and MMU. The memory region access control for hardware interfaces is configured through TZPC. MMU stage 2 can be used for memory access control on the computing systems that use Virtualization Extensions of ARM processor. In the ARM architecture access to TZASC and TZPC configuration is allowed only from TEE (502) and denied from Rich OS Execution Environment (501). In the present invention memory access control is used for separation of runtime execution environments.