CN112912879A

CN112912879A - Apparatus and method for inter-process secure messaging

Info

Publication number: CN112912879A
Application number: CN201880096333.5A
Authority: CN
Inventors: 珍妮·哈马莱宁; 连刚; 安蒂·鲁萨宁; 叶宗波; 杨宗俊
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2018-08-08
Filing date: 2018-08-08
Publication date: 2021-06-04
Also published as: WO2020030270A1

Abstract

An apparatus includes a processor to execute non-transitory machine-readable program instructions. The processor is configured to associate a sending application with a first security category and associate a receiving application with a second security category. The processor is configured to receive an inter-process message from the sending application in a message router, wherein the inter-process message includes an indication of the sending application and the receiving application. The processor determines a permission for the inter-process message based on the first security category and the second security category. The processor forwards the inter-process message to the receiving application when the authority is granted, and blocks the inter-process message when the authority is denied. Associating the first and second applications with a security category significantly simplifies configuration of messaging rules and security policies for applications installed on a computing device.

Description

Apparatus and method for inter-process secure messaging

Technical Field

Aspects of the present disclosure relate generally to mobile computing devices, and more particularly, to security mechanisms used in mobile computing devices.

Background

Software applications designed for modern mobile computing devices are often used as a collection of activity-oriented services, rather than as stand-alone applications or software programs. Popular mobile operating systems or application frameworks such as ANDROID, IOS or WINDOWS provide rich inter-process communication (IPC) mechanisms to seamlessly integrate these activity-oriented applications into a single unified user experience.

Open standards and well documented computing platforms may produce many different software applications developed from many different sources. The device manufacturer and/or distributor will no longer always have control over all software applications. To mitigate the risks posed by software applications originating from unknown and often untrusted sources, various inter-process communication IPC mechanisms may be included in the software operating platform. Some IPC messages trigger user prompts, asking the user to grant permission or select an application to process the message. This type of permission check may be referred to as a reference monitor and is included in some IPC mechanisms. Disadvantageously, the user may not understand the requested rights or consider the pop-up window to be cumbersome.

The operating platform may attempt to improve security by imposing requirements when installing the software application, such as requiring any new software packages to be cryptographically signed by a known authority before installing the software. However, this may limit the scope and types of software applications that may be available for the mobile computing device.

Alternatively or in addition, a message firewall or message router may be used to control IPC message traffic. The ANDROID Intent Firewall (ANDROID INTENENT FIREWall) is an example of a rule-based message router. The rules used in rule-based message routers can be complex and require consideration of both the source and destination at the same time when configured. While it is sometimes possible to automate the update, it is still necessary to evaluate each application and design rules that match the requirements of the application and the security policy. This can be an expensive and time consuming process.

With the increasing number of applications and the growth of new sophisticated security attacks, existing IPC messages have proven to be insufficiently protected. Complex applications may take advantage of enforcement flaws to gain access to privileged services and to break system security. Malicious applications are becoming more and more complex and distributed more and more widely. Accordingly, there is a need for improved apparatus and methods for controlling and securing IPC messaging in mobile computing devices. Accordingly, there is a need to provide methods and apparatus that address at least some of the problems described above.

Disclosure of Invention

It is an object of the present invention to provide improved methods and apparatus for managing and controlling inter-process communications among many applications executing on a computing device in a simplified manner.

The above and further objects and advantages are obtained according to a first aspect by an apparatus comprising a processor for executing non-transitory machine-readable program instructions. The processor is configured to associate the sending application with a first security category and associate the receiving application with a second security category. The processor is configured to receive an inter-process message from a sending application in a message router, wherein the inter-process message includes an indication of the sending application and the receiving application. The processor determines authority for the inter-process message based on the first security category and the second security category. When granted, the processor forwards the inter-process message to the receiving application, and when denied, the processor blocks the inter-process message. Associating the first and second applications with a security category significantly simplifies the effort required to configure messaging rules and security policies for applications installed on the computing device.

In a first possible implementation form of the apparatus according to the first aspect, the inter-process message comprises an indication of a type of the message, and the processor is configured to determine the authority of the inter-process message based on the type of the message. The type of message includes one or more of an action category and an acted data category. Including message types such as action type and data type allows different messaging rules to be associated with the security type of different types of messages.

In a second possible implementation form of the apparatus according to the first aspect as such, the processor is configured to modify a state of the processor based on the inter-process message, and to determine the authority of the inter-process message based on the modified state of the processor. This leads to improved safety within the device. For example, the rights to secure cryptographic operations should be determined within a secure execution environment rather than in a less secure, non-secure world execution environment.

In another possible implementation form of the apparatus, the processor is configured to determine one or more of the first security category and the second security category based on information related to one or more of the sending application and the receiving application, wherein the information related to one or more of the sending application and the receiving application includes one or more of: virus scans, data obtained from social certification services, device user input, installation information, vendor rights, application specific security requirements, and machine learning applications. Determining a desired security category based on a wide range of information sources can improve the security of the device by more reliably selecting the security category associated with each application.

In another possible implementation form of the apparatus, the processor is configured to give priority to the user input when determining one or more of the first security category and the second security category. It is often desirable to allow the user to override any automatic determinations made by the device.

In another possible implementation form of the apparatus, the processor is configured to determine one or more of the first security category and the second security category based on the vendor rights when the installation information indicates one or more of the sending application and the receiving application originating from an untrusted source. Giving the vendor the right to determine the best security category of the application provides a reliable way for the vendor to thoroughly test the application by all other software components distributed on the device.

In another possible implementation form of the apparatus, the processor is configured to change one or more of the first security class and the second security class to a more trusted security class when the authority for the inter-process message has not been denied for a predetermined amount of time or a predetermined amount of the inter-process message has been sent between the sending application and the receiving application. Modifying or changing the security class associated with the application allows the device to adapt to changing conditions and usage patterns. The change conditions may include, for example, changes in the number and type of software applications installed on the device, changes in the manner in which the device is used, and changes in the network to which the device is connected, as well as any other changes in the environment or use of the device.

In another possible implementation form of the apparatus, each security category is associated with one or more messaging policies, and the processor is configured to dynamically modify the one or more messaging policies. Dynamically modifying the message policies associated with the security classes allows the device to adapt to changing conditions and usage patterns.

In another possible implementation form of the apparatus, one or more of the sending application and the receiving application are members of a group of highly protected applications, and the processor is to associate a highly protected security category with the group of protected applications, wherein the group of protected applications is defined by one or more of: the provider of the application, the provider rights and the user input. Identifying an application as a highly secure application allows for a more secure and reliable association of security categories with applications.

In another possible implementation form of the apparatus, the processor is configured to record the rights and associated interprocess message information in a message delivery history, and to modify one or more of the first security class and the second security class based on the message delivery history. Maintaining a history of IPC messages and permissions allows identification of malicious applications that repeatedly attempt to infiltrate sensitive data or operations, or identification of well-behaved applications and modifying the trust level of the applications accordingly.

In another possible implementation form of the apparatus, the processor is configured to associate a sending application with a first one or more security categories, associate a receiving application with a second one or more security categories, and determine the authority of the inter-process message based on the first one or more security categories and the second one or more security categories. Associating applications with multiple security classes allows for better control of IPC messages for applications that may have a wide range of functionality and IPC messaging requirements.

In a further possible embodiment of the device, the first security category is identical to the second security category. It is often desirable to allow inter-process communication between applications associated with the same security class.

In another possible implementation form of the apparatus, modifying the state of the processor includes switching the processor state from the non-secure world execution environment to the secure execution environment.

In another possible embodiment of the device, the device is a mobile telephone.

The above and further objects and advantages are obtained according to a second aspect by a method comprising associating a sending application with a first security class, associating a receiving application with a second security class, receiving an inter-process message from the sending application in a message router, wherein the inter-process message comprises an indication of the sending application and the receiving application. The method determines the authority of the inter-process message based on the first security category and the second security category. When granted, the method forwards the inter-process message to the receiving application, and when denied, the method blocks the inter-process message. Associating the first and second applications with the security category significantly simplifies configuration of messaging rules and security policies for the applications.

In a first possible implementation form of the method according to the second aspect, the method comprises determining one or more of the first security category and the second security category based on information related to one or more of the sending application and the receiving application, wherein the information related to one or more of the sending application and the receiving application comprises one or more of: virus scans, data obtained from social certification services, device user input, installation information, vendor rights, application specific security requirements, and machine learning applications. Determining a desired security category based on a wide range of information sources can improve the security of the device by more reliably selecting the security category associated with each application.

The above and further objects and advantages are obtained according to a third aspect by a non-transitory computer readable medium having stored thereon program instructions which, when executed by a processor, cause the processor to perform a method according to the second aspect or the first implementation form of the second aspect.

These and other aspects, implementations, and advantages of the exemplary embodiments will become apparent from the embodiments described herein, when considered in conjunction with the accompanying drawings. It is to be understood, however, that the description and drawings are for purposes of illustration only and not as a definition of the limits of the disclosed invention, for which reference should be made to the appended claims. Additional aspects and advantages of the invention will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Furthermore, the aspects and advantages of the invention may be realized and obtained by means of the instrumentalities and combinations particularly pointed out in the appended claims.

Drawings

In the following detailed description of the present disclosure, the invention will be explained in more detail with reference to exemplary embodiments shown in the drawings, in which:

FIG. 1 illustrates a block diagram of an exemplary computing device for providing an improved inter-process message mechanism in accordance with aspects of the disclosed embodiments.

FIG. 2 illustrates a block diagram of an exemplary computing device for providing an alternative improved inter-process message mechanism in accordance with aspects of the disclosed embodiments.

FIG. 3 illustrates a flow diagram of an exemplary method for providing secure inter-process message processing within a mobile computing device in accordance with aspects of the disclosed embodiments.

Detailed Description

FIG. 1 illustrates a block diagram of an exemplary computing device 100 for providing an improved inter-process message passing mechanism, according to an embodiment of the present disclosure. The computing device 100 may be incorporated into various types of computing devices and mobile communication devices, such as cell phones, tablet computers, notebook computers, set-top cable boxes, televisions, automobiles, and the like, and may be advantageously used to provide secure and reliable interprocess communication services to user applications running on the computing device 100. In the exemplary computing device 100, a processor 152 is coupled to memory 154 and is used to read and execute non-transitory program instructions stored in computer memory 154.

In one embodiment, the processor 152 of the apparatus 100 is configured to associate the sending application 108 with a first security category; associating the receiving application 112 with a second security category; and receiving an inter-process message 128 from sending application 108 in message router 116. The inter-process message 128 includes an indication of the sending application 108 and the receiving application 112. The processor 152 is also configured to determine the authority of the inter-process message 128 based on the first security category and the second security category. When granted, the inter-process message 128 is forwarded to the receiving application 112. When the rights are denied, the inter-process message 128 is blocked.

The processor 152 may be a single processing device or may include multiple processing devices including dedicated devices such as Digital Signal Processing (DSP) devices, microprocessors, dedicated processing devices, parallel processing cores, or general purpose computer processors. In some embodiments, the processor 152 may include a Central Processing Unit (CPU) working in conjunction with a Graphics Processing Unit (GPU), which may include a DSP or other dedicated graphics processing hardware.

Memory 154 may be any suitable type of computer memory capable of storing computer program instructions and/or data. The memory 154 may be a combination of various types of volatile and non-volatile computer memory, such as Read Only Memory (ROM), Random Access Memory (RAM), magnetic or optical disk, or other types of computer operable memory capable of holding information and making stored information available to the processor 152 communicatively coupled to the memory 154.

The memory 154 is used to store software program instructions or software programs and associated data that may be useful to the computing device 100. The software programs stored in memory 154 are organized into various software modules or components, which may be referred to using terms that indicate the type or functionality provided by each software component. For example, the stored software components may include an Operating System (OS), a hypervisor, a device or other hardware driver, and/or various types of user applications such as a media player, an email application, a banking application, and so forth.

Applications

108, 112 are examples of user applications, and system 114 is an example of an executive, such as an operating system.

It is sometimes desirable to install new or updated user applications onto computing device 100. The user applications or

applications

108, 112 may be installed individually or as part of a package or software package that includes one or more applications, if desired. A software package is a collection of one or more related software applications delivered together by a software provider and may include software utilities and other data for supporting the included applications.

The

applications

108, 112 may be executed by the processor 152, individually or in combination, within a group of computing resources referred to as a process space or

process

106, 110. Each

process

106, 110 is maintained separately by the processor 152 and includes its own set of computing resources. The collection of computing resources associated with a

process

106, 110 is accessible to software programs or

applications

108, 112 executing within the

process

106, 110 and may include resources such as virtual memory space and/or hardware components. The processor 152 is used to manage, and, if necessary, to shield the computing resources belonging to one

process

106, 110 from access or modification by the

software application

108, 112 executing in the

other process

106, 110. For example, system 114 can be used to prevent application 108 executing in process 106 from accessing or modifying a computing resource, such as a portion of memory 154 that has been allocated for use by application 112 within process 110.

In modern open computing environments, such as computing device 100,

applications

108, 112 may be obtained from many different sources or vendors. Therefore, for security purposes, it is important to control the communication between the

applications

108, 112. For example, it would be dangerous to allow a gaming application downloaded from an unknown source to access a banking application executing on the same device. To maintain the security and integrity of the computing device 100, these

applications

108, 112, which may originate from unknown or untrusted sources, may run in different

independent processes

106, 110, such that the system 114 may prevent one application 108 from accessing or corrupting information belonging to another application 112. To facilitate and regulate communication between

applications

108, 112 executing in

different processes

106, 110 on the computing device 100, the system 114 provides an inter-process communication (IPC) mechanism 134 that, in the illustrated embodiment, includes an IPC router 116 for sending messages between the

applications

108, 112 in a secure and controlled manner.

The processor 152 is used to implement and enforce a priority system that provides a way to protect certain applications or processes from other processes' corruption or abuse. This priority system prevents programs or processes executing at a lower priority from modifying or otherwise corrupting or abusing programs or processes executing at a higher priority. In the computing device 100, the system 114 executes at a higher priority than the

applications

108, 112 or their

respective process spaces

106, 110. Thus, the priority system prevents application 108 from tampering with IPC router 116 or other system 114 components to gain unauthorized access to another application 112 or to send unauthorized messages to another application 112.

It is desirable to have

many applications

108, 112 installed and potentially executing on the computing device 100 simultaneously. These

applications

108, 112, which are typically available from many different sources, are used to provide a wide range of features and functionality. To maintain the integrity of the computing device 100, the system 114 is used to execute

applications

108, 112 in different

independent processes

106, 110 and to prevent one application 108 executing in one independent process 106 from accessing or corrupting the computing resources of another application 112 executing within a different process 110. To improve security, direct communication between

applications

108, 112 executing in

different processes

106, 110 is not allowed. All communication between

applications

108, 112 executing in

different processes

106, 110 is accomplished through IPC mechanisms 134 managed by the system 114.

Users of modern computing devices (e.g., cell phones, tablets, etc.) have begun to expect a consistent integrated user experience among all software applications running on their computing devices. To support such a consistent integrated computing experience, applications designed to execute on modern computing devices, such as computing device 100, are designed as a collection of components and services that expose published interfaces for use by other applications running on computing device 100. Integration of such a multi-application environment is facilitated by including an IPC messaging mechanism 134 or infrastructure within the system 114 to allow applications to communicate with each other and utilize services exposed by other applications.

When an application 108 executing in one independent process 106 needs to communicate with another application 112 running in a separate independent process 110, an IPC message 128 may be sent to the IPC router 116, where the message may be forwarded 130 to the receiving application 112. Because the IPC message router 116 executes as part of the system process 114, the

applications

108, 112 cannot tamper with or otherwise interfere with the operation of the IPC router 116. Thus, based on a set of rules or other desired criteria or logic, the IPC router 116 may determine whether to forward 130 the message 128 to the receiving application 112, block the message, or perform other desired billing or data collection based on the IPC message 128. The IPC router 116 is used to control all communications between the

applications

108, 112. Included in the IPC message routing component 134 are various rules and policies that control how and when to forward 130, block, or otherwise process IPC messages 128.

To aid understanding, consider a solution based on ANDROID developed by GOOGLE Inc^TMA conventional computing device operating the framework. In ANDROID^TMIn the operating environment, certain types of interprocess messages 128 are referred to as intents. ANDROID^TMA conventional IPC routing component, called an activity manager, is included that can be used to coordinate with the intended firewall. An intent firewall employs a set of rules to determine when an intent should be forwarded, blocked, or otherwise processed. In for example event managers and intentsIn conventional IPC routing systems for graph firewalls, these messaging rules need to be configured separately for each application, and each application needs to have its own set of routing rules. Configuring these rules for each application can be cumbersome and error prone. A user or administrator needs to study the functionality and requirements of each application to determine which applications are secure and what messaging rules should be created for each application.

In addition, the configuration of these rules may require that the administrator have a higher level of authority than the expected ordinary users, thereby limiting which users can configure the rules. Users who want to modify routing rules may be granted a higher level of permission, thereby creating a greater security risk. It is also difficult for a normal user to know what services an application actually needs and what services may cause a security breach.

Presented herein is a novel approach for reducing the amount of configuration work required and reducing the knowledge required by users and/or device administrators. In contrast, rather than creating messaging rules for each application as in conventional computing devices, the computing device 100 is used to classify applications into a relatively small number of categories and define the messaging rules and security policies for each category. Because the number of security classes is significantly less than the total number of

applications

108, 110, the amount of work required to configure messaging rules and security policies for each security class is much less than the amount of work required to configure rules and policies separately for each application.

The messaging rules and/or security policies may also be assigned to each category in advance without knowledge of all the various applications that may be installed on the computing device 100. Each type of rule may be configured by a skilled administrator when the device 100 or software component is initially developed or configured. These rules can also be easily modified at intervals thereafter. When a

new software application

108, 112 is installed, it may be classified or associated with one of the security classes. Once an application is associated with a security class, the application will inherit the appropriate set of inter-process communication rules from the assigned or associated security class.

The computing device 100 includes a security class service 118 for executing various services that support the IPC router 116. The security class service 118 may assign or classify applications into security classes, process messaging rules, and security policies, and determine 132 how to process the

inter-process messages

128, 130. The class database 120 is used to store inter-process messaging rules and security policies for each security class and to store information that supports assigning or classifying applications into security classes. The category Database (DB) 132 may also store any information needed to enhance the operation or audit of the security category service 118.

The set of security classes to which the security class service 118 associates an application may be any desired size. A large number of security classes provide finer control over the messaging rules or policies applied to a

particular application

108, 112, while a smaller number of security classes simplifies the configuration of security within the IPC messaging mechanism.

In some embodiments, it may be desirable to update the category DB 120 from time to time with new or modified information, or to remove outdated or undesirable information. For example, it may be advantageous to include new or modified messaging rules, security policies, security categories and/or category association rules, and the like. Updating the category DB 120 is advantageous and allows the device 100 to adapt to new security threats, new or modified application types, and to change user requirements.

At the time of installation of the

applications

108, 112 or at intervals thereafter, the security class service is used to obtain information about the installed

applications

108, 112 and use this information, along with information stored in the class DB 120, to assign security classes to the newly installed

applications

108, 110.

The security service 118 is used to gather information from the system services 122, 124, 126 that may have knowledge about the

applications

110, 112, and to use this information to assist in the assignment or association of appropriate security classes.

In one embodiment, the system services 122, 124, 126 for gathering information about installed

applications

108, 112 may include a virus scanner 122, a social attestation service 124, or input 126 obtained from a user of the computing device 100. The virus scanner 122 checks the software and data being installed for known viruses or other security threats or malware signatures. The social attestation service 124 is a service that scans public networks, such as the internet, to locate information about installed

applications

108, 112 and/or about experiences of other users who have installed, rated, or are using the applications. Input from a user of the computing device 100 may be requested by the user input 126 component.

The security category service 118 associates the

applications

108, 112 with security categories based on information obtained from the system services 122, 124, 126, information stored in the history DB, and/or any other suitable information available about the

applications

108, 112 and the computing device 100. The security category service 118 may also be used to apply rules to input obtained from the system services 122, 124, 126 when selecting security categories to associate with the

applications

108, 112. For example, in one embodiment, user input 126 obtained from a user of computing device 100 may be used to override information provided by virus scanner 122 and/or social attestation service 124.

As described above, the computing device 100 is used to prevent one application 108 from sending the message 128 directly to the second application 112. In the computing device 100, all inter-process messages 128 must be sent to the IPC router 116. The IPC router 116 contacts 132 the security class service 118 to determine how the message should be processed and, when allowed, the IPC router 116 forwards 130 the message to the receiving application 112.

When the IPC router 116 receives the message 128, it contacts 132 the security class service 118 to determine how the message 128 should be processed. The security class service then examines all information about the message 128, such as the type of message, the message content, and the application 108 that sent the message 128 and the application 112 to which the message 128 may be forwarded 130, to make a determination as to how the message 128 should be processed.

The type of the inter-process message 128 may be used to indicate the kind of action requested by the inter-process message 128. For example, the category of action may be an encryption service, a name lookup in an address book, displaying information to a user, or any other useful service or action. The type of message may also indicate the type of data included in the message. The data may include, for example, passwords, photos, media files, or other kinds of data as desired.

The messaging rules for the IPC message 128 may then be identified based on the first security category associated with the sending application 108 and the second security category associated with the receiving application 112. The first security category and the second security category may be the same or may be different. The security category service 118 then determines whether to block or forward the IPC message 128 based on information obtained from the category DB 120, e.g., messaging rules and/or security policies corresponding to the first and second security categories.

The security class service 118 may also request information from the user input service 126 to assist it in determining how to process the IPC message 128. The user input service 126 may request information directly from the user. Alternatively, the user input service 126 may rely on previously obtained user input or predetermined default values. In one embodiment, the information received from the user input 126 may override the messaging rules or other information stored in the category DB.

In some embodiments, the

applications

108, 112 may be associated with multiple security classes. In these embodiments, the security category service 118 may consider messaging rules and other information associated with all security categories associated with both the sending application 108 and the receiving application 112.

The IPC message 128 may be forwarded 130 to the receiving application 112 or may be blocked. As will be discussed further below, in addition to forwarding or blocking messages 128, the IPC router 116 or the Security class service 118 may also be used to perform other desired operations. For example, it may be advantageous to quarantine certain applications based on their attempts to access unauthorized services, record audit trails in the history database 140, or any other desired type of security-related process.

In one embodiment, the security class service 118 is used to maintain a history DB 140 having information about processed messaging requests 128. The history database 140 may record information about the sending and receiving applications, the IPC messages 128, the security categories associated with the sending application 108 and the receiving application 112 in processing the IPC messages 128, and the results of processing the message requests 128. The result of processing the message may include information about whether to forward 130 or block the message. In some embodiments, information about the permissions and rules considered in processing the n inter-process message transfers 128 may advantageously be included in the history database 140. The information stored in the history DB 140 may be used as an audit trail or for other auditing or monitoring operations.

The information in the history DB 140 may be used by the security class service 118 to dynamically adjust one or more security classes associated with each

application

108, 112. For example, if the application 108 is found to be sending message requests 128 that are successively rejected by the security class service 118, the security class service 118 may identify this as a possible security problem or malicious application and adjust the security class associated with the sending application 108 accordingly. Similarly, the security category of the receiving application may be adjusted to increase security according to possible new security threats. Similarly, applications may be associated with highly restrictive security classes when first installed, and over time, when applications are observed to perform well, as indicated by information in the history DB 140, the security classes may be adjusted accordingly. In some embodiments, it may be desirable to dynamically adjust security classes associated with the

applications

108, 112 based on other inputs, such as inputs received from the virus scanner 122 and the social attestation service 124.

In one embodiment, the security category service may associate the

applications

108, 112 with a security category at installation based on information about the type of application that began installation. This is particularly useful when the

application

108, 112 is obtained from a trusted source and is cryptographically signed, for example, in a manner that allows the content of the application to be verified prior to installation. As used herein, a trusted application is a software program that is obtained from a trusted source and cryptographically signed in such a way. It may be advantageous to associate trusted applications with a higher security category than untrusted applications, such as applications obtained from unknown or unverified sources.

For example, a banking application obtained from the user's own bank or a media player obtained from a well-credited software company may receive a higher degree of trust and be associated with a security category that indicates a higher level of trust and allows access to sensitive services. In contrast, games downloaded from unknown sites on the internet should be associated with a security category that indicates a low trust level and prevents access to any sensitive information or services.

As used herein, the term "more trusted security category" refers to a security category that is allowed to access a larger number of system services or that is allowed to exchange messages with a larger number of applications or that may be allowed to access more sensitive security services than another security category. Thus, changing the security class with which the

application

108, 112 is associated to a more trusted class can increase the services or resources with which the

application

108, 112 is allowed to exchange IPC messages 128.

Once the security class service 118 has made a determination as to how to process the message 128, the security class service 118 returns its determination to the IPC router 116. The IPC router 116 then blocks or forwards 130 the IPC message 128 based on the information returned from the Security class service 118.

FIG. 2 illustrates a block diagram of an example computing device 200 for providing an improved inter-process message passing mechanism, according to an embodiment of the present disclosure. The computing device 200 is similar to the computing device 100 described above with respect to fig. 1, wherein like reference numerals shown in fig. 2 correspond to like components described above with reference to fig. 1. The example computing device 200 employs a distinctly different approach to associating security classes with

applications

108, 112 and is configured with distinctly

different system services

202, 204, 206 that may be used by the security class service 218 to

associate applications

108, 112 with security classes or to classify

applications

108, 112 with security classes. The security category service 218 of the computing device 200 is used to automatically associate security categories with the

applications

108, 112 based on input obtained from the package installer 202, the vendor rights service 204, the proprietary security requirements 206, and/or the machine learning application 208.

The package installer 202 is used to install the

software applications

108, 112 on the computing device 200. During the installation process, information about the

application

108, 112 being installed may be obtained from the package installer 202 by the security class service 118. This information, referred to herein as installation information, may include cryptographically signed verification results, verification results of certificates and signature information, identification results of the source or vendor of the software, services and computing resources required or requested by the software being installed, and the like.

The vendor rights 204 refer to the management (cure) of known software applications by the vendor of the computing device 200. Software that has been tested and managed by the computing device 200 vendor may be given increased trust and privileges based on the results of such testing and management. Alternatively, the management package may be marked as a risk by the vendor and associated with a security category with limited privileges. The vendor entitlement service 204 provides vendor entitlement information to a security class service 218, which may be used when associating or classifying applications with security classes.

The software products or

applications

108, 112 may specify or request particular security requirements at an appropriate or desired time upon installation on the computing device 200 or thereafter. The security requirements of these requests may be processed by the application security service 206 and provided to the security class service 218 as an aid to associating the

applications

108, 112 with the security class. These security requirements may be handled and considered during the security class service 218 automatically associating security classes. Alternatively, these security requirements may be combined with other input or user data to support associating the

applications

108, 112 with security categories.

By including various machine learning applications 208 that can provide information to the security classes service 218, associating or classifying applications with security classes can improve over time. Machine learning applications can be used to adjust the manner in which applications are classified or associated with security categories. Machine learning 208 may also be used to adjust security policies or messaging rules associated with each security category. The machine learning application 208 may, for example, view the behavior of the

applications

108, 112 and move the applications to different security categories or change the security categories with which the applications are associated.

In a system such as computing device 200, vendor rights 204 may take precedence in associating security categories, however, private security requirements 206 may still deny access to less secure applications. Prioritizing the vendor rights 204 may be advantageous because vendors are often in the best position as system integrators to determine the security of the entire software environment running on the computing device 200.

In one embodiment, the security class service 218 may recognize the

applications

108, 112 as belonging to a group of highly protected applications and associate the

applications

108, 112 with a highly protected security class. A highly protected security class is a security class that has certain messaging rules designed to prevent or limit unauthorized access to services provided by an application. Recognizing that the

application

108, 112 belongs to a group of highly secure applications may be based on any of the criteria described above, such as the provider of the application, which may be determined by the package installer 202, the vendor rights 204, the application specific security requirements 206, or additional information such as the user input 106.

In some embodiments, there may be many client applications that require or want to interact with services from a group of highly secure applications. Because the number of client applications can be extremely large, it is not feasible to classify and individually configure security policies and messaging rules in advance. To address this configuration problem, a relatively small number of security policies and messaging rules for security classes may be configured, followed by crowd sourcing, also known as social attestation, or other such methods as described above, may be used to automatically assign each client application to one of the configured security classes.

Thus, by default, the application will not have access to the protected application. If an input source, such as a social proof input source, indicates that there are enough people to rate the application high enough, it is upgraded to a less restrictive policy and access to the protected application is granted. Classification may also be based on testing applications through trusted application malls or even Artificial Intelligence (AI) systems. Conversely, if an application is marked by a virus scanner as a potentially malicious program, the application is denied access to a group of highly secure applications.

To assist in understanding, the

security category services

118 and 218 used in the

computing devices

100 and 200 are described above as having distinctly different functionality and features for associating security categories with the

applications

108, 112. Those skilled in the art will readily recognize that various combinations of the features of the security class service 118 and the security class service 218 are possible and may be advantageously employed in a computing device without departing from the spirit and scope of the disclosed embodiments.

In some embodiments, a high degree of security is required. For example, the processor 102 may support multiple execution states, one of which is a trusted execution environment or a secure execution environment, and another of which is a less secure environment that may be referred to as an unsecure world execution environment. When the processor 102 supports multiple execution states, it may be advantageous to: the

security class service

118, 208 is executed within a highly secure execution state, e.g., a trusted execution environment, while execution of the

application

108, 112 will remain in a non-secure world execution state. For some types of IPC messages 128, it may be advantageous: the state of the processor 102 is changed or modified to a more secure state or execution environment, such as a secure execution environment, and the

security class service

118, 218 is executed within this highly secure state. This allows for determining the rights, e.g., how to process IPC messages 128 to be protected in a highly secure state.

Advantageously, the

security class service

118, 218 is executed within a secure state or execution environment, for example, when the requested service also needs to be executed within a highly secure state or execution environment. An IPC message 128 requesting a cryptographic operation that relies on confidential material is one example of an IPC message 128 that would benefit from having the

security class service

118, 218 execute within a trusted or secure execution environment or state.

FIG. 3 shows a flow diagram of an exemplary method 300 for providing secure IPC message processing within a mobile computing device or other type of computing device as desired. The exemplary method 300 is suitable for use on various types of computing devices, such as the computing device 100 and the computing device 200 described above.

The method begins by associating 302 a sending application with a first security class at an appropriate time when or after the application is installed on the computing device. The receiving application is associated 304 with a second security category. Alternatively, the receiving application may be associated 304 prior to sending the application, as desired. The first security category may be the same as the second security category, or the first and second security categories may be different. In some embodiments, it may be advantageous to associate more than one security category with an application.

During execution of the sending application and the receiving application, the sending application may want to send a message to the receiving application. For example, a text sending application may need to request a photo from an album application in order to attach the photo to a text message. In this case, the message router will receive 306 an IPC message from the first application. IPC messages will include information about the type of sending application, receiving application and message, as well as other information needed to send and receive applications.

Next, the authority for the IPC message is determined 308 based on the information included in the IPC message and the security categories associated with the sending application and the receiving application. Each security class will have one or more messaging rules and security policies associated with it. These messaging rules provide the basis for determining whether permission to send IPC messages should be granted. When the authority is granted, the IPC message is forwarded 312 to the receiving application. When not granted, transmission of the message is blocked 316.

After forwarding 312 or blocking 316 the IPC message, it may be necessary to change 314 the security class associated with the sending application or the receiving application. For example, if the sending application attempts to send a message to a highly sensitive service, such as a banking service, that the sending application does not have access to and should not attempt to access, it may be desirable to associate the sending application with a higher restrictive or lower trusted security category. In some cases, it may be desirable to associate the sending application with a security class that indicates that the application is isolated, such as a security class that has messaging rules that do not allow the application to send any messages.

In some embodiments, after determining the permissions 308, information about the IPC message and the resulting permissions determination 308 is stored in a history store or database. This historical database may then be used when changing 314 the security category associated with the application. For example, when an application is initially installed, it may be associated with a relatively restrictive security category. As used herein, a relatively restrictive security category refers to a security category having messaging rules that grant permission to send messages only to services that are deemed secure or pose no significant security risk. After the application has been in use for a period of time, the history DB may show that the application is performing well or is not attempting to access sensitive services or information and has only sent messages consistent with its intended functionality. Well-behaved applications may need to be promoted to a less restrictive or more privileged class of security, thereby allowing them to extend their functionality by sending messages to a wider variety of system services.

If no abuse is made of a new functionality enabled in moving an application to a higher trusted security category having a higher trusted security policy, the trust provided to the application by the associated security policy is gradually increased by changing the security category associated with the application. Security policies or messaging rules associated with each security category may be predefined or dynamically created.

Thus, while there have been shown, described, and pointed out fundamental novel features of the invention as applied to exemplary embodiments thereof, it will be understood that various omissions and substitutions and changes in the form and details of the devices and methods illustrated, and in their operation, may be made by those skilled in the art without departing from the spirit and scope of the presently disclosed invention. Moreover, it should be recognized that structures and/or elements shown and/or described in connection with any disclosed form or embodiment of the invention may be incorporated in any other disclosed or described or suggested form or embodiment as a general matter of design choice.

Claims

1. An apparatus (100), comprising:

a processor (152) for executing non-transitory machine-readable program instructions, wherein the processor (152) is for:

associating the sending application (108) with the first security category and;

associating the receiving application (112) with a second security category;

receiving an inter-process message (128) from the sending application (108) in a message router (116), wherein the inter-process message (128) comprises an indication of the sending application (108) and the receiving application (112);

determining a right of the inter-process message (128) based on the first security category and the second security category; and

upon granting the right, forwarding the inter-process message (128) to the receiving application (112); and blocking the inter-process message (128) when the rights are denied.

2. The apparatus (100) of claim 1, wherein the inter-process message (128) comprises an indication of a type of message, and wherein the processor (152) is configured to determine the authority for the inter-process message (128) based on the type of the message, wherein the type of the message comprises one or more of an action category and an acted-upon data category.

3. The apparatus (100) of any of claims 1 or 2, wherein the processor (152) is configured to:

modifying a state of the processor (152) based on the inter-process message (128), an

Determining the authority of the inter-process message (128) based on a modified state of the processor (152).

4. The apparatus (100) of any one of the preceding claims, wherein the processor (152) is configured to determine one or more of the first security class and the second security class based on information related to one or more of the sending application (108) and the receiving application (112), wherein the information related to the one or more of the sending application (108) and the receiving application (112) comprises one or more of: a virus scan (122), data obtained from a social attestation service (124), input from a user (126) of the apparatus (100), installation information (202), vendor rights (204), private security requirements (206), and a machine learning application (208).

5. The apparatus (100) of claim 4, wherein the processor (152) is configured to give priority to user input when determining the one or more of the first security category and the second security category.

6. The apparatus (100) of claim 4, wherein the processor (152) is configured to determine the one or more of the first security class and the second security class based on vendor rights when the installation information indicates the one or more of the sending application (108) and the receiving application (112) originating from an untrusted source.

7. The apparatus (100) of any of the preceding claims, wherein the processor (152) is configured to change the one or more of the first security class and the second security class to a more trusted security class if the authority for the inter-process message (128) has not been denied for a predetermined amount of time or if a predetermined amount of inter-process messages has been sent between the sending application (108) and the receiving application (112).

8. The apparatus (100) of any of the preceding claims, wherein each security category is associated with one or more messaging policies, and wherein the processor (152) is configured to dynamically modify the one or more messaging policies.

9. The apparatus (100) of any one of the preceding claims, wherein the one or more of the sending application and the receiving application are members of a group of highly protected applications, and wherein the processor (152) is configured to associate a highly protected security category with the group of protected applications, wherein the group of protected applications is defined by one or more of: a provider of the application, a provider right, and a user input.

10. The apparatus (100) of any of the preceding claims, wherein the processor (152) is configured to record the permission and associated inter-process message information in a messaging history (140), and wherein the processor (152) is configured to modify the one or more of the first security category and the second security category based on the messaging history.

11. The apparatus (100) of any of the preceding claims, wherein the processor (152) is configured to associate the sending application with a first one or more security classes, to associate the receiving application with a second one or more security classes, and to determine the authority of the inter-process message (128) based on the first one or more security classes and the second one or more security classes.

12. The device (100) according to any one of the preceding claims, wherein the first security category is the same as the second security category.

13. A method (300), comprising:

associating (302) the sending application with a first security class and;

associating (304) the receiving application with a second security category;

receiving (306) an inter-process message from the sending application in a message router, wherein the inter-process message comprises an indication of the sending application and the receiving application;

determining (308) permissions for the inter-process message based on the first security category and the second security category; and

forwarding (412) the inter-process message to the receiving application upon granting the right; and blocking (416) the inter-process message when the right is denied.

14. The method (300) of claim 13, comprising determining one or more of the first security class and the second security class based on information related to one or more of the sending application and the receiving application, wherein the information related to the one or more of the sending application and the receiving application comprises one or more of: virus scans, data obtained from social certification services, input from the user of the device, installation information, vendor rights, application specific security requirements, and machine learning applications.

15. A non-transitory computer readable medium having stored thereon program instructions, which when executed by a processor (152) are for causing the processor (102) to perform the method of any one of claims 13 or 14.