P-MAPS: An on-demand hardware-rooted system for protecting critical applications

posted by Ravi Sahita on April 20, 2009

Since our last virtual discussion (June 2008), malware attacks continue to rise, and more so, attacks have continued to become stealthy and targeted. We have completed a key milestone for our software protection research last month; we created a research prototype of a hardware-assisted application protection capability called “Processor-Measured Application Protection Service (P-MAPS)”. The goal of this work has been to significantly reduce the Trusted Computing Base (TCB) from a full Operating System to a substantially smaller P-MAPS layer to improve the runtime security of critical applications running within the OS. The main contributions of our work are the on-demand trusted instantiation of P-MAPS and the use of P-MAPS to protect applications without interrupting the natural operation of the application or the Operating System. With P-MAPS enabled on a platform, day-0 attacks and attempts by unknown malware to attack critical applications can be mitigated.

Dynamic Software Application Protection white paper View .pdf

We built the P-MAPS layer to be OS-agnostic; an untrusted OS-specific service is used on the platform that runs within a commodity OS. Initially, the OS is in the TCB - the P-MAPS launch put the platform in a reduced-TCB state (with the OS outside the TCB). The OS-specific P-MAPS service can be triggered by the user/OS launching an application that uses P-MAPS for protection, and can be torn-down securely when not needed by any protected applications. The P-MAPS TCB consists of the CPU, the verified chipset and platform firmware. We use Intel® TXT to measure the P-MAPS layer which allows the P-MAPS Core to be independent of the chipset. The chipset specific code is contained in the Authenticated Chipset Module (or ACM) that is signed by Intel. The processor (via the Intel® TXT GETSEC instruction set) verifies the ACM. Additionally, the ACM can verify the P-MAPS measurement against a Launch Control Policy embedded on the platform. This approach protects the user for malicious software that may try to spoof the P-MAPS layer or try to deny P-MAPS execution. To protect the applications after the P-MAPS layer has been launched in a trusted manner, we use Intel® VT capabilities. Note that with P-MAPS active, we have moved the OS execution into “guest” mode. The applications that “register” with the P-MAPS are subject to an in-memory authentication process after which they are protected as was described in our previous post. Protected applications can continue executing within the OS without any disturbance to the OSes operation or the operation of other unprotected applications.

We have written several applications that use the P-MAPS to provide three core security properties: 1. Isolation of the application’s runtime memory from other software on the platform, 2. Encapsulation of the application data memory such that only code in the measured application pages can access the data. 3. Prevention of circumvention of any function entry-points exposed in the application code. A protected application typically involves handling of secret data that is provisioned by a Provisioning Entity (Server) in the network. We have built P-MAPS such that the hardware can authenticate the P-MAPS core when it interacts with the platform root of trust (in our case, a Trusted Platform Module or TPM) which can then be used to provide hardware-derived quotes to a trusted remote entity. The TPM quotes are used by the remote entity to verify that the application is indeed executing with the required hardware-derived protection. A set of trusted third parties participate to enable this attestation mechanism as in a standard Public Key Infrastructure mechanism. Our P-MAPS TCB is substantially smaller (~2500x smaller compared to a commodity OS) TCB. We continue to strive to reduce this TCB layer, and analyze requirements that different applications impose on the P-MAPS, as well as do performance analysis of the overheads while it executes.

Comments (1)

tagged: encryption, malware, research, RSA, security