Patent Description:
<CIT> discloses a method in which a portable device processor generates an application-level certificate for an application installed on the portable device. A request to authenticate the application may be forwarded to a controller.

<CIT> discloses providing an instance of a business process management suite in a sandbox of a web browser. The instance of the business process management suite is based on an archive received from a web server.

<CIT> discloses a secure device enrollment process to enroll a mobile device for access to a service which includes receiving an application package including an application used for accessing the service via the mobile device.

Though web applications can offer great accessibility and other benefits to users and developers, under certain circumstances, deploying an application as a web application may cause certain operational difficulties. For example, by running a web application inside a web browser, the web application typically does not have access to system level services on a computing device because a security boundary or "sandbox" in the web browser isolates the web application from a host operating system of the computing device. Examples of such system level services can include various configuration services (e.g., changing a machine name) or other suitable types of services offered by the host operating system on the computing device.

One solution for the foregoing difficulty is to deploy a web application along with a dedicated web server as a packaged application on the computing device. Such a configuration is sometimes referred to as a "same box" configuration. In operation, the web server can be granted system level access and serves requests for system level services from the web application. The foregoing solution, however, creates risks of potential security breaches from other web applications because the web server not only can serve requests from the co-packaged web application but can also serve requests from other un-authorized web applications running on the same computing device. As such, another web application not having system level access may gain system level access by requesting the web server to perform certain operations. Such operations can circumvent security settings on the computing device.

Several embodiments of the disclosed technology can address certain aspects of the foregoing challenge by implementing automatic generation of app-specific client certification in the packaged application. In one implementation, during installation, modification of access permission, or launch of the packaged application, the web server can be configured to automatically generate a server certificate and a client certificate. The server and client certificates can individually include data representing a private key, a public key, a signature, a subject (e.g., the web server) bound to the foregoing components, or other suitable security data. The web server can then store the generated server and client certificates at a private memory location allocated by, for example, the host operating system to the packaged application. The private memory location is accessible only by the web server and the corresponding web client.

Upon completion of creating and storing the server and client certificates, the web server can be configured to activate the web client by, for example, launching the web client in a web browser. During activation, the web server can be configured to pass, for instance, as arguments in a function call or other suitable types of activation instruction, a digital signature (or "thumb print") or a public key of the web server or an identification of the web server as a trusted certificate authority to the web client. Upon receiving the activation instruction and/or during launching the web client in the web browser, the web client can retrieve, from the private memory location, a copy of the client certificate created by the web server.

Using the automatically generated server/client certificates, the web server and the co-packaged web client can authenticate each other to reduce or prevent a risk of unauthorized web applications from accessing the web server on the computing device. In certain embodiments, the packaged application can implement a Transport Layer Security (TLS) or Secure Sockets Layer (SSL) handshake between the web server and the web client. For instance, the web client can transmit a connection request to the web server along with an identification or other suitable parameters of the web client. In response, the web server can transmit a copy of the server certificate (e.g., containing a public key of the web server) self-signed by the web server. In one implementation, the web client can authenticate the web server by comparing the server certificate with that received as an argument during activation. In another implementation, the web client can identify the web server as a trusted certificate authority and use the public key of the web server to authenticate the server certificate. In further implementations, the web client can authenticate the web server in other suitable ways.

The web client can also transmit a copy of the client certificate to the web server for authentication. Upon receiving the client certificate, the web server can use the copy of client certificate stored in the private memory location to authenticate and verify the web client in a manner generally similar to those described above with respect to authenticating the web server. Once authenticated, the web server can allow the requested connection based on which the web client can access various system level services via the web server. In other embodiments, the packaged application can also implement <NUM>-way, <NUM>-way, or other suitable types of handshake protocols for establishing the connection between the web server and the web client in the packaged application.

Several embodiments of the disclosed technology can thus reduce or prevent risks of an unauthorized web client from accessing the web server in the packaged application. When an unauthorized web client requests a connection with the web server, the unauthorized web client would not have access to the private memory location allocated to the packaged application. As such, the unauthorized web client could not provide any or a correct client certificate to the web server for authentication. As a result, the web server in the packaged application would refuse the connection request and thus prevent the unauthorized web client from access any system level services via the web server.

Certain embodiments of systems, devices, components, modules, routines, data structures, and processes for automatic generation of app-specific client certificate are described below. In the following description, specific details of components are included to provide a thorough understanding of certain embodiments of the disclosed technology. A person skilled in the relevant art will also understand that the technology can have additional embodiments. The technology can also be practiced without several of the details of the embodiments described below with reference to <FIG>.

As used herein, a "host computing device" or "host" generally refers to a computing device configured to support execution of one or more applications or computer programs. In certain embodiments, the host can include a host operating system configured to support execution of applications or computer programs. In other embodiments, the host can also support implementation of, for instance, one or more virtual machines (VMs), containers, or other suitable virtualized components. For example, a host can include a server having a hypervisor configured to support one or more virtual machines, containers, or other suitable types of virtual components. The one or more virtual machines or containers can be used to launch and execute suitable applications or computer programs to provide corresponding computing services.

Also used herein, a "host operating system" generally refers to an operating system deployed to interact directly with hardware components of a computer device (e.g., a server) and can grant or deny system level access to services provided by the host operating system. In certain implementations, a hypervisor (e.g., a hosted hypervisor) can run on top of a host operating system rather than interacting directly with the hardware components of the computing device. The hypervisor can then create, manage, or otherwise support one or more VMs or containers each having a "guest operating system" or "guest" separated from the host operating system by a security boundary. In certain implementations, a guest operating system may not be the same as a host operating system supporting the guest operating system.

Further used herein, a "virtual memory" generally refers to abstracted storage resources available on a computing device. A host operating system, using a combination of hardware and software, can map memory addresses used by a virtual machine or container ("virtual addresses") into physical addresses in a memory and/or storage (e.g., a hard drive) on the computing device. A virtual memory, as seen by a virtual machine or container, may appear as a contiguous address space or collection of contiguous segments. The host operating system can manage and facilitate operations of virtual address spaces and corresponding assignment of underlying physical memory to the virtual memory. Once assigned, a virtual machine, container, or application may use the assigned virtual memory as if the virtual memory were a physical memory suitable for executing instructions of applications.

Furthermore, a "memory location" as used herein generally refers to a block, segment, page, or other suitable divisions of memory identifiable to software and hardware in a computing device by a memory address or memory address range. In certain implementations, memory addresses can include fixed-length sequences of digits (e.g., in hexadecimal) displayed and manipulated as unsigned integers. For instance, an example memory location can be at an example memory address of "FBFF FFFF. " In other implementations, memory addresses can include other suitable types of identifiers.

Also used herein, "asymmetric cryptography" generally refers to a cryptographic technique that uses pairs of public and private keys. Public keys may be shared with other components in the host while private keys are accessible only to a designated component such as a web server or web client in a packaged application. As described in more detail later, private/public keys can be used to authenticate the web server and the web client to each other, thereby preventing an unauthorized web application from accessing the web server. Examples of public and private keys can include a string of <NUM>-, <NUM>-, <NUM>-, or other suitable numbers of bits. Though embodiments of the technique described herein use asymmetric cryptography as an example authentication technique, in other embodiments, the packaged application can also implement symmetric cryptography in which both the web server and the web client can have the same cryptography key.

Further used herein, a "packaged application" generally refers to an application that contains a web server and a corresponding web client configured to cooperate with the web server for achieving certain designed functions. In an outward appearance, a packaged application appears to be a single executable entity. In certain embodiments, the web server can be assigned a port (e.g., port <NUM>) on a network interface card (NIC) of the host. The co-packaged web client can then, upon establishment of a connection, access the web server via the assigned port of the web server in a loop-back fashion. In other embodiments, the web client can access the web server in other suitable fashions.

Deploying a web server and a web client in a packaged application in a "same box" configuration can create potential risks of unauthorized access to system level services on a host. For example, the web server can be granted system level access and serves requests for system level services from the web application. However, other un-authorized web applications running on the same computing device may also access the web server to serve unauthorized service requests. As such, other unauthorized web applications not having system level access may gain system level access via the web server to circumvent security settings on the computing device.

Several embodiments of the disclosed technology can address certain aspects of the foregoing challenge by implementing automatic generation of app-specific client certification in the packaged application. During installation, modification of access permission, or launch of the packaged application, the web server can be configured to automatically generate a server certificate and a client certificate. The web server can then store the generated server and client certificates at a private memory location allocated by, for example, the host operating system to the packaged application. The private memory location is accessible only by the web server and the corresponding web client.

Upon completion of creating and storing the server and client certificates, the web server can be configured to activate the web client by, for example, launching the web client in a web browser. During activation, the web server can be configured to pass, for instance, as arguments in a function call or other suitable types of activation instruction, a digital signature (or "thumb print") or a public key of the web server or an identification of the web server as a trusted certificate authority to the web client. Upon receiving the activation instruction and/or during launching the web client in the web browser, the web client can retrieve, from the private memory location, a copy of the client certificate created by the web server. Using the automatically generated server and client certificates, the web server and the co-packaged web client can authenticate each other to reduce or prevent a risk of unauthorized web applications from accessing the web server on the computing device, as described in more detail below with reference to <FIG>.

<FIG> is a schematic diagram illustrating a host <NUM> supporting a packaged application <NUM> configured to automatically generate an app-specific client certification in accordance with embodiments of the disclosed technology. The host <NUM> can be a server, a desktop or laptop computer, a smart phone, or other suitable types of computing device. Though only particular components of the host <NUM> are shown in <FIG>, in other embodiments, the host <NUM> can include additional and/or different hardware and/or software components, such as those example components described below with reference to <FIG>.

In <FIG> and in other Figures herein, individual software components, objects, classes, modules, and routines may be a computer program, procedure, or process written as source code in C, C++, C#, Java, and/or other suitable programming languages. A component may include, without limitation, one or more modules, objects, classes, routines, properties, processes, threads, executables, libraries, or other components. Components may be in source or binary form. Components may include aspects of source code before compilation (e.g., classes, properties, procedures, routines), compiled binary units (e.g., libraries, executables), or artifacts instantiated and used at runtime (e.g., objects, processes, threads).

Components within a system may take different forms within the system. As one example, a system comprising a first component, a second component and a third component can, without limitation, encompass a system that has the first component being a property in source code, the second component being a binary compiled library, and the third component being a thread created at runtime. The computer program, procedure, or process may be compiled into object, intermediate, or machine code and presented for execution by one or more processors of a personal computer, a network server, a laptop computer, a smartphone, and/or other suitable computing devices.

Equally, components may include hardware circuitry. A person of ordinary skill in the art would recognize that hardware may be considered fossilized software, and software may be considered liquefied hardware. As just one example, software instructions in a component may be burned to a Programmable Logic Array circuit, or may be designed as a hardware circuit with appropriate integrated circuits. Equally, hardware may be emulated by software. Various implementations of source, intermediate, and/or object code and associated data may be stored in a computer memory that includes read-only memory, random-access memory, magnetic disk storage media, optical storage media, flash memory devices, and/or other suitable computer readable storage media excluding propagated signals.

As shown in <FIG>, the host <NUM> can include a host operating system <NUM> configured to support installation and execution of the packaged application <NUM>. Even though the packaged application <NUM> is shown in <FIG> as directly installed or executed on top of the host operating system <NUM>, in other embodiments, the packaged application <NUM> can also be installed or executed in a virtual machine, container, or other suitable virtual components supported by the host operating system <NUM>. In <FIG>, the operations of automatic generation of app-specific client certification are described in the context of installation for illustration purposes. In other embodiments, the operations can also be performed in response to modification of access permission or launch of the packaged application <NUM> in the host <NUM>.

Also shown in <FIG>, the packaged application <NUM> can include a web server <NUM>, a web client <NUM>, and a private memory <NUM> that is a block of virtual memory allocated to the packaged application <NUM> by, for example, the host operating system <NUM>. In certain implementations, the web server <NUM> and the web client <NUM> can both be operating inside a security boundary or "sandbox" defined by the host operating system <NUM>. The web server <NUM> can be granted certain permissions for access to system level services provided by the host operating system <NUM> while the web client <NUM> does not have direct access to such system level services.

In certain embodiments, the web server <NUM> can include a standalone software program configured to serve contents in response to incoming requests according to Hypertext Transfer Protocol (HTTP) protocol or other suitable types of network protocols. In other embodiments, the web server <NUM> can also include an extension to a local web server (not shown) on the host <NUM>. As shown in <FIG>, in accordance with embodiments of the disclosed technology, the web server <NUM> can include a certificate component <NUM>, a handshake component <NUM>, and a service component <NUM> operatively coupled to one another. Though particular components of the web server <NUM> are shown in <FIG>, in other embodiments, the web server <NUM> can also include an interface component or other suitable types of component.

As shown in <FIG>, upon receiving an installation request <NUM> from a user <NUM>, the host operating system <NUM> can, for instance, download the packaged application <NUM> via a computer network (e.g., the Internet), and store/install the downloaded packaged application <NUM> in the host operating system <NUM>. Upon being installed, the certificate component <NUM> of the web server <NUM> can be configured to automatically generate a server certificate 110a and a client certificate 110b.

As used herein, a server/client certificate 110a and 110b generally refers to a data package representing a digital certificate or identity certificate to prove ownership of an identity. In certain embodiments, the server and client certificates 110a and 110b can individually include data representing a private key, a public key, a digital signature, a subject (e.g., the web server <NUM> or the web client <NUM>) bound to the foregoing components, or other suitable security data. In other embodiments, the server and client certificates 110a and 110b can also include designation of trusted certificate authorities and corresponding network addresses. In further embodiments, the server and client certificates 110a and 110b can also include one or more of an identification of the installed instance of the packaged application <NUM>, an identification of the installed web server <NUM>, or an identification of an extension of the installed web server <NUM>, or other suitable information.

The certificate component <NUM> of the web server <NUM> can then be configured to store the generated server and client certificates 110a and 110b at the private memory <NUM>. In certain implementations, the certificate component <NUM> can store the server and client certificates 110a and 110b at certain reserved or designated memory locations in the private memory <NUM>. In other implementations, the certificate component <NUM> can store the server and client certificates 110a and 110b at random memory locations in the private memory <NUM>. In any of the foregoing embodiments, the memory locations holding the server and client certificates 110a and 110b in the private memory location are accessible only by the web server <NUM> and the web client <NUM>.

As shown in <FIG>, upon completion of creating and storing the server and client certificates 110a and 110b, the web server <NUM> can be configured to activate the web client <NUM> by, for example, launching the web client <NUM> in a web browser (not shown) via transmitting an activation instruction <NUM>. In certain embodiments, the activation instruction <NUM> can be a function call (e.g., an application programming interface, or API call), and the web server <NUM> can be configured to pass, for instance, as arguments in the function call, a digital signature (or "thumb print") or a public key of the web server <NUM> or an identification of the web server <NUM> as a trusted certificate authority to the web client <NUM>. In other embodiments, the activation instruction <NUM> can include other suitable types of activation instruction.

The web client <NUM> can include a software program configured to request content or services from the web server <NUM> according to, for example, the HTTP protocol. As shown in <FIG>, the web client <NUM> can include an activation component <NUM>, a connection component <NUM>, and a request component <NUM> operatively coupled to one another. Though particular components of the web client <NUM> are shown in <FIG>, in other embodiments, the web client <NUM> can also include a network component, a display component, or other suitable types of component.

As shown in <FIG>, upon receiving the activation instruction <NUM> and/or during launching the web client <NUM> in the web browser, the activation component <NUM> of the web client <NUM> can be configured to retrieve, from the private memory <NUM>, a copy of the client certificate 110b created by the web server <NUM>. In one embodiment, the activation component <NUM> can retrieve the client certificate 110b from a designated memory location in the private memory <NUM>. In other embodiments, the activation instruction <NUM> can include parameters indicating to the activation component <NUM> the memory location(s) at which the client certificate 110b is stored in the private memory <NUM>. Based on the parameters in the activation instruction <NUM>, the activation component <NUM> can then retrieve a copy of the client certificate 110b. In further embodiments, the activation component <NUM> can be configured to query the private memory <NUM> for the client certificate 110b or perform other suitable operations to retrieve a copy of the client certificate 110b. Additional components of the web server <NUM> and the web client <NUM> are described in more detail below with reference to <FIG>.

<FIG> are schematic diagrams of certain hardware/software components of the host <NUM> of <FIG> and <FIG> during stages of operation to establish a connection between the web server <NUM> and the web client <NUM> in the packaged application <NUM> in accordance with embodiments of the disclosed technology. Using the automatically generated server/client certificates 110a and 110b, the web server <NUM> and the co-packaged web client <NUM> can authenticate each other to reduce or prevent a risk of an unauthorized web application <NUM>' (shown in <FIG>) from accessing the web server <NUM> on the host <NUM>.

In certain embodiments, the packaged application <NUM> can implement a handshake protocol to authenticate the web server <NUM> and the web client <NUM> to each other. In the following description, Transport Layer Security (TLS) or Secure Sockets Layer (SSL) handshake between the web server <NUM> and the web client <NUM> were used as example handshake protocols. In other embodiments, the packaged application <NUM> can also implement <NUM>-way, <NUM>-way, or other suitable types of handshake protocols for establishing the connection between the web server and the web client in the packaged application <NUM>.

As shown in <FIG>, the connection component <NUM> of the web client <NUM> can be configured to transmit a connection request <NUM>, for instance, via a port assigned to the web server in the host <NUM>, to the web server <NUM> along with an identification or other suitable parameters of the web client <NUM>. As shown in <FIG>, in response to receiving the connection request <NUM>, the handshake component <NUM> of the web server can transmit a copy of the server certificate 110a (e.g., containing a public key of the web server <NUM>) self-signed by the web server <NUM>.

The connection component <NUM> can then be configured to perform certificate pinning based on the received server certificate 110a to authenticate the web server <NUM>. In one implementation, the connection component <NUM> can authenticate the web server <NUM> by comparing the received copy of the server certificate 110a with that received as an argument during activation. In another implementation, the connection component <NUM> can identify the web server <NUM> as a trusted certificate authority and use the public key of the web server <NUM> to authenticate a digital signature included in the received server certificate 110a. In further implementations, the connection component <NUM> can also be configured to authenticate the web server in other suitable ways. Upon authentication, the web client <NUM> verifies the identify of the web server <NUM>, and transmits a copy of the client certificate 110b to the web server <NUM>, as shown in <FIG>.

As shown in <FIG>, the handshake component <NUM> can then be configured to authenticate the web client <NUM> by performing certificate pinning based on the received copy of the client certificate 110b and another copy of the client certificate 110b' retrieved from the private memory <NUM>. Implementations of such certificate pinning can be generally similar to those described above with respect to authenticating the web server <NUM> based on the server certificate 110a.

Once authenticated, the handshake component <NUM> of the web server <NUM> can allow the requested connection <NUM> based on which the web client <NUM> can access various system level services via the web server <NUM>. Using the connection <NUM>, the web client <NUM> can request and receive content and/or service from the web server <NUM>. For example, as shown in <FIG>, the request component <NUM> of the web client <NUM> can be configured to transmit service requests <NUM> to the web server <NUM>. In response, the service component <NUM> can be configured to perform suitable system level services and provide, to the web client <NUM>, corresponding service data <NUM> according to, for instance, the HTTP protocol, NT LAN Manager® protocol, or other suitable types of protocol.

Several embodiments of the disclosed technology described above with reference to <FIG> can reduce or prevent risks of an unauthorized web client <NUM>' from accessing the web server <NUM> in the packaged application <NUM>, as shown in <FIG>. As shown in <FIG>, the unauthorized web client <NUM>' is not part of the packaged application <NUM>. As such, the unauthorized web client <NUM>' does not have access to the private memory <NUM>. When the unauthorized web client <NUM>' requests a connection with the web server <NUM>, the unauthorized web client could transmit a connection request <NUM>' to the web server <NUM>, for instance, via the port assigned to the web server <NUM> on the host <NUM>. However, the unauthorized web client <NUM>' could not provide any or a correct client certificate 110b (shown in phantom lines for clarity) to the web server <NUM> for authentication. As a result, the web server <NUM> in the packaged application <NUM> would refuse the connection request <NUM>' and thus prevent the unauthorized web client <NUM>' from access any system level services via the web server <NUM>. In certain embodiments, the handshake component <NUM> can be configured to transmit a connection refusal message (not shown) to the unauthorized web client <NUM>'. In other embodiments, the handshake component <NUM> can be configured to simply ignore the connection request <NUM>' without sending any response.

<FIG> are flowcharts illustrating certain processes of memory assignment for guest operating systems in accordance with embodiments of the disclosed technology. Even though embodiments of the processes are described below in the context of the host <NUM> and the packaged application <NUM> in <FIG>, in other embodiments, the processes can also be performed in hosts, computing devices, or computing systems with additional and/or different hardware/software components.

As shown in <FIG>, a process <NUM> can include receiving a request for installing, modifying permission, or launching a packaged application at stage <NUM>. The request can be received at, for example, an installation, permission modification, or execution of a service provided by a host operating system of a host computing device. The process <NUM> can then include generating a server certificate and a client certificate at a web server of the packaged application at stage <NUM>. The generated server and client certificates can then be stored in a private memory accessible only to components of the packaged application. In certain embodiments, the server and client certificates can be regenerated each time the packaged application is installed, permission modified, or launched. In other embodiments, the generated server and client certificates can have corresponding time-to-live values expiration of which can cause the server and client certificates be regenerated. In further embodiments, the server and client certificates can be regenerated periodically, based on suitable events, or in other suitable manners.

The process <NUM> can then include activating a web client of the packaged application by the web server at stage <NUM>. In certain embodiments, activation of the web client can include a function call with parameters indicating to the web client that the web server is to be trusted (e.g., by indicating that the web server is a trusted certificate authority). In other embodiments, the parameters can also pass a signature of the web server or other suitable information, as described above with reference to <FIG>. Example operations performed by the web client during activation are described below in more detail with reference to <FIG>.

As shown in <FIG>, example operations for activating the web client can include receiving an activation instruction from the web server at stage <NUM>. The operations can then include deploying a web browser to instantiate the web client at stage <NUM>. In one implementation, the deployed web browser can be a single page web browser with a single control (or script) corresponding to the web client. In other implementations, the deployed web client can have other suitable configurations. The operations can then include retrieving, by the web client (e.g., by executing a script) to retrieve a copy of the client certificate generated by the web server from the private memory of the packaged application at stage <NUM>, as described above with reference to <FIG>.

<FIG> is a flowchart illustrating a process <NUM> of performing a handshake between a web server and a web client both being a part of a packaged application. As shown in <FIG>, the process <NUM> can include receiving a client certificate by the web server from the web client at stage <NUM>. The process <NUM> can then include performing certificate pinning at the web server to authenticate the web client is indeed the co-packaged web client based on the received client certificate and a client certificate previously generated by the web server for the web client at stage <NUM>. Example operations for performing such certificate pinning are described above with reference to <FIG>.

The process <NUM> can then include a decision stage <NUM> to determine whether authentication based on the received client certificate is successful. In one example, a digital signature in the received client certificate can be compared to another digital signature in the private memory. Then, the operations can include determining whether the digital signatures match each other, and in response to determining that the digital signatures match each other, the operations can include indicating that authentication is successful; otherwise, the operations can include indicating that authentication has failed. In another example, a certificate authority that signed the received copy of the client certificate can be determined. The operations can then include determining whether the certificate authority is web server itself. In response to determining that the certificate authority is web server itself, the operations can include indicating that authentication is successful; otherwise the operations can include indicating that authentication has failed.

In response to determining that authentication based on the received client certificate is successful, the process <NUM> can include allowing a secured connection with the web client at stage <NUM>. In response to determining that authentication based on the received client certificate is not successful, the process <NUM> can include denying the connection at stage <NUM>.

<FIG> is a computing device <NUM> suitable for the host <NUM> in <FIG>. In a very basic configuration <NUM>, the computing device <NUM> can include one or more processors <NUM> and a system memory <NUM>. A memory bus <NUM> can be used for communicating between processor <NUM> and system memory <NUM>.

Depending on the desired configuration, the processor <NUM> can be of any type including but not limited to a microprocessor (µP), a microcontroller (µC), a digital signal processor (DSP), or any combination thereof. The processor <NUM> can include one more levels of caching, such as a level-one cache <NUM> and a level-two cache <NUM>, a processor core <NUM>, and registers <NUM>. An example processor core <NUM> can include an arithmetic logic unit (ALU), a floating point unit (FPU), a digital signal processing core (DSP Core), or any combination thereof. An example memory controller <NUM> can also be used with processor <NUM>, or in some implementations memory controller <NUM> can be an internal part of processor <NUM>.

Depending on the desired configuration, the system memory <NUM> can be of any type including but not limited to volatile memory (such as RAM), non-volatile memory (such as ROM, flash memory, etc.) or any combination thereof. The system memory <NUM> can include an operating system <NUM>, one or more applications <NUM>, and program data <NUM>. This described basic configuration <NUM> is illustrated in Figure <NUM> by those components within the inner dashed line.

The computing device <NUM> can have additional features or functionality, and additional interfaces to facilitate communications between basic configuration <NUM> and any other devices and interfaces. For example, a bus/interface controller <NUM> can be used to facilitate communications between the basic configuration <NUM> and one or more data storage devices <NUM> via a storage interface bus <NUM>. The data storage devices <NUM> can be removable storage devices <NUM>, non-removable storage devices <NUM>, or a combination thereof. Examples of removable storage and non-removable storage devices include magnetic disk devices such as flexible disk drives and hard-disk drives (HDD), optical disk drives such as compact disk (CD) drives or digital versatile disk (DVD) drives, solid state drives (SSD), and tape drives to name a few. Example computer storage media can include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. The term "computer readable storage media" or "computer readable storage device" excludes propagated signals and communication media.

The system memory <NUM>, removable storage devices <NUM>, and non-removable storage devices <NUM> are examples of computer readable storage media. Computer readable storage media include, but not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other media which can be used to store the desired information and which can be accessed by computing device <NUM>. Any such computer readable storage media can be a part of computing device <NUM>. The term "computer readable storage medium" excludes propagated signals and communication media.

The computing device <NUM> can also include an interface bus <NUM> for facilitating communication from various interface devices (e.g., output devices <NUM>, peripheral interfaces <NUM>, and communication devices <NUM>) to the basic configuration <NUM> via bus/interface controller <NUM>. Example output devices <NUM> include a graphics processing unit <NUM> and an audio processing unit <NUM>, which can be configured to communicate to various external devices such as a display or speakers via one or more A/V ports <NUM>. Example peripheral interfaces <NUM> include a serial interface controller <NUM> or a parallel interface controller <NUM>, which can be configured to communicate with external devices such as input devices (e.g., keyboard, mouse, pen, voice input device, touch input device, etc.) or other peripheral devices (e.g., printer, scanner, etc.) via one or more I/O ports <NUM>. An example communication device <NUM> includes a network controller <NUM>, which can be arranged to facilitate communications with one or more other computing devices <NUM> over a network communication link via one or more communication ports <NUM>.

The network communication link can be one example of a communication media. Communication media can typically be embodied by computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and can include any information delivery media. A "modulated data signal" can be a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media can include wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, radio frequency (RF), microwave, infrared (IR) and other wireless media. The term computer readable media as used herein can include both storage media and communication media.

The computing device <NUM> can be implemented as a portion of a small-form factor portable (or mobile) electronic device such as a cell phone, a personal data assistant (PDA), a personal media player device, a wireless web-watch device, a personal headset device, an application specific device, or a hybrid device that include any of the above functions. The computing device <NUM> can also be implemented as a personal computer including both laptop computer and non-laptop computer configurations.

Claim 1:
A method of automatic generation of app-specific client certification on a host computing device (<NUM>) having a host operating system (<NUM>), the method comprising:
receiving a request to install, modify a permission of, or launch a packaged application (<NUM>) in the host operating system (<NUM>), the packaged application (<NUM>) containing both a web server (<NUM>) and a corresponding web client (<NUM>); and
in response to receiving the request:
automatically generating, with the web server (<NUM>), data representing a server certificate (110a) and a client certificate (110b) for the web client (<NUM>);
storing the generated server and client certificates (110a, 110b) in a private memory (<NUM>) allocated by the host operating system (<NUM>) to the packaged application (<NUM>), the private memory (<NUM>) being accessible only by the web server (<NUM>) and the web client (<NUM>);
upon completion of generating the server and client certificates (110a, 110b), activating, by the web server (<NUM>), the web client (<NUM>) in the packaged application (<NUM>); and
during activation of the web client (<NUM>), retrieving, by the web client (<NUM>), a copy of the stored client certificate (110b) from the private memory (<NUM>), and authenticating the web client (<NUM>) to the web server (<NUM>) with the retrieved copy of the stored client certificate (110b) and authenticating the web server (<NUM>) to the web client (<NUM>) using a copy of the stored server certificate (110a) to reduce a risk of unauthorized access to the web server (<NUM>) by another web client (<NUM>') executing on the host computing device (<NUM>).