Patent Description:
The operating systems of computing devices typically provide various mechanisms for data communication between applications or processes executing on the devices. These mechanisms may be referred to as inter-process communication (IPC) mechanisms, for example, or other related terms. Some forms of IPC mechanisms also facilitate the division of processing requirements among the processes.

In some cases, applications that rely upon IPC mechanisms can be categorized as clients or servers. Under that construct, a client can be an application or a process that requests a service from some other application or process. A server, on the other hand, is an application or a process that responds to a client request. Applications can act as both clients and servers, depending on the situation. <CIT> discloses inter-process communications between a first process and a second process. A first process recognizes that inter-process communications must be initiated with a second process. A first computer that supports the first process submits a request to initiate inter-process communications with a second computer that supports the second process. The second computer replies to a request to initiate inter-process communications by replying to the first computer with a request for information of a digital certificate that authenticates the first process. <CIT> discloses a first executable program on a computer system that is enabled to exchange communications with a second executable program on the computer system by determining that the first executable program requests to exchange information with the second executable program. <CIT> discloses methods, devices and systems for inter-app communications between software applications on a mobile communications device. <CIT> discloses systems and methods for bestowing trust from a first application to a second application on a single device. A first application has an established trust with an external service provider and a certificate registered with the service provider.

With the growing number of different mobile computing devices, platforms, and operating systems available for adoption, a number of challenges arise in the management of large numbers of mobile devices for many users. One challenge is the need to achieve secure communications between two different computing devices. Some mobile device management (MDM) platforms provide features that help to achieve secure communications between different computing devices and, in some cases, between two different applications or processes executing on the same computing device. Thus, the use of MDM platforms can help to achieve secure IPC mechanisms.

Many aspects of the present disclosure can be better understood with reference to the following drawings. The components in the drawings are not necessarily drawn to scale, with emphasis instead being placed upon clearly illustrating the principles of the disclosure. In the drawings, like reference numerals designate corresponding parts throughout the several views.

As noted above, some MDM platforms provide features that help to achieve secure communications between different computing devices and, in some cases, between two different applications or processes executing on the same computing device. However, MDM platforms cannot be relied upon to achieve secure inter-application communications in all cases and between all applications. It would be beneficial to offer other solutions for secure inter-application communication processes among two or more applications executing on the same computing device, particularly on an unmanaged computing device.

On certain computing devices, keychain or keystore services can be relied upon to provide a mechanism for applications to store data in an encrypted database called a keychain. The keychain can be relied upon to store sensitive data, such as passwords, credit card information, cryptographic keys, cryptographic certificates, and other types of sensitive data. However, keychain services are also not tailored or designed to provide secure inter-application communication processes on managed or unmanaged devices.

In the context outlined above, the embodiments described herein provide a mechanism for secure inter-application communications between a number of different processes or applications executing on the same computing device. In one example, an application executing on a computing device generates an asymmetric key pair and obtains an identity certificate from a certificate authority based on the key pair. The identity certificate can include a unique identifier of the computing device upon which the application is executing, along with a public key of the first application. Other applications executing on the same computing device can also generate asymmetric key pairs and obtain identity certificates, each including the same unique identifier for the computing device, based on the key pairs.

The applications executing on the computing device can then exchange their public keys with each other to facilitate secure inter-application communications between each other. To exchange their public keys with each other, each of the applications can query a management computing environment using its identity certificate for authentication. The unique identifier in the identity certificates can be relied upon by the management computing environment to identify the computing device upon which the applications are executing. The unique identifier can also be relied upon to uniquely identify the computing device and distinguish it from other computing devices. Once the management computing environment authenticates the applications, the management computing environment can then store the public keys from the identity certificates of the applications in a mapping table or memory area specific to the computing device upon which the applications are executing.

For each application that queries the management computing environment, the management computing environment can also return any public keys of other applications stored in the mapping table. Each application can maintain a local copy of the public keys of the other applications in a local key store memory area. Once the public keys have been exchanged between the applications, the applications can encrypt and sign data packages for secure data communications between each other as described in further detail below.

Turning to the drawings, the following paragraphs provide an outline of a networked environment followed by a discussion of the operation of the same. <FIG> illustrates an example networked environment for secure inter-application data sharing according to various examples described herein. The networked environment <NUM> includes a computing environment <NUM>, a network <NUM>, a client device <NUM>, and a certificate authority <NUM>. The networked environment <NUM> is provided as a representative example for purposes of discussion. The networked environment <NUM> can include other networked components not illustrated in <FIG>.

The computing environment <NUM> can be embodied as one or more computers, computing devices, or computing systems. In certain embodiments, the computing environment <NUM> can include one or more computing devices arranged, for example, in one or more server or computer banks. The computing device or devices can be located at a single installation site or distributed among different geographical locations. The computing environment <NUM> can include a plurality of computing devices that together embody a hosted computing resource, a grid computing resource, or other distributed computing arrangement. In some cases, the computing environment <NUM> can be embodied as an elastic computing resource where an allotted capacity of processing, network, storage, or other computing-related resources varies over time. As further described below, the computing environment <NUM> can also be embodied, in part, as certain functional or logical (e.g., computer-readable instruction) elements or modules as described herein.

The computing environment <NUM> can function as a type of management service for the client device <NUM>, among other devices. In that context, the computing environment <NUM> includes a data store <NUM> and a management service <NUM>. The data store <NUM> includes areas in memory for the storage of device data <NUM> and mapping tables <NUM>, among other types of data. The management service <NUM> includes a device authenticator <NUM> and a key exchanger <NUM>, among other components.

The management service <NUM> can enroll the client device <NUM>, among others, for device management services (e.g., MDM services), although it is not necessary for the management service <NUM> to enroll the client device <NUM> for management services to achieve the benefits of secure inter-application communications as described herein. That is, the concepts of secure inter-application communications described herein can be achieved on client devices that are not managed by a management service (i.e., "unmanaged devices").

The certificate authority <NUM> can be embodied as one or more computers, computing devices, or computing systems similar to the computing environment <NUM> but directed to a different function or purpose. The certificate authority <NUM> can operate as a certificate authority for the computing environment <NUM>, the client device <NUM>, and other computing devices on the network <NUM>. In that context, the certificate authority <NUM> is configured to issue identity certificates, digital certificates, and other certificates that can be relied upon to authenticate the identity of one or more devices in the networked environment <NUM>. An identity or digital certificate can be relied upon to certify or authenticate the ownership of a public key. In that sense, the certificate authority <NUM> can operate as a trusted third party between the computing environment <NUM>, client device <NUM>, and the applications <NUM> and <NUM> executing on the client device <NUM>. The identity or digital certificates generated by the certificate authority <NUM> can take any suitable format, such as that defined by the X. <NUM> standard, among others.

The certificate authority <NUM> can also maintain data related to the revocation status of public keys and certificates. A public key or certificate can be irreversibly revoked, for example, if the certificate authority certificate authority <NUM> had improperly issued a certificate or a private key has been compromised or stolen. Public keys or certificates can also be revoked for a failure of the owner to adhere to certain security policies or requirements, such as the publication of false data, misrepresentations, or violations of other policies specified by the certificate authority <NUM>.

The network <NUM> can include the Internet, intranets, extranets, wide area networks (WANs), local area networks (LANs), wired networks, wireless networks, cable networks, satellite networks, other suitable networks, or any combinations thereof. As one example, the computing environment <NUM>, the client device <NUM>, and the certificate authority <NUM> can be respectively coupled to one or more public or private LANs or WANs and, in turn, to the Internet for communication of data among each other. Although not shown in <FIG>, the network <NUM> can also include network connections to any number and type of network hosts or devices, such as website servers, file servers, cloud computing resources, databases, data stores, or any other network or computing architectures.

In the networked environment <NUM>, the computing environment <NUM>, the client device <NUM>, and the certificate authority <NUM> can communicate data among each other using one or more network transfer protocols or interconnect frameworks, such as hypertext transfer protocol (HTTP), simple object access protocol (SOAP), representational state transfer (REST), real-time transport protocol (RTP), real time streaming protocol (RTSP), real time messaging protocol (RTMP), user datagram protocol (UDP), internet protocol (IP), transmission control protocol (TCP), other protocols and interconnect frameworks, and combinations thereof.

The client device <NUM> is representative of one or more client devices. The client device <NUM> can be embodied as any computing device, processing circuit, or processor based device or system, including those in the form of a desktop computer, a laptop computer, a tablet computer, a personal digital assistant, a cellular telephone, a wearable computing device, or a set-top box, among other example computing devices and systems. Depending upon its primary purpose or function, for example, the client device <NUM> can include various peripheral devices or components. The peripheral devices can include input or communications devices or modules, such as keyboards, keypads, touch pads, touch screens, microphones, cameras, wireless communications modules (e.g., infra-red, WI-FI, or BLUETOOTH®), buttons, switches, or sensors. The peripheral devices can also include a display, indicator lights, speakers, global positioning system (GPS) circuitry, accelerometers, gyroscopes, or other peripheral devices depending upon the primary purpose or function of the client device <NUM>.

As illustrated in <FIG>, the client device <NUM> includes a data store <NUM>, having areas for the storage of application data <NUM> and device data <NUM>, among other types of data. The client device <NUM> also includes the applications <NUM> and <NUM>, which are installed and configured for execution on the client device <NUM>. As described in further detail below, the applications <NUM> and <NUM> (among others) can securely communicate encrypted data packages between each other using inter-application communication processes.

The application data <NUM> can include data related to any applications associated with the client device <NUM>, such as the executable code of the applications <NUM> and <NUM>, among others, installed on the client device, user data associated with the applications <NUM> and <NUM>, and other related data. The device data <NUM> can include various types of data associated with the client device <NUM>, including a unique identifier of the client device <NUM>. The unique identifier can be generated by an operating system of the client device <NUM>, generated by one of the applications <NUM> or <NUM>, or provided to the client device <NUM> by the management service <NUM> or some other computing device or environment.

The applications <NUM> and <NUM> are representative of any applications, application extensions, or other application-related components that can be executed on the client device <NUM>. The client device <NUM> can also execute a number of other applications in addition to the applications <NUM> and <NUM>. The applications <NUM> and <NUM> can include hypertext-based network browsers, such as the Internet Explorer®, Firefox®, Chrome®, Safari®, or Silk® browsers, among other types of browsers. Alternatively, the applications <NUM> and <NUM> can be embodied as other types of applications, such as an e-mail clients, messaging clients, document editors or viewers, file browsers, or other applications or application extensions for other purposes.

The application <NUM> includes a key pair generator <NUM>, a key operator <NUM>, and a key store <NUM>. Similarly, the application <NUM> includes a key pair generator <NUM>, a key operator <NUM>, and a key store <NUM>. The key pair generator <NUM> is configured to generate one or more asymmetric public and private key pairs. The key operator <NUM> can use one or more of the key pairs to perform various cryptographic operations, including operations to facilitate secure inter-application communications between the applications <NUM> and <NUM>, among others, as described herein.

Key pairs generated by the key pair generator <NUM> can be stored in the key store <NUM>. The key store <NUM> can be embodied as a local memory area in the client device <NUM> reserved for use only by the application <NUM>. The key store <NUM> can be used to store sensitive data, such as passwords, credit card information, cryptographic keys, cryptographic certificates, and other types of sensitive data. In one example, the key store <NUM> can be a sandboxed or private area of the data store <NUM>. The key store <NUM> can be reserved by the operating system of the client device <NUM> for use only by the application <NUM>. The key store <NUM> can also be embodied as a keychain managed for the application <NUM> by the operating system of the client device <NUM>. In addition to storing key pairs generated by the key pair generator <NUM>, the key store <NUM> can also store public keys generated by other applications, such as the application <NUM>, among others executing on the client device <NUM>. The key store <NUM> of the application <NUM> is similar to the key store <NUM> of the application <NUM>, and the key store <NUM> can be used to securely store data for use by the application <NUM>.

As noted above, the key operator <NUM> is configured to perform a number of cryptographic operations using the key pairs generated by the key pair generator <NUM>. The cryptographic operations can include encryption, decryption, verification, signature, and other operations. The key operator <NUM> is also configured to obtain one or more public key, identity, or digital certificates for the application <NUM> based on communications with the certificate authority <NUM>. Such certificates can be based on the X. <NUM> standard or other related standards or protocols. An example identity certificate obtained from the certificate authority <NUM> can include both the public key of the key pair generated by the key operator <NUM> and a unique identifier for the client device <NUM>. The key operator <NUM> of the application <NUM> is configured to perform operations similar to those performed by the key operator <NUM>. Thus, the key operator <NUM> is configured to obtain one or more public key, identity, or digital certificates for the application <NUM> based on communications with the certificate authority <NUM> and the key pair generated for the application <NUM> by the key pair generator <NUM>.

Another function of the key operator <NUM> is to encrypt and decrypt data for secure communications between other applications executing on the client device <NUM>. In that context, the key operator <NUM> is configured to encrypt and decrypt data using the key pair generated by the key pair generator <NUM>. Similarly, the key operator <NUM> is configured to encrypt and decrypt data using the key pair generated by the key pair generator <NUM>.

The key operator <NUM> is not limited to performing cryptographic operations with the key pair generated by the key pair generator <NUM>, however. Instead, the key operator <NUM> can also perform cryptographic operations using the public keys of other applications executing on the client device <NUM>, including the application <NUM>. The key operator <NUM> can also perform cryptographic operations using the public keys of other applications executing on the client device <NUM>, including the application <NUM>. Thus, the key operator <NUM> of the application <NUM> and the key operator <NUM> of the application <NUM> are also configured to encrypt and decrypt data using the public keys of other applications executing on the client device <NUM>. As one example, the key operator <NUM> can encrypt data for communication to the application <NUM> using the public key of the application <NUM>. The encrypted data can then be securely communicated to the application <NUM>, and the key operator <NUM> of the application <NUM> can then decrypt the encrypted data using the private key of the application <NUM>.

However, before the key operator <NUM> can conduct cryptographic operations using the public keys of other applications executing on the client device <NUM> (e.g., the public key of the application <NUM>, among other public keys), it is necessary for the application <NUM> to obtain copies of the public keys of those other applications. It is also necessary for the application <NUM> to obtain copies of the public keys of the other applications executing on the client device <NUM>. To that end, the management service <NUM> of the computing environment <NUM> operates as a type of application authenticator, public key repository, and public key exchanger for the applications executing on the client device <NUM>. According to an example described herein, the applications <NUM> and <NUM> are able to conduct secure inter-application communications between each other, in part, by sharing and exchanging their public keys through the management service <NUM> on the computing environment <NUM>.

For the application <NUM> to obtain the public keys of the other applications executing on the client device <NUM>, the key operator <NUM> is configured to query the management service <NUM> to authenticate itself. The key operator <NUM> can forward the identity certificate for the application <NUM> as part of the query. As noted above, the identity certificate of the application <NUM> includes the public key of the application <NUM> as well as a unique identifier of the client device <NUM>. Using the identity certificate of the application <NUM> and information stored in the device data <NUM>, the device authenticator <NUM> of the management service <NUM> can authenticate the application <NUM> in connection with a digital certificate contained in the identity certificate. The authentication can be conducted based on communications with the certificate authority <NUM> in some cases. The device authenticator <NUM> can also uniquely identify the client device <NUM> upon which the application <NUM> is executing with reference to the unique identifier of the client device <NUM> and information stored in the device data <NUM>.

Once the application <NUM> is authenticated by the device authenticator <NUM>, the management service <NUM> can create and store data in a record for the application <NUM> in one of the mapping tables <NUM> for the client device <NUM>. For example, the table 124A can be specifically reserved by the management service <NUM> for the client device <NUM> based on the unique identifier for the client device <NUM> received in the identity certificate from the application <NUM>. Thus, the management service <NUM> can store a record for the application <NUM> in the table 124A. The record can include a number of data elements associated with the application <NUM>, including the identity certificate, the public key, or both the identity certificate and the public key of the application <NUM>, among other data elements. In a similar way, the management service <NUM> can use the table 124A to store other records for other applications executing on the client device <NUM>. The mapping tables <NUM> can also include other tables for client devices other than the client device <NUM>.

The key operator <NUM> of the application <NUM> is similar to the key operator <NUM> of the application <NUM> and can be relied upon by the application <NUM> to perform operations similar to those performed by the key operator <NUM>. Thus, the key operator <NUM> can obtain public key, identity, or digital certificates for the application <NUM> from the certificate authority <NUM> based on the key pair generated by the key pair generator <NUM>. The key operator <NUM> can also authenticate itself with the management service <NUM> though a query to the management service <NUM> using an identity certificate including the unique identifier of the client device <NUM> and the public key of the application <NUM>. The key operator <NUM> can also share the public key of the application <NUM> with the management service <NUM>, and the management service <NUM> can store the public key of the application <NUM> in the table 124A. As each application executing on the client device <NUM> (e.g., the applications <NUM> and <NUM>, among others) authenticates itself with the device authenticator <NUM>, the management service <NUM> can store all the public keys of the applications in the table 124A.

When the key operator <NUM> of the application <NUM> checks in and authenticates itself with the management service <NUM>, it can also query the management service <NUM> for the public keys of other applications executing on the client device <NUM>. In turn, the key exchanger <NUM> can access the table 124A, retrieve copies of the public keys stored in the table 124A for all the other applications executing on the client device <NUM>, and return the copies of the public keys to the key operator <NUM> of the application <NUM>. The key operator <NUM> can then store the public keys of the other applications in the key store <NUM>. In that way, the key operator <NUM> can obtain copies of the public keys of the application <NUM>, among others that are executing on the client device <NUM>, from the computing environment <NUM>. The key operator <NUM> of the application <NUM> can also obtain copies of the public keys of the application <NUM>, among others, from the computing environment <NUM> in a similar way.

After the application <NUM> has a copy of the public key of the application <NUM> and the application <NUM> has a copy of the public key of the application <NUM>, the applications <NUM> and <NUM> can encrypt data packages to send to each other. The applications <NUM> and <NUM> can also communicate the encrypted data packages to each other through any suitable inter-application communication process available on the client device <NUM>. The manner in which the applications <NUM> and <NUM> can securely communicate with each other is described in further detail below with reference to the process flow diagrams of <FIG>.

<FIG> illustrates example data elements stored in the local key store <NUM> of the application <NUM>. The local key store <NUM> can store other data elements in addition to those shown in <FIG>. In other cases, the local key store <NUM> can omit (i.e., not store) one or more of the data elements shown in <FIG>. The local key store <NUM> can include data elements similar to those shown in <FIG> for the local key store <NUM>. Additionally, each of the mapping tables <NUM>, including the mapping table 124A, can include data elements similar to those shown in <FIG>.

For the application <NUM>, the local key store <NUM> includes the public key 200A and the private key 201A. Together, the public key 200A and the private key 201A form the asymmetric key pair generated by the key pair generator <NUM>. The local key store <NUM> also includes the identity certificate 202A of the application <NUM>. As described above, the identity certificate 202A can be provided by the certificate authority <NUM> and, among other data, include the public key 200A and a unique identifier of the client device <NUM>.

The local key store <NUM> can also include public keys of other applications executing on the client device <NUM>. These public keys can be obtained from the management service <NUM> of the computing device, as described herein. In the example shown in <FIG>, the local key store <NUM> also includes the public keys 200B-200N. The public key 200B can be the public key of the application <NUM>, for example, and the public keys 200C-200N can be the public keys of other applications executing on the client device <NUM>. In another embodiment, the local key store <NUM> can store the identity certificates of the application <NUM> and other applications executing on the client device <NUM>. Thus, in addition or as an alternative to the public keys 200C-200N, the local key store <NUM> can store the identity certificates of the other applications executing on the client device <NUM>.

The local key store <NUM> also includes the revocation status data 210B-210N. The revocation status data 210B is associated with the public key 200B, the revocation status data 210C is associated with the public key 200C, and so on. The revocation status data 210B can be relied upon by the key operator <NUM> to determine whether or not the public key 200B of the application <NUM> is valid for use or has been revoked for use. Thus, the revocation status data 210B defines the revocation status of the public key 200B. The manner in which the application <NUM> obtains and uses the revocation status data 210B-210N is described in further detail below.

Turning to a detailed description of the operations of the components described in <FIG>, <FIG> illustrate a process for secure inter-application data sharing according to various examples described herein. The process is described in connection with the applications <NUM> and <NUM> of the client device <NUM> and the management service <NUM> shown in <FIG>, although other applications and services can perform the process. Although the process diagrams show an order of operation or execution, the order can differ from that which is shown. For example, the order of execution of two or more process steps can be switched relative to the order shown or as described below. Also, two or more process steps shown in succession can be executed concurrently or with partial concurrence. Further, in some examples, one or more of the process steps shown in the process diagrams can be skipped or omitted.

At step <NUM>, the process can include the key pair generator <NUM> generating an asymmetric key pair for the application <NUM>. Any suitable type or length of key pair can be generated by the key pair generator <NUM>. As an example, key pairs can be randomly generated using a random number generator (RING) or pseudorandom number generator (PRNG). Using the key pair, the key pair generator <NUM> can conduct cryptographic operations using one or more cryptosystems, such as the Diffie-Hellman, Rivest-Shamir-Adleman (RSA), and digital signature algorithm (DSA) cryptosystems, among others.

At step <NUM>, the process can include the key operator <NUM> obtaining an identity certificate for the application <NUM> from the certificate authority <NUM>. To do so, the key operator <NUM> can submit a certification or signing request to the certificate authority <NUM> over the network <NUM>. As one example, the certification request can include the public key portion of the key pair generated at step <NUM>, a signature algorithm identifier, and a digital signature of the application <NUM>. The digital signature of the application <NUM> can be generated using the private key portion of the key pair generated at step <NUM>. In some cases, the certification request can also include a unique identifier of the client device <NUM>. In response to the signing request from the key operator <NUM>, the certificate authority <NUM> can return an identity certificate back to the key operator <NUM> at step <NUM>. The identity certificate issued by the certificate authority <NUM> certifies the ownership of the public key of the application <NUM>. Among other data fields in the identity certificate, it can also include a copy of the identifier of the client device <NUM>. Alternatively, the key operator <NUM> can add the identifier of the client device <NUM> to the identity certificate as a new field after the identity certificate is received from the certificate authority <NUM>.

At step <NUM>, the process can include the key operator <NUM> querying the management service <NUM> on the computing environment <NUM> to authenticate the application <NUM> with the management service <NUM>. To do so, the key operator <NUM> can communicate the identity certificate received from the certificate authority <NUM> at step <NUM> to the management service <NUM>.

At step <NUM>, the device authenticator <NUM> can authenticate the application <NUM> based on the identity certificate received in the query from the key operator <NUM> at step <NUM>. The device authenticator <NUM> can authenticate the application <NUM> in connection with the public key contained in the identity certificate. The authentication can be conducted based on communications with the certificate authority <NUM> in some cases. The device authenticator <NUM> can also uniquely identify the client device <NUM> at step <NUM> with reference to the unique identifier in the identity certificate and, in some cases, information stored in the device data <NUM>.

At step <NUM>, the process can include the key exchanger <NUM> storing the public key for the application <NUM>, which was received in the query from the key operator <NUM> at step <NUM>, into the data store <NUM>. For example, the key exchanger <NUM> can store the identity certificate received at step <NUM>, which includes the public key for the application <NUM>, in the table 124A of the data store <NUM>. As noted above, the table 124A can be specifically reserved by the management service <NUM> to store the identity certificates of the applications executing on the client device <NUM>. The applications executing on the client device <NUM> can be distinguished from those executing on other client devices based on the unique identifier for the client device <NUM> received in the identity certificate at step <NUM>.

At step <NUM>, the process can include the key exchanger <NUM> forwarding the public keys stored in the table 124A back to the key operator <NUM> of the application <NUM>. Here, the key exchanger <NUM> can review the data records stored in the table 124A to find any identity certificates, including public keys, of applications other the application <NUM> that are known to be executing on the client device <NUM>. Depending upon the order in which applications are installed on the client device <NUM> (and the order in which the management service <NUM> authenticates and creates records for them), the number of records stored in the table 124A may vary. In any case, the key exchanger <NUM> is directed at step <NUM> to find the records of all the applications executing on the client device <NUM> and to communicate them to back to the application <NUM>. From the data contained in the records, the key exchanger <NUM> can forward back the identity certificates, the public keys, or both the identity certificates and the public keys of the applications executing on the client device <NUM>, among other relevant data.

At step <NUM>, the process can include the key operator <NUM> of the application <NUM> obtaining the data records forwarded from the key exchanger <NUM> at step <NUM>. Thus, in response to the key operator <NUM> querying the management service <NUM> at step <NUM>, the key operator <NUM> can receive the identity certificates and public keys of other applications executing on the client device <NUM> from the key exchanger <NUM>. In that way, the application <NUM> can obtain copies of the public keys of the other applications executing on the client device <NUM>. The key operator <NUM> can also request the identity certificates of other applications executing on the client device <NUM> from the management service <NUM> at any other time.

At step <NUM>, the process can include the key operator <NUM> storing data from the records received at step <NUM> in the key store <NUM>. The data can include the identity certificates and public keys of other applications executing on the client device <NUM>. At this point, the key store <NUM> can include a number of records for the applications executing on the client device <NUM>, similar to those shown in <FIG>.

At step <NUM>, the process can include the key operator <NUM> confirming a revocation status of the identity certificates and the public keys stored in the key store <NUM>. Identity certificates issued by the certificate authority <NUM> for the applications executing on the client device <NUM> are typically valid until their validity times have been reached. From the time of validity, each identity certificate is valid until its expiration date. Certain circumstances may cause a certificate to become invalid before the expiration of the validity period, such as a change of association with the certificate authority <NUM>, suspected compromise of a private key, or other reasons. In those cases, the certificate authority <NUM> may revoke identity certificates, including those issued to the applications <NUM> and <NUM>, among others executing on the client device <NUM>.

Thus, at step <NUM>, the key operator <NUM> confirms whether the identity certificates obtained at step <NUM> are still valid or use, before using the public keys contained within them to perform cryptographic operations. The key operator <NUM> can confirm the revocation status of the public keys stored in the key store <NUM> through a certificate status protocol communication with the certificate authority <NUM>. The key operator <NUM> can confirm the revocation status of each of the public keys individually or confirm the status of multiple public keys through reference to a certificate revocation list (CRL) stored by the certificate authority <NUM>.

At step <NUM>, the process can include the key operator <NUM> caching or storing, in the key store <NUM>, the revocation status information obtained at step <NUM>. The revocation status information for each record or public key can be stored in the key store <NUM>, similar to the way the revocation status data 210B-210N shown in <FIG> is stored individually for the public keys 200C-200N. The revocation status for each public key can be based on a time to live (TTL) parameter received through the certificate status protocol communication at step <NUM>.

After step <NUM>, the application <NUM> has obtained the public keys of the other applications executing on the client device <NUM> and is ready to conduct secure inter-application data communications with them. The other applications executing on the client device <NUM>, such as the application <NUM>, also need to obtain the copies of the public keys. Thus, turning to <FIG>, the application <NUM> performs a number of steps similar to those performed by the application <NUM> in <FIG>.

At step <NUM>, the process can include the key pair generator <NUM> generating an asymmetric key pair for the application <NUM>. Any suitable type or length of key pair can be generated by the key pair generator <NUM>. Using the key pair, the key pair generator <NUM> can conduct cryptographic operations using one or more cryptosystems, such as the Diffie-Hellman, RSA, and DSA cryptosystems, among others.

At step <NUM>, the process can include the key operator <NUM> obtaining an identity certificate for the application <NUM> from the certificate authority <NUM>. To do so, the key operator <NUM> can submit a certification or signing request to the certificate authority <NUM> over the network <NUM>. As one example, the certification request can include the public key portion of the key pair generated at step <NUM>, a signature algorithm identifier, and a digital signature of the application <NUM>. The digital signature of the application <NUM> can be generated using the private key portion of the key pair generated at step <NUM>. In some cases, the certification request can also include a unique identifier of the client device <NUM>. In response to the signing request from the key operator <NUM>, the certificate authority <NUM> can return an identity certificate back to the key operator <NUM> at step <NUM>. The identity certificate issued by the certificate authority <NUM> certifies the ownership of the public key of the application <NUM>. Among other data fields, the identity certificate can include a copy of the identifier of the client device <NUM>. Alternatively, the key operator <NUM> can add the identifier of the client device <NUM> to the identity certificate as a new field after the identity certificate is received from the certificate authority <NUM>.

At step <NUM>, the process can include the key operator <NUM> querying the management service <NUM> on the computing environment <NUM> to authenticate the application <NUM> with the management service <NUM>. To do so, the key operator <NUM> can communicate, to the management service <NUM>, the identity certificate received from the certificate authority <NUM> at step <NUM>.

At step <NUM>, the device authenticator <NUM> can authenticate the application <NUM> based on the identity certificate received in the query from the key operator <NUM> at step <NUM>. The device authenticator <NUM> can authenticate the application <NUM> in connection with a digital signature contained in the identity certificate. The authentication can be conducted based on communications with the certificate authority <NUM> in some cases. The device authenticator <NUM> can also uniquely identify the client device <NUM> at step <NUM> with reference to the unique identifier in the identity certificate and, in some cases, information stored in the device data <NUM>.

At step <NUM>, the process can include the key exchanger <NUM> storing the public key for the application <NUM>, which was received in the query from the key operator <NUM> at step <NUM>, into the data store <NUM>. For example, the key exchanger <NUM> can store the identity certificate received at step <NUM>, which includes the public key for the application <NUM>, in the table 124A of the data store <NUM>.

At step <NUM>, the process can include the key exchanger <NUM> forwarding the public keys stored in the table 124A back to the key operator <NUM> of the application <NUM>. Here, the key exchanger <NUM> can review the data records stored in the table 124A to find any identity certificates of applications other the application <NUM> that are known to be executing on the client device <NUM>, including public keys. The key exchanger <NUM> is directed at step <NUM> to find the records of all the applications executing on the client device <NUM>, such as the application <NUM>, and to communicate such records to back to the application <NUM>. The key exchanger <NUM> can communicate back one or more of the identity certificates or the public keys of the applications executing on the client device <NUM>, among other relevant data.

At step <NUM>, the process can include the key operator <NUM> of the application <NUM> obtaining the data records forwarded from the key exchanger <NUM> at step <NUM>. Thus, in response to the key operator <NUM> querying the management service <NUM> at step <NUM>, the key operator <NUM> can receive the identity certificates and public keys of other applications executing on the client device <NUM> from the key exchanger <NUM>. In that way, the application <NUM> can also obtain copies of the public keys of the other applications executing on the client device <NUM>, similar to the way the application <NUM> did so. The key operator <NUM> can also request the identity certificates of other applications executing on the client device <NUM> from the management service <NUM> at any other time.

At step <NUM>, the process can include the key operator <NUM> confirming a revocation status of the identity certificates and the public keys stored in the key store <NUM>. The key operator <NUM> can confirm the revocation status of the public keys stored in the key store <NUM> through a certificate status protocol communication with the certificate authority <NUM>. The key operator <NUM> can confirm the revocation status of each of the public keys individually or confirm the status of multiple public keys through reference to a certificate revocation list (CRL) stored by the certificate authority <NUM>.

At step <NUM>, the process can include the key operator <NUM> caching or storing, in the key store <NUM>, the revocation status information obtained at step <NUM>. The revocation status information can be stored for each record or public key in the key store <NUM>, similar to the way the revocation status data 210B-210N shown in <FIG> is stored individually for the public keys 200C-200N. The revocation status for each public key can be based on a TTL parameter received through the certificate status protocol communication at step <NUM>. The TTL parameter, which may be defined according to a relative or absolute time period, a specified future date, a specified future date and time, or other timeframe, can define the valid lifespan for each record or public key in the key store <NUM>. After step <NUM>, the applications <NUM> and <NUM> have exchanged their identity certificates and public keys. The applications <NUM> and <NUM> are now capable of conducting secure inter-application data communications with each other according to the steps shown in <FIG>.

At step <NUM> in <FIG>, the process includes the key operator <NUM> of the application <NUM> signing the data to be communicated to the application <NUM>. The key operator <NUM> can conduct the signing operation using the private key of the application <NUM>, and the signing operation can generate a signature of the application <NUM>. The signature can be used by the application <NUM> to authenticate data communications from the application <NUM>. As an example, the key operator <NUM> can sign a hash of the data to be communicated to the application <NUM> with the private key of the application <NUM>. Alternatively, the key operator <NUM> can directly sign the data to be communicated to the application <NUM> with the private key of the application <NUM>.

At step <NUM>, the process includes the key operator <NUM> encrypting the data to be communicated to the application <NUM> using the public key of the application <NUM>. This encrypting process generates encrypted data for transfer to the application <NUM> as part of an encrypted data package. The encrypted data package can also include the signature generated at step <NUM>.

At step <NUM>, the process includes the application <NUM> communicating the encrypted data package generated at steps <NUM> and <NUM> to the application <NUM> through an inter-application communication process. Any type of inter-application or inter-process communication (IPC) supported by the operating system of the client device <NUM> can be relied upon to communicate the encrypted data package at step <NUM>. Example methods can include memory-based file transfers, socket transfers, message queue transfers, and pipe transfers, among other techniques.

At step <NUM>, the process can include the application <NUM> decrypting the encrypted data package received from the application <NUM> at step <NUM>. Particularly, because the data was encrypted by the application <NUM> using the public key of the application <NUM> at step <NUM>, the key operator <NUM> of the application <NUM> can now decrypt the encrypted data package using its private key.

At step <NUM>, the process can include the application <NUM> verifying the signature contained within the encrypted data package received at step <NUM>. As one example, the key operator <NUM> can decrypt the signature in the encrypted data package using the public key of the application <NUM>, which was obtained from the management service <NUM> (e.g., at step <NUM> in <FIG>). The decrypted signature can be compared to a hash of the data decrypted at step <NUM> (or the data itself) to confirm that the encrypted data package transferred at step <NUM> was sent from the application <NUM>. Finally, at step <NUM>, the application <NUM> can process the data received from the application <NUM>.

The application <NUM> can also receive encrypted data packages from the application <NUM>. As shown at step <NUM>, the process includes the key operator <NUM> of the application <NUM> signing data to be communicated to the application <NUM>. The key operator <NUM> can conduct the signing operation using the private key of the application <NUM>, and the signing operation can generate a signature of the application <NUM>. The signature can be used by the application <NUM> to authenticate data communications from the application <NUM>. As an example, the key operator <NUM> can sign a hash of the data to be communicated to the application <NUM> with the private key of the application <NUM>. Alternatively, the key operator <NUM> can directly sign the data to be communicated to the application <NUM> with the private key of the application <NUM>.

At step <NUM>, the process includes the application <NUM> communicating the encrypted data package generated at steps <NUM> and <NUM> to the application <NUM> through any type of inter-application or inter-process communication process supported by the operating system of the client device <NUM>. Example methods can include memory-based file transfers, socket transfers, message queue transfers, and pipe transfers, among other techniques.

At step <NUM>, the process can include the application <NUM>) decrypting the encrypted data package received from the application <NUM> at step <NUM>. Particularly, because the data was encrypted by the application <NUM> using the public key of the application <NUM> at step <NUM>, the key operator <NUM> of the application <NUM> can now decrypt the encrypted data package using its private key.

At step <NUM>, the process can include the application <NUM> verifying the signature contained within the encrypted data package received at step <NUM>. As one example, the key operator <NUM> can decrypt the signature in the encrypted data package using the public key of the application <NUM>, which was obtained from the management service <NUM> (e.g., at step <NUM> in <FIG>). The decrypted signature can be compared to a hash of the data decrypted at step <NUM> (or the data itself) to confirm that the encrypted data package transferred at step <NUM> was sent from the application <NUM>.

Other applications executing on the client device <NUM> can securely communicate with each other and with the applications <NUM> and <NUM> according to the concepts outlined above. The embodiments provide a mechanism for secure inter-application communications between a number of different processes or applications executing on the same computing device.

The flowcharts in <FIG> show examples of the functions and operations of the components described herein. The components described herein can be embodied in hardware, software, or a combination of hardware and software. If embodied in software, each element can represent a module or group of code that includes program instructions to implement the specified logical function(s). The program instructions can be embodied in the form of, for example, source code that includes human-readable statements written in a programming language or machine code that includes machine instructions recognizable by a suitable execution system, such as a processor in a computer system or other system. If embodied in hardware, each element can represent a circuit or a number of interconnected circuits that implement the specified logical function(s).

The computing environment <NUM> can include at least one processing circuit. Such a processing circuit can include, for example, one or more processors and one or more storage or memory devices coupled to a local interface. The local interface can include, for example, a data bus with an accompanying address/control bus or any other suitable bus structure. Similarly, the client device <NUM> can include at least one processing circuit. Such a processing circuit can include, for example, one or more processors and one or more storage or memory devices coupled to a local interface.

The storage or memory devices can store data or components that are executable by the processors of the processing circuit. For example, the management service <NUM> and/or other components can be stored in one or more storage devices and be executable by one or more processors in the computing environment <NUM>. Similarly, the applications <NUM> and <NUM> and/or other components can be stored in one or more storage devices and be executable by one or more processors in the client device <NUM>.

The management service <NUM>, application <NUM>, application <NUM>, and/or other components described herein can be embodied in the form of hardware, as software components that are executable by hardware, or as a combination of software and hardware. If embodied as hardware, the components described herein can be implemented as a circuit or state machine that employs any suitable hardware technology. The hardware technology can include, for example, one or more microprocessors, discrete logic circuits having logic gates for implementing various logic functions upon an application of one or more data signals, application specific integrated circuits (ASICs) having appropriate logic gates, programmable logic devices (e.g., field-programmable gate array (FPGAs), and complex programmable logic devices (CPLDs).

Also, one or more or more of the components described herein that include software or program instructions can be embodied in any non-transitory computer-readable medium for use by or in connection with an instruction execution system such as, a processor in a computer system or other system. The computer-readable medium can contain, store, and/or maintain the software or program instructions for use by or in connection with the instruction execution system.

A computer-readable medium can include a physical media, such as, magnetic, optical, semiconductor, and/or other suitable media. Examples of a suitable computer-readable media include, but are not limited to, solid-state drives, magnetic drives, or flash memory. Further, any logic or component described herein can be implemented and structured in a variety of ways. For example, one or more components described can be implemented as modules or components of a single application. Further, one or more components described herein can be executed in one computing device or by using multiple computing devices.

Further, any logic or applications described herein, including the management service <NUM>, application <NUM>, application <NUM>, and/or other components can be implemented and structured in a variety of ways. For example, one or more applications described can be implemented as modules or components of a single application. Further, one or more applications described herein can be executed in shared or separate computing devices or a combination thereof. For example, a plurality of the applications described herein can execute in the same computing device, or in multiple computing devices. Additionally, terms such as "application," "service," "system," "engine," "module," and so on can be used interchangeably and are not intended to be limiting.

Claim 1:
A method for secure data sharing between applications, the applications being executed by a computing device (<NUM>), the method comprising:
obtaining, by a first application (<NUM>) executed by the computing device (<NUM>), an identity certificate associated with the first application (<NUM>), wherein the identity certificate comprises: a unique identifier associated with the computing device (<NUM>), and a public key associated with the first application (<NUM>);
authenticating the first application (<NUM>) with a management computing environment (<NUM>), over a network (<NUM>), using the identity certificate associated with the first application (<NUM>);
distinguishing, by the management computing environment (<NUM>), a plurality of other applications executing on the computing device (<NUM>) from those executing on other computing devices based on the unique identifier received in the identity certificate;
obtaining a plurality of public keys by the first application (<NUM>) from the management computing environment (<NUM>) in response to the authenticating the first application (<NUM>) with the management computing environment (<NUM>), the plurality of public keys being associated with the plurality of other applications executing on the computing device (<NUM>);
causing, by the first application (<NUM>), the plurality of public keys to be stored in a key store (<NUM>) of the computing device (<NUM>);
causing, by the first application (<NUM>), an encrypted data package to be generated using a public key associated with a second application (<NUM>) among the plurality of other applications; and
causing, by the first application (<NUM>), the encrypted data package to be communicated to the second application (<NUM>) through an inter-application communication process.