System and method for centralized key distribution

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Application Ser. No. 61/876,121, filed on 10 Sep. 2013 which is incorporated in its entirety by this reference.

TECHNICAL FIELD

This invention relates generally to the cryptographic key field, and more specifically to a new and useful system and method for centralized key distribution in the cryptographic key field.

BACKGROUND

In dealing with cryptographic keys, many systems rely on a private/public key pair system. Uses of key pairs have numerous applications, one of them being authentication of an account. When the destination of the public key is known or is easily copyable, the key can be transferred to the destination. But there are many cases where the verifying party (i.e., the one who needs the public key) is unknown or unavailable at the time of key generation. One common scenario is where the key pair is generated on a mobile device; transferring a public key can be cumbersome and possibly insecure depending on the approach. Thus, there is a need in the cryptographic key field to create a new and useful system and method for centralized key distribution. This invention provides such a new and useful system and method.

BRIEF DESCRIPTION OF THE FIGURES

<figref idref="DRAWINGS">FIG. 1</figref> is a schematic representation of a system of a preferred embodiment;

<figref idref="DRAWINGS">FIG. 2</figref> is a schematic representation of an exemplary implementation of the client application;

<figref idref="DRAWINGS">FIG. 3</figref> is a communication flowchart of a method of a first preferred embodiment;

<figref idref="DRAWINGS">FIG. 4</figref> is a flowchart representation of an exemplary user flow of a first preferred embodiment;

<figref idref="DRAWINGS">FIG. 5</figref> is a communication flowchart of a method of a second preferred embodiment;

<figref idref="DRAWINGS">FIG. 6</figref> is a flowchart representation of an exemplary user flow of a second preferred embodiment;

<figref idref="DRAWINGS">FIG. 7</figref> is a communication flowchart of a variation of a method verifying key access conditions;

<figref idref="DRAWINGS">FIG. 8</figref> is a communication flowchart of a variation of a method applying a time-based expiration window;

<figref idref="DRAWINGS">FIG. 9</figref> is a communication flowchart of a variation of a method applying an access count limit; and

<figref idref="DRAWINGS">FIG. 10</figref> is a communication flowchart of a variation of a method communicating key event information to a destination.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

The following description of preferred embodiments of the invention is not intended to limit the invention to these preferred embodiments, but rather to enable any person skilled in the art to make and use this invention.

1. System for Cryptographic Key Distribution

As shown in <figref idref="DRAWINGS">FIG. 1</figref>, a system for cryptographic key distribution of a preferred embodiment includes a key master service <b>100</b> with a public key repository <b>120</b> and integrated with at least one client application <b>130</b> and an outside service <b>140</b>. The system is preferably used to enable a centralized activation service that function to provide asynchronous creation and distribution of cryptographic keys. In particular, the system is used for the distribution of key pairs between the client application <b>130</b> and the outside service <b>140</b>. The system can be architected and configured to enable user driven identity from the client application <b>130</b> as opposed to the user receiving identity information from an outside service <b>140</b> and then later establishing on a client application. The system is particularly applicable to situations where the client device is not pre-configured for a public key destination. In an exemplary scenario, a two-factor authentication platform may enable a client application <b>130</b> to be used as the second factor of authentication for a variety of outside systems, and the outside systems are not pre-configured in the application. The system can act as the mechanism to transfer a public key to one of these outside devices. Additionally, the system may provide security and policy around key distribution while simultaneously simplifying the user experience.

The system is configured for use during activation of an account on a client application <b>130</b>. Herein, a two-factor application is used as a preferred version of a client application <b>130</b> but the system may be used with any suitable system where a key is distributed between a client application <b>130</b> and a service. The system is preferably used during the activation portion of an account on a client device such as when creating a new account, adding a new device to the account, or updating an existing device and account. In one exemplary user flow, a user will decide to use the two-factor authentication with an outside service <b>140</b>. The user can create a new two-factor authentication account on the device, which will eventually be associated with an outside service <b>140</b>. The account on the device is instantiated independently of an account on the outside service <b>140</b>. An account instantiated independently is preferably defined as an account wherein an associated outside service <b>140</b> has no data linking or referencing the account instance on the device to an account on the outside service <b>140</b>. The account on the device is preferably synchronized and linked with an account on the outside service through the transfer of a key identifier. A key pair is generated for the account instance on the client application <b>130</b>. The public key is transmitted to a key master service no, and in response receives an identifier. The identifier is preferably in a format such that the identifier can be easily transferred to an outside service <b>140</b>. The identifier in one implementation is a code displayed to the user. The user then proceeds to login to an account or create an account on the target outside service <b>140</b>. For example, a user may access a control panel on a web application of the outside service where a second factor of authentication can be registered. An option is selected to configure two-factor authentication through the two-factor authentication platform, and the user supplies the identifier. In response to receiving the identifier, the outside service <b>140</b> fetches the public key associated with the identifier from the key master service no. With possession of the public key, the client application <b>130</b> and the outside entity <b>140</b> can use the key pair for encrypted communication with the key pair.

The key master service no of the preferred embodiment functions as a centralized key escrow service. The key master service <b>110</b> acts as a singular or cohesive entity that can be reliably used as a transfer channel for distributing key pairs. The key master service no adds an abstraction layer between a device and an outside service <b>140</b> such that client devices <b>130</b> and outside services <b>140</b> talk to the key master service no directly to obtain or transfer keys. The key master service <b>110</b> is preferably an internet accessible service operative on a server, a computer cluster, a distributed computing system, and/or any suitable computing environment. The key master service no includes an interface for client application <b>130</b><i>s </i>to activate key pairs, and the key master service no can include a similar or related interface for outside services <b>140</b> to obtain public keys. The interfaces can include an authentication process such that client application <b>130</b><i>s </i>and/or outside services <b>140</b> have to be authenticated.

The key master service <b>110</b> will often be used alongside a multi-tenant platform and can identify and optionally track the entities involved in key pair transfers. As a multi-tenant platform the key master service <b>110</b> can facilitate key pair distribution for a plurality of distinct client applications <b>130</b> and outside services <b>140</b>. The different client applications <b>130</b> and outside services <b>140</b> preferably include programmatic integration with the key master service no through one or more application programming interfaces (APIs). In one example, a client application <b>130</b> is developed and released that enables multiple outside services to be authenticated by the client application as a second factor of authentication. Various outside services can enable use of two-factor authentication using this universal 2FA app by integrating public key retrieval with the key master service no. Additionally, if an enterprise wanted to create a customized universal 2FA app for use by employees, then this client application could similarly be developed and remain compatible with the multi-tenant key master service no and the configured outside service <b>140</b>.

The key master service <b>110</b> can additionally include a policy engine that functions to regulate and apply policy to key distribution. In one variation, the public key pairs are only stored temporarily. The policy engine is preferably at least communicatively integrated with the public key repository <b>120</b>. The policy engine can be configured for application of various forms of policy. In one variation, the policy engine includes a time expiration monitor that deletes, removes, or otherwise prevents access to a public key after a time expiration window has expired for a particular public key. For example, a public key may only be valid for 24 hours after creation. In another variation, the policy engine is integrated with a key request engine (or at least the API service provided to outside services <b>140</b>. The policy can regulate access to a public key based on the access conditions. The policy engine can restrict the number of access attempts, authenticate access (with user provided credentials or outside service credentials), machine address restrictions, geographic meta data restrictions, time of day restrictions on access, and/or any suitable policy related to the conditions relating to key requests.

The key master service <b>110</b> can additionally include a communication sub-system that functions to establish event notification/communication. The event notification is preferably in response to activity with a key pair, and the destination of the communication is preferably the client application associated with the relevant key pair. For example, a client application may receive a push notification when an outside service successfully receives a public key corresponding to the private key of the device. The client application may alternatively receive notifications that a key has expired, that an access attempt was blocked, that an expired identifier was used, or that any suitable event occurred. Alternatively, the destination endpoint can be registered as an external server or other suitable destination. For example, notifications of key pair access activity associated with an account of the key master service <b>110</b> may be sent to an application service of the account holder so that server side updates can be made.

In an alternative embodiment, the key master service no can additionally generate key pairs and appropriately distribute the private key to a client application <b>130</b>. The key master service <b>110</b> preferably includes a public key repository <b>120</b>.

The public key repository <b>120</b> functions to store public keys of various devices/applications. The public key repository <b>120</b> can be a database of key records. A key record will include the public key and at least one identifier. The identifier is preferably a human transcribable code that can be used to uniquely reference the public key. It acts as a simplified identifier so that a user can provide it to an outside service <b>140</b>, and the outside service <b>140</b> can request the public key associated with the identifier. The identifier could alternatively be an audio or visual signal such as a QR code that facilitates manual transfer to the outside service <b>140</b>. The key record can additionally store other associated information. In one variation, additional authentication information such as a username and/or password information may be used. In another variation, a destination address of the client application <b>130</b>, device, or user can be stored. The destination address can be used to send information or notifications about events that occur with the associated key pair with the communication sub-system. For example, once a public key has been transferred, a push notification can be delivered to the destination address to inform a user of completed key transfer or completed activation.

The client application <b>130</b> functions as the system using the private key of the key pair. In many implementations, the client application <b>130</b> will use the private key to talk with an outside service <b>140</b>, and the outside service <b>140</b> uses a corresponding public key to decrypt the communication as is commonly used in asymmetric cryptography. The client application <b>130</b> can alternatively use a public key distribution model or any suitable key model wherein at least one token is shared from one party to a second party. The client application <b>130</b> is preferably operable on a user operated host device. The host device is preferably a mobile computing device such as a mobile phone, a tablet, a wearable computing device, but the host device can alternatively be a desktop computing device, a TV connected computing device, or any suitable computing device. The client application <b>130</b> may be designed for use with a wide variety of outside services <b>140</b>. More preferably, the client application <b>130</b> can be designed to enable registering for use with an outside entity ad hoc (i.e., without needing to have prior registration or communication with the outside entity). Additionally, from a usability perspective, the client application <b>130</b> can be designed with user-driven account activation. Rather than having an outside system create an account and configuring the account information on the device, the user can initiate account activation directly from the client application <b>130</b>. As one benefit of the system, user-driven activation can be achieved even before engaging an outside service <b>140</b>. Similarly, the user-driven activation can be achieved before communicating with a particular application. In one variation, an enterprise application may create an easy enrollment mode for new employees, wherein the enrollment mode generates a set of different key pair tokens for various services used by the enterprise. Then the new employee can easily be set up 2FA with the various services used by the employee. In some cases, the potential outside services <b>140</b> is not preconfigured in the client application <b>130</b>, and in other cases could not be pre-configured. Accordingly, the client application <b>130</b> may not have an address or have knowledge of an interface to deliver a public key when initiating account activation from the client application <b>130</b>. The client application <b>130</b> operates cooperatively with the key master service <b>110</b> to facilitate distributing the public keys to the appropriate destination.

In a preferred implementation, the client application <b>130</b> is a two-factor authentication application that is used to provide a second channel of authentication. The two-factor authentication application is used in connection with a cloud hosted two-factor authentication platform that enables outside services <b>140</b> to easily add at least a second factor of authentication with their authentication process. Developers preferably integrate with the two-factor authentication platform using appropriate SDKs and/or APIs. The client application <b>130</b>, however, can be distributed in a generic form such that outside services <b>140</b> using the two-factor authentication platform can have users use the two-factor authentication application to complete two-factor authentication. As shown in <figref idref="DRAWINGS">FIG. 2</figref>, a plurality of different accounts for one or more services can be setup within one client application <b>130</b>. When setting up two-factor authentication, the two-factor authentication application can allow a user to simply specify a new account to be added before accessing the outside service <b>140</b>. In response to creating a new account, an identifier will be presented through the client application <b>130</b>, and a user will transfer the identifier to the outside service <b>140</b>. Transparently, the outside service <b>140</b> will use the identifier to access a public key that corresponds with a private key associated with the newly created account.

As described, a plurality of outside services <b>140</b> can be involved in the activation process and act as the destination of the public key. The outside service <b>140</b> can be any system or service that may require a key of a key pair. In the two-factor authentication example above, the outside service <b>140</b> can be any service that includes an account system requiring user authentication. The outside service <b>140</b> can be a web platform, a computing device, an enterprise solution, or any suitable system. The outside service <b>140</b> can be network accessible over the internet, but may alternatively be operative within an internal intranet or local network. The outside service <b>140</b> has at least partial network communication access to the key master service no. The outside service <b>140</b> will preferably include a user interface through which a key identifier can be received during a user-initiated transfer. For example, an account settings page for a web platform may offer the option configure a device for two-factor authentication. As opposed offering some user flow that results in establishing communication with the client application <b>130</b> and transferring tokens directly, the device registration interface may be a simple text field in which the key identifier is provided. The key identifier may alternatively be provided through an audio recording or image capture. Additional information may additionally be captured during the registration processes such as user authentication credentials, user location information, and other information that may be used in enforcing policy by the key master service no. The outside service <b>140</b> then can communicate with the key master service <b>110</b> to request the key using at least the key identifier. If the request is successfully fulfilled, the key is transferred to the outside service <b>140</b> where it is ideally stored in association with the associated account. With the public key established in the outside service <b>140</b> the key pair can be used for cryptographic interactions with the client application <b>130</b>.

2. Method for Cryptographic Key Distribution

As shown in <figref idref="DRAWINGS">FIG. 3</figref>, a method S<b>100</b> for cryptographic key distribution of a first preferred embodiment includes creating a key pair at a first device S<b>110</b>, receiving a public key of the key pair at a key master service S<b>120</b>, storing the public key at the key master service indexed, at least in part, by a key identifier S<b>130</b>, transmitting the key identifier of the public key to the device S<b>140</b>, and receiving a request of the public key and responding with the public key S<b>150</b>. The method functions to enable a centralized activation scheme where the key master service can act as a temporary key escrow service. The method is primarily used with systems dependent on key pairs shared between a client device and an outside service. The method is particularly applicable to situations where the client device is not pre-configured for a public key destination—at the time of account creation on the device, there may be no known URL or endpoint of the desired outside service for the public key. In an exemplary scenario, a two-factor authentication application may be usable for a variety of outside systems, but the outside systems are not pre-configured in the application. The method can facilitate the transfer of a public key to one of these outside devices.

The method is preferably used during activation of an account on a client application. Herein, a two-factor application is used as a preferred version of a client application and use of the method, but the method may be applied to any suitable system where a key pair used during activation needs to be distributed between a client application and a service. The method is preferably employed during the activation portion of an account on a client device such as when creating a new account, adding a new device to the account, or updating an existing device and account.

As shown in <figref idref="DRAWINGS">FIG. 4</figref> for one exemplary user flow, a user will decide to use the two-factor authentication with an outside service. The user can create a new two-factor authentication account on personal device, which will eventually be associated with the outside service. The account on the device is instantiated independently of an account on the outside service. A key pair is generated for the account instance on the client application. The public key is transmitted to a key master service, and in response the client application receives an identifier. The identifier is preferably in a format such that the identifier can be easily transferred to an outside service. The identifier in one implementation is a code displayed to the user. The user then proceeds to login to an account or create an account on the target outside service. An option is selected to configure two-factor authentication through the two-factor authentication platform. The user supplies the identifier to the outside service, and then the outside service fetches the public key associated with the identifier from the key master service. With the public key, cryptographic communication using the key pair can occur between the client application instance and the outside service.

Block S<b>110</b>, which includes creating a key pair at a first device, functions to establish the private key and a public key. The key pair is preferably created or generated in response to a user or application action. In one implementation of the method S<b>100</b>, Block S<b>110</b> is executed outside of operation of the method by a client application distinct from the system including the key master service. The key pair preferably includes a private key and a public key. A key is preferably a sequence of characters, be any suitable data object. Alternatively any suitable number of cryptographic tokens and token relationships may be used depending on the cryptographic key types. The private key is preferably stored within the host device in the client application or an alternative private data storage solution of the device. Generating the public key pair preferably uses an asymmetric key algorithm, but any suitable approach may be used. In one variation a public key distribution model mechanism is implemented. In a public key model, a client application could pass a symmetric key to the key master service and an outside service can pull it in using a similar key identifier key scheme. The key pair is created on the host device that intends to use the private key. The host device preferably stores the private key and will transmit the public key such that the public key is eventually stored by a target outside service (with initial storage in the key master service). The public key is preferably transferred through an API of the key master service. Herein key pairs and more specifically asymmetric key pairs are used in describing the method, but the method can alternatively be used in distributing other types of cryptographic tokens. In alternative implementations, the public key described in the method may be any suitable key or token to be shared between the device and the outside service. For example, the generated key on a mobile device could be a symmetric key. In this variation, the method may include receiving a key message at a key master service, wherein the key message originates from a first client application (S<b>110</b>); associating a key identifier with a first key of the key message (S<b>120</b>); storing the first key at the key master service indexed at least by a key identifier (S<b>130</b>); receiving a request for a key from an outside service, wherein the request specifies a key identifier (S<b>140</b>); and responding to the request with a key according to the key identifier (S<b>150</b>). If the key identifier of the request matches the key identifier mapped to the first key, and the request satisfies any policy conditions (e.g., it authenticates, key is not expired, etc.), the response to the request preferably includes the first key. The API can be a REST API using an application layer protocol such as HTTP, HTTPS, or SPDY. The API may alternatively be any suitable type of API. In addition to creating the key pair, the client application may additionally collect or generate additional information such as a user-specified key identifier, user geographic information, user authentication credentials, outside service identifiers (e.g., name, domain name, label, etc.).

The key pair is preferably created in response to an event on the client application. In one exemplary use-case, the key pair is generated in response to a user selecting an option to create a new account association within the application. The account association may be used for authentication, two-factor authentication, or any suitable use. Associated with creating the key pair, the method can include instantiating an account in the client application. The account can be instantiated independently of a pre-existing account. Being instantiated independently preferably describes the creation context where the outside service is not contacted or used during the creation, and at the very least, the public key is not transferred to the outside service (before additional processes of the method).

The host device is preferably a mobile computing device such as a mobile phone, a tablet, a wearable computing device, but the host device can alternatively be a desktop computing device, a TV connected computing device, or any suitable computing device. The key is more particularly generated according to a client application operative on the device. In many implementations, the application will use the private key to talk with an outside service.

In one implementation, the client application is a two-factor authentication application that functions to facilitate providing the second factor of authentication through the application. Preferably, instantiating an account includes activating the client application to act as a secondary factor of authentication for an outside service account. The two-factor authentication application can generally target multiple services that elect to use a two-factor platform of the two-factor application. The various services can include a wide variety of types of services. The types of services can include privately hosted outside services, an internal service operated by the same entity as the key master service operator, an enterprise internal service, and an on-premise service. The services are accessible and usable on a public network and/or a private intra-net. The use of the key master service also frees the outside service from maintaining support for direct communication of the public keys from the host device. The outside service would be free to reconfigure IP addresses, domain names, and other configurations without breaking support with the key pair distribution approach. Of these services, a machine address to the services may or may not be known, and the service in some cases may not be readily accessible for incoming communications, thereby preventing a public key to be directly transferred to the outside service.

Block S<b>120</b>, which includes receiving the public key of the key pair at a key master service, functions to transfer the public key to a centralized service. The client application preferably transmits the public key to a key master service using an API. The public key is preferably communicated as a public key message that can include additional meta data that can be used in storing and referencing the public key, authenticating outside service access, and/or otherwise managing the public key. The meta data can be supplemental information that can include information such as a password, a username, geolocation information, allowed outside service identifier, time expiration window, or any suitable information. Access to the API is preferably authenticated using API credentials granted to an account of the application developer. The key master service is preferably a centralized server system accessible over HTTP. The client application can POST the public key to the key master service, but can transmit the public key in any suitable manner.

Block S<b>130</b>, which includes storing the public key at the key master service indexed by a key identifier, functions to hold the public key at the key master service. The key master service as described is accessible by a plurality of different client applications and their respective devices/users. A plurality of keys can be stored by the key master service, and the keys can be for different devices and/or different outside services. The public keys can be stored anonymously using only an identifier to access a public key. The public keys are preferably stored such that the public keys are indexed by the key identifier—a public key can be uniquely identified and accessed using the key identifier. Storing a received public key includes generating and assigning a unique identifier to the public key. A user can use the identifier to inform an outside service how to access the public key using just the unique identifier. The identifier can be an alphanumeric code. While the identifier in one implementation is an easily human transcribable code (e.g., a 16 digit code), the unique identifier can alternatively be more complex. In the case where the identifier is complex, alternative mechanisms of transferring the code to an outside service can be used such as using QR codes or other suitable approaches. A record of the key and identifier can additionally include additional information values, which may be used in different variations of the method. For example, user credentials may be used to add a username-password-type authentication process when an outside entity tries to access of the public key. In another example, user location information may be used as a policy condition to restrict key access to identifying a geographic region substantially local to the location provided by the client application.

The public key is preferably stored temporarily, which functions to make the key master act as a public key escrow service. The public key can be stored in the key master service for the duration required to complete transfer to a service. Accordingly storing the public key preferably includes storing the public key with an expiration condition and when the expiration condition is satisfied, removing the public key. Removing the public key can include deleting the public key and/or public key record or otherwise preventing access to the public key. The public key can expire and be deleted after a certain time-based expiration window. The time-based expiration window can be an amount of time a specified date in the future or any suitable time condition. The public key can additionally include a limited number of access attempts such that the public key is not stored after a defined number of services have accessed the key. For example, a client application uploads a public key. The user then configures an outside service, which prompts the outside service to retrieve the associated public key. When transferring the public key to the outside service, the key master service deletes the public key so that it cannot be accessed by another entity. The public keys can alternatively be maintained or stored for any suitable duration. In a first variation, the public key record is deleted after successfully being accessed and transferred to a service. The first outside service to request the key can obtain the key. The key master service may allow any number of accesses to a key before deleting the public key as shown in <figref idref="DRAWINGS">FIG. 9</figref>. As an additional or alternative variation, a key may have any suitable form of assigned expiration condition. The expiration condition can be based on when and how a key was accessed. When the expiration condition is met, the particular public key is deleted or removed from the key master service. In some variations, a password or other suitable mechanism can be used to secure access of the public key.

Block S<b>140</b>, which includes transmitting the key identifier of the public key to the client application, functions to return an access mechanism to the originating device. The key identifier can be transferred as a response to the public key. For example, an HTTP POST may submit a public key to the key master service, and the HTTP response includes the key identifier. As mentioned above, the key identifier can be an alphanumeric code. The identifier can also be a random or unique phrase. In one variation, the transmitted identifier is an encoded version of the record identifier. The medium of the encoding can be a machine-readable audio signal or a visual image such as a QR code or bar code. In one variation, the key identifier is created on the client application and thus the method may avoid transferring a key identifier from the key master service to the client application.

At the client application, the identifier is received. The identifier is used as a more readily transferable item that can be communicated to an outside service. In a first variation, the user acts as the communication channel to transfer the identifier to the desired service. The client application displays the identifier to the user; the user then accesses the outside service; and when prompted, provides the identifier information in the outside service. For example, the user can type in the 16 digit key identifier into the outside service. Having completed the transfer of the identifier, the outside service can then access the key master service, specify the identifier and obtain the public key. From the user perspective, this processes is distilled into a more seamless transaction of simply copying a code from a client application to the desired service, and the use of an identifier enables a complex key to be efficiently transferred to an unknown service with high usability.

Block S<b>150</b>, which includes receiving a key request for the public key and responding with the public key, functions to deliver the public key to a requesting service. The request is made by an outside service in response to an identifier having been transferred to the service. The request can be an API call or any suitable communication. The service can be operated by a variety of entities and can be any suitable form of service such as a web service, a locally hosted service within an intranet, and/or a service operated by the operator of the key master service. The outside service is configured to accept an identifier and to communicate with the key master service at a defined machine address. The key master service includes a singular addressable endpoint or otherwise a defined set of endpoints that can be consistently addressed by outside services as well as client applications. As the address of the key master service is substantially stable, changes to the client application and/or the outside service may not negatively impact key distribution as it may for a direct app-to-service exchange.

The received request includes at least the key identifier. The key identifier is used by the key master service to access a stored public key with a corresponding key identifier. The public key is then transmitted to the key request. The key request may additionally include other parameters used to identify and/or authenticate a key request such as a user name and/or a password. Receiving a request and responding with the public key can additionally include processing the request and optionally verifying access conditions of the request. Processing the request preferably includes using at least the key identifier to identify the corresponding public key stored in a key repository. Verifying access conditions can include verifying various conditions are met and then granting or denying access appropriately as shown in <figref idref="DRAWINGS">FIG. 7</figref>. In one variation, the conditions are time-based expiration windows as shown in <figref idref="DRAWINGS">FIG. 8</figref>. In another variation, the condition is meta-data comparison. Various meta-data properties supplied during interaction with the client application may need to match to meta-data supplied by the outside service. For example, the user may supply a domain name they intend to use with the on device account. If the API request does not originate from that domain or a related subdomain then the request may be denied. Similarly, outside services may have to be registered and have undergone an enrollment process. As part of an enrolled service provider, the outside provider may be required to request key pairs using a set of whitelisted IP addresses. Other suitable access conditions may similarly be enforced. Additionally, availability of a public key may be altered asynchronous (i.e., not in response) to actions of an outside service and/or client application events. For example, a public key can be expired prior to any access attempts are made.

As described above, upon access of the public key, the public key record in the key master service may be permanently deleted. The key may alternatively be queued for deletion, set with an expiration time, marked for removal, marked as expired, or otherwise have access blocked. Delayed removal of the key can accommodate communication errors between the key master service and the service. Similarly, the outside service may transmit a message confirming receipt of the key, and the key master service removes the key record upon confirming receipt by the service. In an alternative approach where the public key may be reused, the identifier can be expired and a new one issued so that a second outside service will need a refreshed identifier to access the same public key.

Additionally, the method can include transmitting a message to a destination, which functions to notify the user or interested party of key events as shown in <figref idref="DRAWINGS">FIG. 10</figref>. The message preferably communicates events related to public key status. The key master service can push notifications to the client application to notify the user of successful key transfer, of a key expiring soon, of a key having expired, of blocked access attempts, or for any suitable event. The message can be a push notification delivered over a push service of the device. Alternatively, the message could be any delivered communication such as an email, text message, in-app message. The message can additionally be delivered to a callback URL, which can function to notify an interested service. For example, the server-side infrastructure used to support the client application may want to be informed of events such that server-side actions can be performed. A push identifier, an email address, a phone number, device address, URL, or other destination address of the client application or user device is preferably obtained when communicating the public key from the client application to the key master service. The destination is stored in association with the public key and/or the identifier. The destination address may alternatively be obtained during previous communication.

As shown in <figref idref="DRAWINGS">FIG. 5</figref>, a method S<b>200</b> for centralized key distribution of a second preferred embodiment includes receiving the key request at a key master service S<b>220</b>, creating a key pair at the key master service S<b>210</b>, storing the public key at the key master service S<b>230</b>, transmitting the private key of the key pair and an identifier of the public key to the device S<b>240</b>, receiving a request of the public key and responding with the public key S<b>250</b>. Method S<b>200</b> can function to provide a centralized activation scheme for key sharing through key generation off the device. The method S<b>200</b> preferably has similar benefits to method S<b>100</b> and includes similar variations and additional elements such as transmitting notification messages and verifying access conditions. As shown in the exemplary user experience flow of <figref idref="DRAWINGS">FIG. 6</figref>, a user can have a substantially similar experience, where as the key generation responsibility is changed to a centralized key management service. In method S<b>200</b>, the key pair is generated by the key master service. The key master service acts as the central service for generation and distribution as compared to method S<b>100</b> where the key generation and communication is more distributed amongst multiple entities. Blocks S<b>220</b> preferably precedes and prompts block S<b>210</b>. The key request in block S<b>220</b> can be a simple HTTP request without any data as opposed to a request in block S<b>120</b> that can include a public key. Additionally, the supplemental information such as user authentication credentials, geolocation information, outside service identifiers, and other meta data can be passed in the key request. The key master service creates or generates the key pair in a substantially similar manner to that in S<b>110</b>. Generating the key pair at the key master service may be a preferred alternative if the client device or application does not have the capabilities to generate the key pair or is not secure enough to have access to both keys. The key master service will preferably generate the key pair in response to a request by the client application. From a user perspective, the interaction flow will be substantially similar whether the key is generated on the device or the key master service—the user requests to create a new account on the client application and an identifier is presented to use with an outside service. Blocks S<b>230</b> and S<b>250</b> are substantially similar to those of Blocks S<b>130</b> and S<b>150</b>. Block S<b>240</b> is similar to S<b>140</b>, but S<b>240</b> sends the identifier along with the private key. The client application will store the private key.

In one variation, methods S<b>100</b> and S<b>200</b> may be selectively employed within a single system. The client application can dynamically decide the preferred approach or be preconfigured to use one of the two key generation approaches. If a request is received at the key master service and a public key is not provided, the key master service can automatically generate a key pair and deliver the private key and corresponding identifier. However, if a key is provided in the request, then that key is stored and an identifier is returned. Dynamically deciding the key generation approach may include detecting device type of the client application and then selectively proceeding with one of at least two modes.

In a first mode, generating a key pair at the client application, communicating at least the public key to the key master service and receiving a key identifier. The first mode results in an instance use where the process substantially resembles method S<b>100</b> after determining the mode. As discussed above, the first mode may be used in devices that have processing capabilities and/or security levels sufficient to generate a key and/or have at least temporary access to both keys in a key pair. In a second mode, requesting a private key and identifier from the key master service. The second mode preferably uses the remote key generation approach of method S<b>200</b>. The second mode may be selected for devices that have insufficient processing power or a vulnerable to attacks. In one variation, a vulnerability assessment may be run on the device and determine if the device is vulnerable to a type of attack. If the device is vulnerable to an attack then the second mode can be used to prevent the client device from having access to both keys.

As described above, the method is preferably implemented by a multi-tenant web service acting as the key master service. As a multi-tenant service, multiple client applications preferably use the service for distributing a public key to outside services. Similarly, a wide variety of outside services can use the key master service. The methods S<b>100</b> and S<b>200</b> are preferably performed in alongside and/or in parallel to other instances of the method. Accordingly for method S<b>100</b>, multiple client instances from a set of distinct client instances create key pairs, wherein each key pair is used by the respective client instance, and key identifiers unique to each key pair are received at the respective client application instance. At the key master service, the plurality of keys are received and processed individually. The key master service additionally receives key requests that specify different key identifiers, and those requests are similarly individually handled.

The system and method of the preferred embodiment and variations thereof can be embodied and/or implemented at least in part as a machine configured to receive a computer-readable medium storing computer-readable instructions. The instructions are preferably executed by computer-executable components preferably integrated with the key master service, a client application, and/or an outside service. The computer-readable medium can be stored on any suitable computer-readable media such as RAMs, ROMs, flash memory, EEPROMs, optical devices (CD or DVD), hard drives, floppy drives, or any suitable device. The computer-executable component is preferably a general or application specific processor, but any suitable dedicated hardware or hardware/firmware combination device can alternatively or additionally execute the instructions.

As a person skilled in the art will recognize from the previous detailed description and from the figures and claims, modifications and changes can be made to the preferred embodiments of the invention without departing from the scope of this invention defined in the following claims.