US20180316662A9 - Embedded trusted network security perimeter in computing systems based on ARM processors - Google Patents
Embedded trusted network security perimeter in computing systems based on ARM processors Download PDFInfo
- Publication number
- US20180316662A9 US20180316662A9 US15/063,625 US201615063625A US2018316662A9 US 20180316662 A9 US20180316662 A9 US 20180316662A9 US 201615063625 A US201615063625 A US 201615063625A US 2018316662 A9 US2018316662 A9 US 2018316662A9
- Authority
- US
- United States
- Prior art keywords
- tee
- security
- network
- network security
- embedded
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0209—Architectural arrangements, e.g. perimeter networks or demilitarized zones
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0272—Virtual private networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3234—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/02—Protecting privacy or anonymity, e.g. protecting personally identifiable information [PII]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/03—Protecting confidentiality, e.g. by encryption
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/08—Access security
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/08—Access security
- H04W12/086—Access security using security domains
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/12—Details relating to cryptographic hardware or logic circuitry
- H04L2209/127—Trusted platform modules [TPM]
Definitions
- the present invention generally relates to network communication protection on mobile devices by providing an embedded trusted network security perimeter using particular ARM processor Security Extensions and optional Virtualization Extensions.
- the present invention particularly addresses the threat of unauthorized network access or data leakage from a mobile device.
- Embedded trusted network security perimeter runs in the TEE on one or more cores with dedicated memory and storage. All network traffic from an OS running in a Rich OS Execution Environment to external networks unconditionally goes through security checks and transformations performed in the TEE.
- the present invention addresses threats of unauthorized network access or data leakage in the scenario where the Rich OS is compromised and its security related settings are compromised.
- the hardware-protected embedded trusted network security perimeter remains active and performs all checks and transformations required by a security policy.
- the ARM Security Extensions extend the processor architecture to provide hardware security features that support the development of secure applications, by providing two processor security states. Rich OS Execution Environment is running in Normal World when the processor is in Non-secure state. A Trusted Execution Environment (TEE) and its trusted applications are running in Secure World when the processor is in Secure state. The most important system control resources are only accessible from the TEE. Each security state has its own system registers and memory address space. The execution privilege levels are defined independently in each security state.
- the Virtualization Extensions further extend the processor architecture to provide virtualization capabilities. Some of the ARM processor implementations do not include the Virtualization Extensions. The present invention does not require Virtualization Extensions, however it includes embodiments both with and without Virtualization Extensions.
- Some of the ARM processor implementations do not include the Security Extensions.
- the present invention is applicable only to computer systems based on ARM processors with Security Extensions.
- ARM Security Extensions While the main purpose of ARM Security Extensions is isolation between Normal and Secure Worlds, the present invention provides the innovative approach of using these Security Extensions to isolate and protect an embedded security perimeter which is used to control all external network communications of a computer system.
- MMU Memory Management Unit
- TZASC TrustZone Address Space Controller
- TZPC TrustZone Protection Controller
- CSU Central Security Unit
- iMX6 Freescale processor see i.MX 6Dual/6Quad Applications Processor Reference Manual
- FIG. 5 illustrates a generic method of memory access control.
- ARM architecture it is possible to set access rights to different memory regions ( 503 , 507 ) for different processor mode sets.
- MMU memory management unit
- TZASC TZASC
- TZPC TZPC-based hardware modules
- processor manufacturers added their own extensions to enhance memory control functionality. For example, Freescale iMX 6 processor uses CSU instead of TZPC to provide more granular access control and additional security functionality.
- the most common memory access control mechanism is the MMU and it is currently used in popular OSs to separate system and user applications memory.
- the MMU is controlled by system control registers that can also disable the MMU.
- the processor works with virtual addresses and MMU works with memory system to translate virtual addresses to physical addresses.
- MMU divides memory into pages (4 KB, 64 KB, 1 MB, and 16 MB) and each page can have its own memory access attributes.
- the ARM processor enhanced with Security Extensions has a separate and independent MMU for Secure and Normal World execution environments.
- TZASC TZASC module
- RAM random-access memory
- MMU memory access control attributes
- the TZASC works totally independently of MMU even when MMU is disabled.
- the TZASC works with physical addresses and doesn't have any MMU virtual address awareness.
- the TZPC is used to control access between the Rich OS Execution Environment and TEE for memory regions where peripheral hardware device controllers and interfaces ( 504 , 509 , 505 and 511 ) are mapped. Also TZPC is used to control on-chip RAM access control in some ARM processors implementations. The TZPC could be configured from TEE only. Different ARM processors have different peripheral devices and interfaces, so TZPC regions are predefined and implementation dependent and only access rights to these regions can be changed in the runtime.
- the present invention uses TZPC to provide controlled access to peripheral devices ( 504 , 509 , 505 and 511 ).
- the main TZPC function in preferred embodiments is to make hardware network interface as it's shown on FIG. 2 accessible only from TEE ( 206 ), while Rich OS Execution Environment ( 201 ) uses Virtual Network Interface ( 203 ) for network communications.
- 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.
- 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.
- 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.
- 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.
- 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).
- 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.
- trusted system boot loader 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.
- a trusted system boot loader 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.
- ROM read-only memory
- 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.
- 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.
- SMC Secure Monitor Calls
- 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.
- TrustWall software ( 207 ) is fully transparent for the software of Rich OS and can be configured from TEE only according to security policy.
- 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 ).
- 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.
- 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 ).
- 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.
- Crypto Provider allows indirect and controlled work with cryptographic keys.
- TPM as it described in prior art, Patent No. US008375221B1 or other implementations could be used.
- Crypto Provider can be used to simplify integrity and authenticity checks and provide hardware accelerated encryption for Rich OSs.
- 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).
- 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.
- 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.
- 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.
- ARM architecture access to TZASC and TZPC configuration is allowed only from TEE ( 502 ) and denied from Rich OS Execution Environment ( 501 ).
- memory access control is used for separation of runtime execution environments.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Storage Device Security (AREA)
Abstract
Description
- The present invention generally relates to network communication protection on mobile devices by providing an embedded trusted network security perimeter using particular ARM processor Security Extensions and optional Virtualization Extensions.
- Current mobile devices such as tablets or smart phones often provide rich OS functionality without any restrictions on network access. This unrestricted network access generally poses a high risk for malware infection or data leakage. The present invention particularly addresses the threat of unauthorized network access or data leakage from a mobile device.
- Embedded trusted network security perimeter runs in the TEE on one or more cores with dedicated memory and storage. All network traffic from an OS running in a Rich OS Execution Environment to external networks unconditionally goes through security checks and transformations performed in the TEE.
- The present invention addresses threats of unauthorized network access or data leakage in the scenario where the Rich OS is compromised and its security related settings are compromised. In such a scenario, the hardware-protected embedded trusted network security perimeter remains active and performs all checks and transformations required by a security policy.
- The following references identify related art:
- [1] Shanbhogue Vedvyas [Patent U.S. Pat. No. 8,190,778 B2] Method And Apparatus For Network Filtering And Firewall Protection On A Secure Partition
- [3] Crowell Zachary Thomas, Khalidi Yousef A, Talluri Madhusudhan [U.S. Pat. No. 8,151,337 B2] Applying Firewalls To Virtualized Environments
- http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0406c/index.html
ARM Cortex-A series processor Technical Reference Manuals:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0388e/index.html - http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0388e/index.html
- http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0388e/index.html
- http://cache.freescale.com/files/32bit/doc/ref_manual/IMX6DQRM.pdf?fasp=1&WT_TYPE=Reference% 20Manuals&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=pdf&WT_ASSET=Documentation&fileExt=.pdf
- The ARM Security Extensions extend the processor architecture to provide hardware security features that support the development of secure applications, by providing two processor security states. Rich OS Execution Environment is running in Normal World when the processor is in Non-secure state. A Trusted Execution Environment (TEE) and its trusted applications are running in Secure World when the processor is in Secure state. The most important system control resources are only accessible from the TEE. Each security state has its own system registers and memory address space. The execution privilege levels are defined independently in each security state.
- The Virtualization Extensions further extend the processor architecture to provide virtualization capabilities. Some of the ARM processor implementations do not include the Virtualization Extensions. The present invention does not require Virtualization Extensions, however it includes embodiments both with and without Virtualization Extensions.
- Some of the ARM processor implementations do not include the Security Extensions. The present invention is applicable only to computer systems based on ARM processors with Security Extensions.
- While the main purpose of ARM Security Extensions is isolation between Normal and Secure Worlds, the present invention provides the innovative approach of using these Security Extensions to isolate and protect an embedded security perimeter which is used to control all external network communications of a computer system.
- In order to achieve memory separation between two execution environments, memory access rights are configured through ARM Memory Management Unit (MMU) (see ARM Cortex-A series processor Technical Reference Manuals), TrustZone Address Space Controller (TZASC) (see CoreLink TrustZone Address Space Controller TZC-380 Technical Reference Manual) and TrustZone Protection Controller (TZPC) (see PrimeCell Infrastructure AMBA 3 TrustZone Protection Controller Technical Overview) or through vendor specific Security Extension hardware modules, for example Central Security Unit (CSU) in iMX6 Freescale processor (see i.MX 6Dual/6Quad Applications Processor Reference Manual).
-
FIG. 5 illustrates a generic method of memory access control. In ARM architecture, it is possible to set access rights to different memory regions (503, 507) for different processor mode sets. To achieve this, several hardware modules are integrated into the processor: MMU, TZASC and TZPC. Additionally, several processor manufacturers added their own extensions to enhance memory control functionality. For example, Freescale iMX6 processor uses CSU instead of TZPC to provide more granular access control and additional security functionality. - The most common memory access control mechanism is the MMU and it is currently used in popular OSs to separate system and user applications memory. The MMU is controlled by system control registers that can also disable the MMU. When the MMU is enabled, the processor works with virtual addresses and MMU works with memory system to translate virtual addresses to physical addresses. MMU divides memory into pages (4 KB, 64 KB, 1 MB, and 16 MB) and each page can have its own memory access attributes. The ARM processor enhanced with Security Extensions has a separate and independent MMU for Secure and Normal World execution environments.
- The purpose of a TZASC module is separation of TEE memory from Rich OS Execution Environment. It works with random-access memory (RAM) only and can be configured from TEE only. As the MMU, it divides memory into regions and each region has its own memory access control attributes. The TZASC works totally independently of MMU even when MMU is disabled. The TZASC works with physical addresses and doesn't have any MMU virtual address awareness.
- Since the TZASC module works only with RAM, the TZPC is used to control access between the Rich OS Execution Environment and TEE for memory regions where peripheral hardware device controllers and interfaces (504, 509, 505 and 511) are mapped. Also TZPC is used to control on-chip RAM access control in some ARM processors implementations. The TZPC could be configured from TEE only. Different ARM processors have different peripheral devices and interfaces, so TZPC regions are predefined and implementation dependent and only access rights to these regions can be changed in the runtime.
- The present invention uses TZPC to provide controlled access to peripheral devices (504, 509, 505 and 511). The main TZPC function in preferred embodiments is to make hardware network interface as it's shown on
FIG. 2 accessible only from TEE (206), while Rich OS Execution Environment (201) uses Virtual Network Interface (203) for network communications. -
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. -
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. -
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. -
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. -
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). - 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.
- 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.
- 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.
-
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. -
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. - 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.
- 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.
- TrustWall software (207) is fully transparent for the software of Rich OS and can be configured from TEE only according to security policy.
-
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). -
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. - 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).
- 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.
- 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.
-
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). - 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.
- Security and Virtualization Extensions of current ARM processors allows isolated runtime environments to be established using the method presented in this invention.
- 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.
Claims (4)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US15/063,625 US10250595B2 (en) | 2015-03-30 | 2016-03-08 | Embedded trusted network security perimeter in computing systems based on ARM processors |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201562139977P | 2015-03-30 | 2015-03-30 | |
US15/063,625 US10250595B2 (en) | 2015-03-30 | 2016-03-08 | Embedded trusted network security perimeter in computing systems based on ARM processors |
Publications (3)
Publication Number | Publication Date |
---|---|
US20170264607A1 US20170264607A1 (en) | 2017-09-14 |
US20180316662A9 true US20180316662A9 (en) | 2018-11-01 |
US10250595B2 US10250595B2 (en) | 2019-04-02 |
Family
ID=59787320
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US15/063,625 Active 2036-12-07 US10250595B2 (en) | 2015-03-30 | 2016-03-08 | Embedded trusted network security perimeter in computing systems based on ARM processors |
Country Status (1)
Country | Link |
---|---|
US (1) | US10250595B2 (en) |
Families Citing this family (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10778444B2 (en) * | 2018-07-11 | 2020-09-15 | Verizon Patent And Licensing Inc. | Devices and methods for application attestation |
CN111953637B (en) * | 2019-05-16 | 2022-08-26 | 阿里巴巴集团控股有限公司 | Application service method and device |
US11416619B1 (en) * | 2019-09-24 | 2022-08-16 | Sprint Communications Company L.P. | Trusted boot-loader authentication |
CN112953909B (en) * | 2021-01-28 | 2023-03-14 | 北京豆荚科技有限公司 | Method for realizing vehicle-mounted internal and external network safety isolation based on TEE |
CN112929392A (en) * | 2021-03-19 | 2021-06-08 | 杭州市电力设计院有限公司余杭分公司 | Electric power Internet of things security communication module improvement method based on TEE |
Family Cites Families (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060026422A1 (en) * | 2004-07-29 | 2006-02-02 | International Business Machines Corporation | Method, apparatus, and product for providing a backup hardware trusted platform module in a hypervisor environment |
US7865908B2 (en) | 2005-03-11 | 2011-01-04 | Microsoft Corporation | VM network traffic monitoring and filtering on the host |
US8151337B2 (en) | 2006-06-30 | 2012-04-03 | Microsoft Corporation | Applying firewalls to virtualized environments |
US8190778B2 (en) | 2007-03-06 | 2012-05-29 | Intel Corporation | Method and apparatus for network filtering and firewall protection on a secure partition |
US9231921B2 (en) * | 2013-08-20 | 2016-01-05 | Janus Technologies, Inc. | System and architecture for secure computer devices |
US20150188949A1 (en) * | 2013-12-31 | 2015-07-02 | Lookout, Inc. | Cloud-based network security |
US9749294B1 (en) * | 2015-09-08 | 2017-08-29 | Sprint Communications Company L.P. | System and method of establishing trusted operability between networks in a network functions virtualization environment |
US9792143B1 (en) * | 2015-10-23 | 2017-10-17 | Amazon Technologies, Inc. | Platform secure execution modes |
-
2016
- 2016-03-08 US US15/063,625 patent/US10250595B2/en active Active
Also Published As
Publication number | Publication date |
---|---|
US20170264607A1 (en) | 2017-09-14 |
US10250595B2 (en) | 2019-04-02 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP3326104B1 (en) | Technologies for secure trusted i/o access control | |
US9081911B2 (en) | Mediating communication of a universal serial bus device | |
Lentz et al. | Secloak: Arm trustzone-based mobile peripheral control | |
TWI570589B (en) | Apparatus for providing trusted computing | |
US9979699B1 (en) | System and method of establishing trusted operability between networks in a network functions virtualization environment | |
US8627414B1 (en) | Methods and apparatuses for user-verifiable execution of security-sensitive code | |
US10250595B2 (en) | Embedded trusted network security perimeter in computing systems based on ARM processors | |
US8627069B2 (en) | System and method for securing a computer comprising a microkernel | |
US8893306B2 (en) | Resource management and security system | |
US20180082057A1 (en) | Access control | |
US20140053245A1 (en) | Secure communication using a trusted virtual machine | |
US10922402B2 (en) | Securing secret data embedded in code against compromised interrupt and exception handlers | |
US10360386B2 (en) | Hardware enforcement of providing separate operating system environments for mobile devices | |
CN110874468B (en) | Application program security protection method and related equipment | |
AU2020287873B2 (en) | Systems and methods for processor virtualization | |
EP3178032B1 (en) | Embedding secret data in code | |
US20170317832A1 (en) | Virtual Secure Elements in Computing Systems based on ARM Processors | |
US9398019B2 (en) | Verifying caller authorization using secret data embedded in code | |
Zhang et al. | An efficient TrustZone-based in-application isolation schema for mobile authenticators | |
CN117034330B (en) | macOS-based safety protection method, macOS-based safety protection equipment and storage medium | |
EP3314516B1 (en) | System management mode privilege architecture | |
Wan et al. | Remotely controlling TrustZone applications? A study on securely and resiliently receiving remote commands | |
Li et al. | GSLAC: GPU Software Level Access Control for Information Isolation on Cloud Platforms | |
CN117708832A (en) | Method and system for realizing high-performance heterogeneous trusted execution environment |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: GBS LABORATORIES, LLC, VIRGINIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SURDU, OLEKSII;REEL/FRAME:045776/0974 Effective date: 20180511 |
|
FEPP | Fee payment procedure |
Free format text: PETITION RELATED TO MAINTENANCE FEES GRANTED (ORIGINAL EVENT CODE: PTGR); ENTITY STATUS OF PATENT OWNER: SMALL ENTITY |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
AS | Assignment |
Owner name: INZERO TECHNOLOGIES, LLC, VIRGINIA Free format text: CHANGE OF NAME;ASSIGNOR:GBS LABORATORIES, LLC;REEL/FRAME:054555/0094 Effective date: 20191125 |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YR, SMALL ENTITY (ORIGINAL EVENT CODE: M2551); ENTITY STATUS OF PATENT OWNER: SMALL ENTITY Year of fee payment: 4 |