Patent Application
20160004859
The present invention relates to a computer system and method, and more specifically to a system and method for platform and user application security on a computing device.
Protecting user-space code on computing devices such as mobile phones has been increasingly important. There currently exist several approaches for security of application code on such devices: One of these is Discretionary Access Controls (DAC). Conventionally operating systems (OS's) utilize DACs to restrict access to objects based on User-IDs, thereby protecting the objects from unauthorized access. The owners of the objects under DAC have the ability to make policy decisions and/or assign security attributes. Using DAC, it is possible to permit or deny other users permission to, for example, execute certain user application code. However, the fundamental limitation of the DAC approach is that there is a “root” user which is exempt from the limitations imposed by DAC on all other User-IDs, and thus a malicious user may completely bypass DAC by simply acquiring root privilege (also known as “rooting the device”).
SE Linux is another approach to securing a Linux platform by imposing Mandatory Access Controls (MACs), which as the name suggests are not discretionary based on the User-ID. The SE Linux approach provides for a policy-based security mechanism in which every potentially privileged access to files, drivers, and other system resources, is granted or denied based on not just the User-ID, but the executing process making the request. The fundamental difficulty with SE Linux (and the reason it is not more widely employed) is that the security policy data is very complex (almost arbitrarily so), in that it must describe the complete matrix of every resource on the system and every process that may or may not be allowed access to those resources. Furthermore, it is required to update the policy every time new software is installed in a device. This is virtually unmanageable in practice and has largely prevented real-world adoption of SE Linux.
Therefore, there is a need to provide a new system and method for improving security on a computing device.
It is an object of the invention to provide a method and system that obviates or mitigates at least one of the disadvantages of existing systems.
In accordance with an aspect of the present disclosure, there is provided a method of enhancing security on a computing device, which includes: verifying integrity of operating system code on the computing device to establish a trusted execution environment in the operating system of the computing device; and in response to the successful integrity verification of the operating system code, binding a user-space application on the computing device to the operating system on the computing device.
In accordance with a further aspect of the present disclosure, there is provided a computer readable storage medium storing one or more programs, the one or more programs comprising instructions, which when executed by a computer processer in a computing device, cause the processor to perform the method enhancing security on a computing device.
In accordance with a further aspect of the present disclosure, there is provided a system for enhancing security on a computing device, which includes: a processor configured for: verifying integrity of operating system code on the computing device to establish a trusted execution environment in the operating system of the computing device; and in response to the successful integrity verification of the operating system code, binding a user-space application on the computing device to the operating system on the computing device.
These and other features of the invention will become more apparent from the following description in which reference is made to the appended drawings wherein:
For simplicity and clarity of the illustration, elements in the figures are not necessarily to scale, are only schematic and are non-limiting, well known components may be omitted, and the same reference numbers in different figures denote the same elements, unless stated otherwise.
In the description below, the terms “device(s)”, “platform(s)” and “system(s)” may be used interchangeably, and the terms “executable”, “process”, “module” and “component” may be used interchangeably. In the description below, the terms “kernel (executable) process”, “kernel (executable) module”, and “kernel” may be used interchangeably. In the description below, the terms “Kernel Agent (executable) process”, “Kernel Agent module”, and “Kernel Agent” may be used interchangeably.
Embodiments are described below, by way of example only, with reference to
In the present disclosure, a secure platform and method for enhancing security on a computing device is provided. The secure platform and method for enhancing security on a computing device is applicable to, for example, but not limited to, any computing devices including mobile phones, games consoles, tablets, set top boxes, televisions or other consumer electronic devices. The embodiments of the present disclosure are described, by way of example only, in terms of any platforms that use an open source operating system (OS), for example, but not limited to, Linux or Android™ OS and these examples should not be construed as limiting the intended scope of the present invention.
Referring to
In a non-limiting example, the IV (100) step includes the IV (110) of the OS code to verify that the computing device has a trusted OS to establish a SW TEE in the OS space. If the IV (110) of the OS code is successful, it is determined that the OS of the computing device is fully trusted. In a non-limiting example, upon success of the IV (110) of the OS, the binding (120) step is implemented. In a non-limiting example, the IV (110) of the OS includes either one or more of IV of the on-disk image of the OS, IV of the in-memory image of the OS, and continuous/incremental IV of the in-memory image of the OS. In a non-limiting example, upon success of IV (112) of the on-disk and in-memory image of the OS, the binding (120) step is implemented. In a non-limiting example, upon success of the IV (112) of the on-disk and in-memory image of the OS, continuous/incremental IV (114) of the in-memory image of the OS is implemented (see
In a non-limiting example, the IV (100) step includes IV (130) of the user-space application to verify that the computing device has a SW TEE in user-space (see e.g.,
In a non-limiting example, the in-memory image of the user-space application (including the relocations) is signed (140) after the IV (130) of the user-space application image (see e.g.,
In a non-limiting example, the binding (120) step includes restoring a missing piece of code and/or data (or “MP”) to the user-space application. In a non-limiting example, the MP is revoked if any IV fails. In a non-limiting example, after the binding (120) step, continuous/incremental IV (170) of the in-memory image of the use application is implemented (see e.g.,
In a non-limiting example, if all performed IV is successful, the system grants (190) privileges to the user application (e.g., privileged access to the computing device's resource(s)) (see
In a non-limiting example, the OS of the computing device is a kernel based OA, and the IV of the OS (110) includes the IV of the kernel-space during system startup to create the trusted OS kernel-space. The IV of the kernel image may be performed by a Kernel Agent of the kernel based OS. The IV of the kernel image may include either one or more of IV of the on-disk image of the kernel, IV of the in-memory image of the kernel, the on-disk image of the Kernel Agent, IV of the in-memory image of the Kernel Agent,
In a non-limiting example, the IV steps of
In a non-limiting example, the security of the platform with the OS is enhanced by a Mandatory Access Control (MAC) mechanism. The MAC constrains the ability of a user to execute application code or access system resources regardless of whether the user is “root”, or masquerades as “root”. The Kernel Agent in the trusted OS kernel-space monitors and intercepts specific system-calls from user-space into the kernel. The Kernel Agent is thus able to monitor creation of user-space processes (aka “invoking an application”) on an ongoing basis and apply Process State Verification to validate callers. The term “Process State Verification” refers to the process of ensuring that the entire executable memory of the calling process is fully signed/validated code, thereby preventing common code-injection attacks such as over-writing code-space or shared-library shimming. The Kernel Agent validates the executable image (either one or more of on-disk and in-memory), generates a verifiable signature of the entire process-space executable memory, and binds the user-space application to the trusted kernel-space. In this way, the KA is used to establish a Software (SW) TEE in the kernel-space and extend that SW TEE into user-space (at least for designated user-space applications of interest).
In a non-limiting example, the Process State Validation is implemented based on the signature and validation (e.g., IVs in
In a non-limiting example, the Kernel Agent of the kernel based OS binds the user-space code to the trusted kernel-space code by using a Missing Piece (“MP”) technique. Binding the user-space application to the kernel-based OS prevents a malicious attacker from simply taking the executable code from the on-disk user application file and running it in on another device. This MP-based binding technique also prevents an attacker from turning off some of the protections of the user application.
Referring to
User Application Executable Provisioning 200A (
In a non-limiting example, the piece of code and/or data 210 is extracted from the original user application file 202 by using a provisioning tool 204 and replaced by dummy values. The resultant user application executable image (file) 206 contains the original version of the user application code and/or data except for the piece of code and/or data 210. At runtime the Kernel Agent (e.g., “KA.ko” in 212 of
In a further non-limiting example, the piece of code and/or data 210 in the user application file 202 is corrupted or encrypted by the provisioning tool 204. At runtime the Kernel Agent (e.g.,“KA.ko” in 212 of
Signing Executables 200B (
In a non-limiting example, the user application executable is signed at 200B after the user application executable provisioning 200A. In a further non-limiting example, the user application executable may be signed at 200B before the user application executable provisioning 200A in the case that the extraction of the piece of code and/or data 210 does not change the user application executable to be signed.
Code Signing 200C (
The provisioning of the user application executable 200A and the code signing 200C may be independently implemented, depending on the MP technique. For example, if the piece of data 210 is extracted from the user application file 202, the code signing 200C is implemented independent of the user application provisioning 200A. If the piece of code 210 in the user application file 202 is changed by the provisioning tool 204, it changes the contents of the executable file (and thus, the computed signature), and the code signing 200C is, therefore, be implemented after the user application provisioning 200A.
Kernel Agent Executable Provisioning 200D (
At runtime, in response to a call to create a user application executable image in memory, the Kernel Agent implements IV of the user application file (on-disk) with the voucher (e.g., 228 of
The Kernel Agent is configured to, among other things, implement “IV” of code or data images in the system, including, for example, static or on-disk Integrity Verification (e.g., on HDD or on flash memory) and dynamic or in-memory Integrity Verification (e.g., in random access memory (RAM)). The Kernel Agent is configured to, among other things, act as a watcher to dynamically monitor the integrity of the kernel components, the secure boot components, all protected applications and their associated shared-libraries.
The IV is implemented, for example, but not limited to, by computing a signature (e.g. a hash value) for an object (e.g., a system component, an application) and then comparing that to a known good value for the signature. If the calculated value is the same as the stored known good value, the Kernel Agent assumes that the object has not been modified by an attacker. However, if the calculated value is different than the stored known good value, the Kernel Agent assumes that the object has been modified and can no longer be trusted to perform the functionality that it was intended to perform or that it does not have the same privileges that were originally assigned to the object.
Referring to
The System Startup process includes, among others, executing an OS boot-loading process 302 (“Bootloader” in
For example, the Kernel Agent file 308 corresponds to the Kernel Agent file 236 of
The Kernel Agent 310 gains execution control during initialization to perform IV operations in the kernel-space 300. In a non-limiting example, the Kernel Agent 310 implements IV operations, including: (1) in-memory IV to verify integrity of the kernel image itself 306 (step 3 in
In addition, the Kernel Agent 310 is executed to perform all in-memory IV upon the kernel executable image and the Kernel Agent executable image incrementally, which will detect dynamic attacks.
By completing the IV operations, the Kernel Agent 310 confirms that the OS installed in the platform is the intended OS such that the kernel 306 has not been modified between boot-load and the bring-up of the Kernel Agent 310 and the Kernel Agent 310 performs the functionality that it was intended to perform. The kernel-space 300 is fully verified and trusted, and thus the kernel code and Kernel Agent code run in a fully secured fashion. If the Kernel Agent 310 detects itself running in an un-trusted environment, it will take an appropriate action, such as shutting itself down, and removing any privileged assets (or resources, e.g., OS, hardware components, network components) which have been distributed to user applications.
Referring to
A system call (“Process Create” in
The user application file 402 contains, for example, a user application executable file signed in the code signing process 200C as shown in
The Kernel Agent 310 then implements on-disk IV of the user application file 402 (step 3 of
The IV may be conducted by, for example, but not limited, comparing the signature in the voucher 404 to a known value corresponding to the user application resources. The user application resources may include IV information and the application signing certificate stored in a secure store. If the signature value is the same as the stored application signing certificate (i.e., known good value), the Kennel Agent 310 assumes that the user application file 402 on disk has not been modified by an attacker and that its permissions or privileges have not been modified. If the signature value is different than the known good value, the Kernel Agent 310 assumes that the user application file 402 has been modified and can no longer be trusted to perform the functionality that it was intended to perform.
The IV result is sent back to the kernel 306 via the LSM 312 (e.g., “OK” if the IV verification is successful) (step 4 of
The user application contents are relocated into Virtual Memory Areas (VMAs) allocated by the kernel for use by the user application process 406. To relocate the contents, the executable loader 410 processes the executable file as shown in
The relocated contents are typically branch-target addresses and thus affect control-flow of the application process, resulting in possibly becoming attack targets. The Kernel Agent 310 conducts the in-memory IV verification of the VMA(s) as shown in
In the case that the IV verification is successful, restoration of a missing code and/or data (or “MP”) is granted. The Kernel Agent 310 binds the user application process 406 to the Kernel Agent (and the SW TEE) 310 by restoring a missing piece of code and/or data (or “MP”) 420 of the original user application executable, in the user application process 406 memory, as shown in
The Kernel Agent 310 injects the MP 420 at the appropriate location in the VMA(s). In a non-limiting example, a dummy value(s) used in the user application provisioning process (200A of
By completing the IV of VMAs and restoring the missing piece of code and/or data 420 into the user application process 406 memory, the user application process 406 is fully verified and trusted and able to operate as originally intended (in contrast, if the IV verification fails at any stage, the Missing Piece code and/or data will not be provided by the KA, and the application process will not operate as originally intended). The resultant user application module 406 performs the functionality that the original version of the user application (e.g., 202 of
To accept or deny the call to create the user-space process, the Kernel Agent 310 may add further criteria including, for example, but not limited to, system/application integrity, application permissions, application behavior, security context for other applications that may be running and remote commands.
Referring to
The Kernel Agent 534 maintains and has sole access to the secured data store 532 within which the Kernel Agent 534 keeps information relevant for the Kernel Agent's performance of kernel resource access control, Integrity Verification, application licensing and application resource access control. While the secure store 532 is shown in
The Kernel Agent 534 is Linux Security Module interface (LSM I/F) compliant. The Kernel Agent 534 forms an integral and un-detachable part of the OS kernel 530 without which the kernel based OS and/or the applications 520a, 520b will cease to function correctly. In order to render the Kernel Agent 534 resistant to tampering, modification, and reverse engineering attacks, the Kernel Agent 534 may be protected using software protection techniques such as, but not limited to, those described in more detail in U.S. Pat. Nos. 6,594,761, 6,779,114, 6,842,862, and 7,506,177 each issued to Chow et al.
One example of the functions of the Kernel Agent 534 is to monitor the integrity of both the kernel based OS and the user applications 520a, 520b loaded onto the platform 500, and to detect any breaches of the OS 530, secure boot 550 and the user applications 520a, 520b. The IV may be conducted as shown in
A further example of the functions of the Kernel Agent 534 may include controlling application access to OS kernel resources and data where the access control decisions may be made by the Kernel Agent based on, but not limited to, factors such as: OS kernel integrity, application integrity, application context, and the privileges granted by any given trusted root authority. An access control decision based on OS kernel integrity determines whether the kernel has been modified, been replaced, been added to, or had portions removed in an unauthorized manner. The access control decision may also determine whether the secure boot process completed in successfully (i.e. without tampering). If the OS kernel has been modified, replaced, added to or portions removed or the secure boot process cannot be positively verified, this determination would serve to invalidate many of the assumptions that the Kernel Agent or an application or a secure application such as a media player would normally operate under. An access control decision based upon application integrity determines whether the application that is attempting to access OS kernel resources has been modified in any way (e.g., to insert malware into the application or by other malware) or whether the privileges associated with that application been modified (e.g., to give it privileges to access system resources that were not authorized by the certifying authority).
Each element in the embodiments of the present disclosure may be implemented as hardware (e.g., general and/or specialized computer processor), software/program in a carrier, or any combination thereof. Software codes, either in its entirety or a part thereof, may be stored in a computer readable medium (e.g., as a ROM, for example a CD ROM or a semiconductor ROM, or a magnetic recording medium, for example a floppy disc or hard disk), and may be executed by a computer processor. The program may be in the form of source code, object code, a code intermediate source and object code such as partially compiled form, or in any other form. A computer data signal representing the software code which may be embedded in a carrier wave may be transmitted via a communication network. The carrier may be any entity or device capable of carrying the program. Further the carrier may be a transmissible carrier such as an electrical or optical signal, which may be conveyed via electrical or optical cable or by radio or other means. When the program is embodied in such a signal, the carrier may be constituted by such cable or other device or means. Alternatively, the carrier may be an integrated circuit in which the program is embedded, the integrated circuit being adapted for performing, or for use in the performance of, the relevant method.
One or more currently preferred embodiments have been described by way of example. It will be apparent to persons skilled in the art that a number of variations and modifications can be made without departing from the scope of the invention as defined in the claims.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/CA2013/000288 | 3/26/2013 | WO | 00 |
