Cryptographic Operations in Isolated Sets

Abstract

Example implementations of the present disclosure describe systems and methods for performing cryptographic operations within an isolated set. In an example, a user may have associated user resources within the isolated set, which may be associated with cryptographic keys. Other users may access the user keys from a known location to perform one or more encryption operations manually or automatically. In another example, a key may be generated when initiating a group conversation. The key may be encrypted using the public keys of each participant and provided to each participant. Then, each participant may use the cryptographic key during the conversation. A new participant may receive authorization to join the conversation from an existing participant, where the cryptographic key of the existing participant may be decrypted and re-encrypted using the public key of the new participant. The new participant may then use the re-encrypted key to participate in the conversation.

Description

Technical Field

[0001] The present invention generally relates to a technical solution for performing cryptographic operations in an isolated set. Background Art

[0002] Cryptography can provide various authentication and data protection tools. As an example, the public key of an asymmetric key pair can be used to encrypt data and verify a cryptographic signature, while the private key of the asymmetric key pair can be used to decrypt data and generate a cryptographic signature. As a result, two parties can use multiple asymmetric key pairs (e.g., one key pair per party) to communicate securely, verify the source of the received data, and verify the identity of the other party. Traditionally, establishing such a cryptographic system requires at least one of various key exchange protocols or mechanisms to ensure that users within the cryptographic system can access the necessary keys for performing such cryptographic operations (e.g., encryption and signature verification, among others).

[0003] Regarding these and other general considerations, the aspects disclosed herein have been made. Moreover, although relatively specific issues may be discussed, it should be understood that these embodiments are not limited to solving the specific problems identified in the background art of the present disclosure or elsewhere. Summary of the Invention

[0004] Examples of the present disclosure describe systems and methods for performing cryptographic operations in an isolated set. In an example, a user can be associated with a user resource within the isolated set. The user resource can be associated with one or more cryptographic keys, which can be automatically generated or received from the user. In some examples, providing the cryptographic keys can be a prerequisite for obtaining access to the isolated set. In one example, a user can encrypt a resource by accessing the public key associated with a recipient stored by the isolated set. In another example, a recipient can use the public key associated with a sender stored by the isolated set to verify a cryptographic signature. As a result, such encryption operations can occur automatically because the necessary cryptographic keys can be accessed by other users of the isolated set from a known location.

[0005] In another example, a cryptographic key can be generated when initiating a conversation session. Messages sent during the conversation session can be encrypted using the cryptographic key and stored in the isolated set. In some examples, the messages can also be signed as described above. The cryptographic key can be encrypted using the public key of each session participant and provided to each session participant. When a new session participant wishes to obtain access to the conversation session, authorization can be requested from and provided by an existing session participant. The authorization can cause the encrypted cryptographic key of the existing session participant to be decrypted, after which it can be re-encrypted using the public key of the new session participant. The re-encrypted cryptographic key can then be provided to the new session participant, and the new session participant can then use it to access and participate in the conversation session.

[0006] The present invention content is provided to introduce some concepts in a simplified form, which will be further described in the following detailed description. The present invention content is not intended to identify the key features or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter. Other aspects, features, and / or advantages of the examples will be set forth in part in the following description, and in part will be apparent from the description, or may be learned by practice of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] The following non-limiting and non-exhaustive examples are described with reference to the accompanying drawings.

[0008] Figure 1 An overview of an example system for performing cryptographic operations within an isolated set is shown.

[0009] Figure 2 An overview of an example system for managing an isolated set of resource identifiers and corresponding relationships is shown.

[0010] Figure 3A An overview of an example isolated set is shown.

[0011] Figures 3B to 3E An example query model that can be used to traverse an isolated set is shown.

[0012] Figure 4 An overview of an example isolated set is shown.

[0013] Figure 5A An overview of an example encrypted conversation stored in an isolated set is shown.

[0014] Figures 5B - 5C An overview of an example key store associated with an encrypted conversation is shown.

[0015] Figure 6 An overview of an example method for verifying signatures within an isolated set is shown.

[0016] Figure 7 An overview of an example method for encrypting resources within an isolated set is shown.

[0017] Figure 8 An overview of an example method for encrypted group communication among participants within an isolated set is shown.

[0018] Figure 9 An overview of an example method for a new participant to obtain access to a group conversation session is shown.

[0019] Figure 10is a block diagram showing example physical components of a computing device with which aspects of the present disclosure may be implemented.

[0020] Figure 11A and Figure 11B is a simplified block diagram of a mobile computing device with which aspects of the present disclosure may be practiced.

[0021] Figure 12 is a simplified block diagram of a distributed computing system in which aspects of the present disclosure may be practiced.

[0022] Figure 13 shows a tablet computing device for performing one or more aspects of the present disclosure. Detailed Description

[0023] Aspects of the present disclosure are described more fully hereinafter with reference to the accompanying drawings, which form a part hereof and show specific exemplary aspects. However, the different aspects of the present disclosure may be implemented in many different forms and should not be construed as limited to the aspects set forth herein; rather, these aspects are provided so that this disclosure will be thorough and complete, and will fully convey the scope of these aspects to those skilled in the art. The aspects may be implemented as a method, system, or device. Thus, the aspects may take the form of an entirely hardware implementation, an entirely software implementation, or an implementation combining software and hardware aspects. Accordingly, the following detailed description should not be taken in a limiting sense.

[0024] The present disclosure provides systems and methods for performing cryptographic operations within an isolated collection. A resource can be a document, information related to a document (e.g., revisions, comments or notes, metadata, attributes, etc.), a message, a conversation, a presence update or indication, a calendar event, a user resource including information related to a user (e.g., username, user identity, email address, phone number, etc.), and others. A document can contain any type of information, including but not limited to text data, image or video data, audio data, drawings, simulations, 3D models, cryptographic keys, shared secrets, computations, algorithms, recipes, formulas, or any combination thereof. In some examples, a resource can be identified by a resource identifier, which can be a persistent uniform resource identifier (URI) pointing to a specific resource. The resource identifier can also be a uniform resource locator (URL), a uniform resource name (URN), or other suitable identifier or pointer to the resource itself. In one example, a resource can be stored in an isolated collection. In another example, a resource can be stored in a data collection, and the associated resource identifier can be stored in an isolated collection. For example, a resource can reside on a remote server, and the resource identifier can be used to retrieve the resource (e.g., the resource can be stored on a remote web server, where the resource identifier includes a URL). Identifying the location of a resource can include using, for example, regular expressions to parse the resource identifier, providing one or more parts of the resource identifier to a search utility, performing the resource identifier, etc. Relationships within an isolated collection can identify the correlation between two or more resources in the isolated collection. In some examples, the isolated collection can be a plurality of universal data nodes (UDNs), a document graph, or other collection of resources and relationships.

[0025] Resources or resource identifiers and / or relationships can be provided by a developer or other external sources. These resources, resource identifiers, and relationships are referred to herein as asserted resources, asserted resource identifiers, and asserted relationships. By executing a ruleset against data already in an isolated set, each isolated set can also be enriched to create additional relationships and, in some examples, create additional resource identifiers. The additional data generated by executing such a ruleset is referred to herein as inferred data, such as inferred relationships, inferred resources, and inferred resource identifiers. Queries can then be executed against the isolated set, which includes both asserted and inferred data, to provide richer results than would be available from the asserted data alone. The isolated set can also be stored as a graph database, and the results of queries against the isolated set can be displayed in a graphical format where resources are shown as nodes and relationships are shown as edges, as well as other display formats (e.g., as a tree, directed graph, matrix, table, etc.). As used herein, an isolated set of resource identifiers and the relationships between those resources or resource identifiers can be referred to as a "set". Additionally, access to the isolated set can be controlled by various techniques to provide additional security measures for the content in each isolated set, and each isolated set can have a different ruleset to generate unique and different inferred data to meet the specific needs of each application.

[0026] Within an isolated set, cryptographic keys can be used to sign and / or encrypt resources. In some examples, additional information (e.g., metadata, attributes, etc.) related to a resource (e.g., information about an encryption operation, last modified time, view count, security access control list, etc.) can be embedded in or associated with the resource. In one example, at least a portion of the resource and / or additional information related to the resource can be encrypted while at least another portion of the resource and / or related information can remain unencrypted. Additionally, different cryptographic keys can be used to sign and / or encrypt different resources, resource parts, or information related to resources within the isolated set. In other examples, a portion of a cryptographic key or cryptographic key pair (e.g., a public key) can be stored within the isolated set or another known location for retrieval during the execution of cryptographic operations. The cryptographic key can be a symmetric key or an asymmetric key pair consisting of a public key and a private key, as well as other key types. In one example, the public key can be used for encryption and signature verification, while the private key can be used for decryption and signature generation. In another example, the private key can be stored at a location or have access control other than that of the public key such that the availability of the private key is lower than that of the public key.

[0027] A variety of encryption algorithms can be used, including but not limited to the Advanced Encryption Standard (AES), Digital Signature Algorithm (DSA), Rivest-Shamir-Adleman (RSA), and Elliptic Curve Cryptography (ECC), as well as others or any combination thereof. In some examples, one cryptographic key (or key pair) can be used for signing or verification operations, while another cryptographic key (or key pair) can be used for performing encryption or decryption operations. Each cryptographic key can have similar or different properties compared to other cryptographic keys. As an example, each key can have a similar or different key length, or can use a similar or different cryptographic algorithm, as well as other similar or different properties unique to a particular cryptographic algorithm. Those skilled in the art will recognize that other cryptographic algorithms, key types, or systems can be used without departing from the spirit of the present disclosure.

[0028] Cryptographic keys can be stored in a key vault. In one example, information related to the cryptographic key can also be stored in the key vault, the information including but not limited to the algorithm type, one or more initialization vectors, or the key expiration date. The key vault can be a software component (e.g., an isolated collection, an encrypted data store, an access-restricted database, etc.), or can be a hardware device (e.g., a hardware security module, a trusted platform module, or other cryptographic hardware device). One or more key vaults can be associated with a user (e.g., user resources) and used to store the cryptographic keys associated with the user. In some examples, storing the cryptographic keys in the key vault can use the user's public key encryption such that they can only be accessed using the user's private key. In one example, instead of storing the cryptographic keys in a key vault associated with the user, alternatively the cryptographic keys themselves can be associated with the user and stored.

[0029] In another example, there can be a central key vault for storing the cryptographic keys for one or more users. As an example, among other reasons, the central key vault can be used to retain the cryptographic keys to meet data retention requirements or legal obligations. In one example, the central key vault can be encrypted such that the required decryption key is stored in escrow by a trusted third party. Access control lists or other access control mechanisms can be used to control access to the cryptographic keys. In some examples, the private key associated with a user can be stored or accessed separately and restricted such that only the user (or a small group of users, e.g., within a department, the user's manager, etc.) can access the private key, while the associated public key can be more widely available and / or stored in a known location as described above.

[0030] A cryptographic key can be associated with an identifier. The identifier can be used to access or locate the cryptographic key (e.g., in a key vault, a segregated collection, a data store, etc.). In some examples, the identifier can indicate a particular key vault or provide another indication that can be used to locate the cryptographic key. Additionally, the identifier can be stored with or associated with the cryptographic key. As an example, the key vault that stores the cryptographic key can also store the identifier associated with the cryptographic key. The key vault can use the identifier to index the cryptographic key to facilitate retrieval. The identifier can be a key fingerprint, a hash of the key, or information related to the key (e.g., MD5, SHA-1, etc.), or an identifier (e.g., a globally unique identifier (GUID)), a uniform resource identifier (URI), etc.) and others.

[0031] A user can be one or more entities that access, modify, or interact with a segregated collection. As an example, a user can be an individual, including but not limited to a person with a particular position or title or an employee (e.g., a system administrator, a manager, etc.). In another example, a user can be a group of people, such as an organization, a department within an organization, a list of people within a group, etc. In some examples, a user can be one or more entities within a computing system, including but not limited to a user account, an application, a service, a process, or a hardware or software module. Those skilled in the art will recognize that any entity can be a user without departing from the spirit of the present disclosure.

[0032] A user can have one or more cryptographic keys associated with their user resources in a segregated collection. In certain instances, such an association can be a prerequisite for interacting with the segregated collection (e.g., accessing resources, storing resources, sending resources, creating relationships and / or modifying relationships, and others). In one example, one or more cryptographic keys can be automatically generated, received from another entity (e.g., from the user, a different hardware or software module, etc.), or determined, or any combination thereof. In some examples, one or more security policies can be applied to the cryptographic keys. As an example, the cryptographic keys may be required to use a certain algorithm, have a certain length, or be stored in a certain way (e.g., using an encrypted hardware device, accessing a restricted data store, etc.) and others. The requirements can vary based on the context, including but not limited to characteristics or attributes associated with the user or the data stored or accessed by the user within the segregated collection.

[0033] Users of an isolated set may have cryptographic keys associated with other users that are readily accessible at one or more known locations, thereby providing ready access to the users' cryptographic keys for performing cryptographic operations (e.g., signature verification, resource encryption, etc.). As an example, a user's cryptographic key (e.g., the private key of a key pair) may be used to sign a resource automatically or manually such that other users can use the cryptographic key available from a known location (e.g., the public key of a key pair, which may be associated with the user's user resources) to automatically or manually verify the cryptographic signature. When a user interacts with a resource (e.g., when a user creates a resource, modifies a resource, shares or sends a resource, etc.), the resource may be automatically signed by the user. Similarly, when another user accesses the resource, the signature may be automatically verified. As an example, an antivirus application may be the user and may provide such an indication (e.g., as metadata, as one or more attributes, as a relationship, etc.) after determining that the resource is not malicious or otherwise infected, the indication being accompanied by a signature generated using the private key associated with the antivirus application (e.g., the cryptographic key associated with the user resources of the antivirus application).

[0034] In another example, when a sender sends a resource to a receiver, the resource may be automatically encrypted. In one example, the resource may include a flag indicating that the resource should not be sent unless it can be sent in an encrypted format. Assuming that the receiver's public key is available from a known location, the sender may access the cryptographic key associated with the receiver (e.g., the public key of a key pair, which may be associated with the receiver's user resources). The sender may then use the public key to encrypt the resource and provide the encrypted resource to the receiver. The receiver may access the private key of the key pair to decrypt the resource. In another example, accessing the private key may include providing at least a portion of the data of the encrypted resource to a key vault containing the private key, where the key vault may decrypt a portion of the data and provide the unencrypted data in response. As a result, the receiver does not need to receive the actual cryptographic key to perform decryption or signature generation operations. In some examples, as described above, the resource may also be signed by the sender, so the receiver may also verify the sender's signature.

[0035] There may be one or more asserted or inferred relationships between a resource and a user resource. In one example, a relationship can be created when a user performs an encryption operation on a resource (e.g., when a user signs a resource, when a user encrypts a resource, etc.). In another example, there may already be a pre-existing relationship between the resource and the user resource (e.g., because the user created or modified the resource, sent or received the resource, or participated in various other interactions with the resource). In some examples, the user associated with the user resource and the user performing the cryptographic operation can be different. For example, when a first user encrypts a resource using the public key of a second user, a relationship can be formed between the resource and the user resource associated with the second user (rather than the user resource associated with the first user), indicating that the cryptographic key associated with the second user can be used to decrypt the resource. As a result, the user associated with the resource can be determined by evaluating the relationships of the resource. Similarly, the relationships of the user resources associated with a user can be used to determine one or more resources with which the user interacts.

[0036] To encrypt a resource for decryption by a recipient, a user can access the user resource associated with the recipient. The user resource can have a relationship with one or more cryptographic keys, and then the one or more cryptographic keys can be accessed and used to generate an encrypted representation of the resource. In one example, a key pair can be associated with the resource itself. At least one key in the key pair can be access-restricted so that it cannot be widely accessed (e.g., it can be accessed by the sender and the recipient or a group of users, among others). In this example, the public key of the associated key pair can be used to generate the encrypted representation of the resource. The encrypted representation can be stored and / or provided to the recipient. Providing the resource can include sending the resource to the recipient or storing the resource in an isolated collection (as a new resource, rewriting or replacing the unencrypted resource, etc.) and providing a notification to the recipient, among others. In some examples, a relationship (e.g., a "recipient" relationship) can be formed between the encrypted resource and the recipient, where the relationship can provide an indication of which user's cryptographic key was used for the encryption operation.

[0037] In another example, a resource can be signed by a user (e.g., before or after sending the resource to enable other users to verify the status of the resource, as a non-repudiation technique, etc.). The resource can be signed using the private key associated with the user or in one example, the private key associated with the resource. A relationship can be formed between the signed resource and the user resource associated with the user, such that it can be determined which user signed the resource based on the relationship. As a result, to verify the signature of the resource, the relationships of the resource can be evaluated to determine the user resource associated with the signer. The relationships of the user resource of the signer can be evaluated to identify the public key associated with the signer, and then the public key can be used to verify the signature of the resource.

[0038] Messages of a conversation session can be stored in an isolated set, where a cryptographic key can be used to encrypt the messages of the conversation. As described above, the cryptographic key can be an asymmetric key pair or a symmetric key, among others. The cryptographic key can be generated when initiating a conversation session. In some examples, an identifier associated with the cryptographic key can be stored in the isolated set such that a relationship can be formed between the cryptographic key and the messages sent during the conversation session. The cryptographic key can be distributed to the participants of the session. In one example, distributing the cryptographic key can include sending an encrypted representation of the cryptographic key to each user, where the cryptographic key has been encrypted with the public key of the user as indicated by the isolated set. Then, each user can store the encrypted representation of the cryptographic key (e.g., stored in a key vault, an isolated set, etc.). In another example, the cryptographic key can be provided to the participants, and then the participants can encrypt and store the key (e.g., stored in a key vault, using an encrypted hardware device, etc.). In one example, as a result of storing the key, the key can be encrypted by a storage component. In some examples, the cryptographic key can be retained by the system (e.g., in a central key vault, hosted by a trusted third party, etc.) to meet data retention policies or other legal obligations. When accessing the conversation session or sending a message, the user can use his / her private key to decrypt the encrypted key and use the decrypted key accordingly. In some examples, according to the aspects disclosed herein, the messages transmitted during a conversation session can be signed by the sender and / or verified by the receiver. In another example, the decrypted key can be locally cached for at least a portion of the conversation session.

[0039] At some point, a new session participant can be added to the conversation session. The new session participant can request access from a previously existing participant, and if authorized, can use the private key of the previously existing participant to decrypt the encrypted cryptographic key of the previously existing participant and re-encrypt it using the public key of the new session participant (e.g., which can be stored by the isolated set). Then, the new conversation participant can store the encrypted cryptographic key and use the decrypted representation of the encrypted cryptographic key to access and participate in the conversation session. As a result of receiving the cryptographic key, the new participant may be able to access the messages encrypted with the cryptographic key, even if they may have been transmitted before the new participant joined the conversation session.

[0040] Figure 1An overview of an example system for performing cryptographic operations within an isolated set is shown. Example system 100 can be a combination of interdependent components that interact to form an integrated whole for performing delegated authentication. In various aspects, system 100 can include hardware components (e.g., for executing / running an operating system (OS)) and / or software components running on the hardware (e.g., applications, application programming interfaces (APIs), modules, virtual machines, runtime libraries, etc.). In certain aspects, system 100 can provide an environment for software components to execute, evaluate a set of operation constraints, and utilize the resources or facilities of system 100. In these aspects, the environment can be included or installed on one or more processing devices. For example, software (e.g., applications, operation instructions, modules, etc.) can run on processing devices such as computers, mobile devices (e.g., smartphones / phones, tablets, laptops, personal digital assistants (PDAs), etc.) and / or any other electronic devices. As an example of an operating environment for a processing device, reference is made to Figures 10 - 13 the exemplary operating environment depicted therein. In other instances, the components of the systems disclosed herein can be distributed across multiple devices and can be executed by multiple devices. For example, input can be made on a client device, and information can be processed or accessed from other devices in the network (e.g., server devices, network devices, other client devices, etc.).

[0041] As presented, system 100 includes client devices 102A-C, a distributed network 104, and a distributed server environment including one or more servers (e.g., server devices 106A-C). Those skilled in the art will recognize that the scale of a system such as system 100 can vary and can include more or fewer components than Figure 1 the components described therein. In some aspects, the engagement between the components of system 100 can occur remotely, e.g., where the components of system 100 can be distributed across one or more devices of a distributed network.

[0042] In an aspect, client devices 102A-C can be configured to receive input via a user interface component or other input unit. Examples of input can include voice, visual, touch, and text input. The interface component can implement the creation, modification, and navigation of various data sets and graphical representations. In an example, the various data sets can include (or otherwise be associated with), for example, resource identifiers, resource metadata, relationship information, asserted relationships, graphical mapping information, query data, rule sets such as inference rules, authorization information, authentication information, etc., as discussed further in detail below. Generally, the data sets are stored on one or more server devices 106A-C and are accessible by client devices 102A-C. However, in some examples, the data sets can be stored at least in part on one or more of client devices 102A-C. The underlying resources represented in the various data sets can be stored locally or in a data store accessible by client devices 102A-C, such as a cloud storage application. In at least one example, the underlying resources represented in the various data sets (or portions thereof) can be distributed across client devices 102A-C. For example, client device 102A (e.g., a mobile phone) can locally store a first portion of the resources represented in the data set, client device 102B (e.g., a tablet) can locally store a second portion of the resources, and client device 102C (e.g., a laptop computer) can locally store the remaining portion of the resources represented in the data set. In an example, client devices 102A-C can access all of the resources included in the data set, can access a subset of the resources included in the data set, or alternatively, cannot access any of the resources included in the data set.

[0043] Client devices 102A-C can also be configured to interrogate a data store that includes data corresponding to the resource identifiers in the various data sets. In an example, client devices 102A-C can interrogate a content provider, such as server devices 106A-C, via a distributed network 104. The interrogation can include identifying the remote device where the resource is located and / or determining whether the remote device (or service / individual remote device) has authenticated access to the resource. If access to the resource has been authenticated, client devices 102A-C can retrieve an authentication indication from the remote device. Client devices 102A-C can use the authentication indication to provide access to one or more of the various data sets that include the corresponding resource identifier.

[0044] Server devices 106A-C may be configured to store and / or provide access to one or more resources. For example, server device 106A may be a web server, server device 106B may be a device including a collaboration messaging tool and a calendar application, and server device 106C may be an email server. Each of these devices may include a repository of resources that may be accessed via one or more authentication mechanisms. In an example, server devices 106A-C may perform or monitor an authentication process upon receipt of a request for a resource. If authentication is successful, the authentication device may store an authentication indication or maintain the authentication indication for a specified period of time. When the period expires, server devices 106A-C may remove or attempt to update the authentication indication. In an example, server devices 106A-C may provide the authentication indication to an interrogating client device. In some aspects, server devices 106A-C may also be configured to store at least a portion of various data sets and graphical representations, as described above.

[0045] Figure 2 An overview of an example system 200 for managing an isolated collection of resource identifiers and corresponding relationships is shown. Isolation collection techniques implemented in system 200 may include Figure 1 one or more of or associated with the delegation authentication techniques described in. In an alternative example, a single device (including one or more components such as a processor and / or memory) may perform the processing described in systems 100 and 200, respectively.

[0046] Regarding Figure 2, the system 200 may include collection creation applications 202 and 204, collection environments 206, collections 208 and 210, entities 212 and 214, resource identifiers 216, 218, 220, 222, 224, and 226, and resources 228, 230, 232, 234, 236, and 238. In various aspects, collection creation applications 202 and 204 may be applications or services configured to create, infer, manipulate, navigate, and visualize various resources, relationships, and graphical representations. Collection creation applications 202 and 204 may define sets of relationships between resources (e.g., people, files, tasks, emails, documents, calendar events, etc.) and execute queries on these sets. Collection creation applications 202 and 204 may also provide for defining and storing a set of rules for inferring one or more relationships in a collection, and displaying a graphical representation of the collection data. The defined set of rules may be stored in the collection itself and, in some examples, stored as metadata within the collection. In an example, collection creation applications 202 and 204 may be installed and executed on a client device or on one or more devices in a distributed environment. For example, collection creation application 202 may be installed on client device 102A, collection creation application 204 may be installed on client device 102B, and a collection creation service associated with server device 106A may be accessible to client device 102C.

[0047] In various aspects, collection creation applications 202 and 204 may access a file directory or execution environment, such as environment 206. Environment 206 may be collocated with the collection creation application, or environment 206 may be locally remote from the collection creation application. Environment 206 may provide access to one or more of a collection of data (e.g., collections 208 and 210). In an example, access to the collection of data may be determined using one or more sets of permissions generated and / or maintained by collection creation applications 202 and 204. These sets of permissions may vary across one or more collections of data. As a result, one or more of the collections of data (or functions associated therewith) may not be accessible from one or more of collection creation applications 202 and 204.

[0048] Collections 208 and 210 may each include an isolated set of asserted resource identifiers and corresponding relationships. The relationships in the isolated set may be defined manually or may be automatically derived using one or more sets of rules. The isolated set may be represented using a graphical structure that directly associates resources in a collection of data and provides a means to retrieve relationship data in a single operation. Each isolated set may include resource identifiers unique to that isolated set. Alternatively, the isolated set may include resource identifiers included in one or more alternative isolated sets. For example, as Figure 2As shown, collection 208 may include resource identifiers 216, 218, 220, and 222, and collection 210 may include resource identifiers 220, 222, 224, and 226. Resource identifiers 216, 218, 220, 222, 224, and 226 may correspond to and / or identify the location of one or more resources. As used herein, a resource identifier refers to an existing resource, but is not a resource itself. Exemplary types of resource identifiers include, but are not limited to, Uniform Resource Identifiers (e.g., Uniform Resource Locators (URLs), Uniform Resource Names (URNs), etc.), IP addresses, memory or storage addresses, and the like. Those skilled in the art will recognize that, without departing from the scope of the present disclosure, various aspects disclosed herein may employ any type of identifier. Identifying the location of a resource may include, for example, using a regular expression to parse the resource identifier, providing one or more portions of the resource identifier to a search utility, executing the resource identifier, etc. In various aspects, accessing a data collection does not guarantee access to the resources identified by the resource identifiers contained in each data collection. For example, although a user may be able to access and manipulate collection 208, the user may not be authorized to access one or more of the underlying resources corresponding to the resource identifiers in collection 208.

[0049] Resource providers 212 and 214 may be configured to store and / or provide access to one or more resources. Thus, a resource provider as used herein may be a data store, a cloud service provider, a client computing device, a server computing device, a distributed device system, e.g., an enterprise network, an application, a software platform (e.g., an operating system, a database, etc.), and the like. In various aspects, resource providers 212 and 214 may (or may have access to) various different data sources, such as content providers, data stores, various application data sets, etc. A data store may include one or more resources corresponding to one or more resource identifiers. For example, as Figure 2As shown, the resource provider 212 can be a data store including various different types of resources, such as the resources 228 (e.g., Document 1 (D1)) and 230 (e.g., Presentation 2 (PI)), and the resource provider 214 can be a contact management application, including contact resources 232 (e.g., Contact 1 (CI)), 234 (e.g., Contact 2 (C2)), 236 (e.g., Contact 3 (C3)), and 238 (e.g., Contact 4 (C4)). In this example, the resource identifier 216 can correspond to the resource 228; the resource identifier 218 can correspond to the resource 230; the resource identifier 220 can correspond to the resource 232; the resource identifier 222 can correspond to the resource 234; the resource identifier 224 can correspond to the resource 236; the resource identifier 226 can correspond to the resource 238. In some aspects, the resource providers 212 and 214 can be accessed by the collection creation applications 202 and 204. The collection creation applications 202 and 204 can access the resource providers 212 and 214 to determine the existence of resources and / or retrieve information associated with the resources (e.g., resource metadata, resource location, resource identifier, permission set, authentication data, etc.). The information retrieved from the resource providers 212 and 214 can be used to determine a set of resource identifiers corresponding to one or more of the available resources. This set of resource identifiers can be used to create one or more isolated collections of asserted resource identifiers and correspondences. As described above, the resource identifier can be or include a persistent URI for its corresponding resource. For example, the resource identifier 216 can include the URI for the actual document (D1) 228. Thus, in such an example, the user can determine the location of the document (D1) 228 from the collection and, depending on authentication and access restrictions, retrieve the document (D1) 228. As another example, as Figure 2 shown, the resource provider 212 can be accessed by the collection creation application 202. The collection creation application 202 can determine that the resource provider 212 includes at least the resources 228 and 230 and may determine the resource identification information for each resource. Based on the determined resource identification information, the resource identifiers 216 and 218 can be applied / associated to the resources 228 and 230 respectively and provided to the environment 206. Then, the environment 206 can make the resource identifiers 216 and 218 eligible for inclusion analysis into one or more isolated collections.

[0050] Figure 3AAn example isolated set 300 showing asserted resource identifiers and correspondences is shown. The example isolated set 300 includes resource identifiers 302, 304, 306, 308, 310, 312, and 314, and relationships 316, 318, 320, 322, 324, and 326. In an aspect, a set creation utility can be used to generate and / or manipulate the isolated set 300, and the set creation utility can be included as part of the set creation application discussed above. When presented in the graphical form depicted in Figure 3A each resource identifier can be referred to as a "node" and each relationship can be referred to as an "edge". The set creation utility can also use one or more rule sets to identify resources and / or determine resource types for the set, and the rule sets can include rules defined according to semantic web technologies such as Resource Description Framework (RDF), RDF Schema (RDFS), SPARQL Protocol, and RDF Query Language (SPARQL), Web Ontology Language (OWL), etc. For example, the set 300 includes a resource identifier 312 representing an underlying resource, which is "email789 (E-mail 789)" in the depicted example. Similarly, the resource identifier 304 represents the resource document "Doc123 (Document 123)", and the resource identifier 302 represents the resource task "Taskl23 (Task 123)". Each resource and relationship included in the isolated set 300 can be asserted by a developer through the set creation application. For example, the developer can manually add each resource identifier and the relationship between the resource identifiers. As an example, the developer can manually indicate that "taskl23 (Task 123)" is a task on "Docl23 (Document 123)", as represented by the "taskOn (task thereon)" relationship 316 in the set 300. Resource identifiers and relationships can also be asserted by an external bot or an application created by a developer. For example, an add-on can be programmed to monitor activities in a browser or other applications to track the usage of the application. Based on the usage of the application, the add-on sends additional resources and relationships to be included in the set 300.

[0051] Different from the asserted resource identifiers and relationships, the set creation utility can execute rule sets to determine additional relationships and resource types, here referred to as "inferred relationships" and "inferred resource identifiers" or "inferred resource types". For example, when executing the rule set, the set creation utility can determine that the resource identifier 312 represents an e-mail message and the resource identifier 304 represents a document. The generation of inferred relationships and resources is discussed in further detail below.

[0052] The isolated collection 300 further depicts resource identifier 302 associated with resource identifiers 304, 306, and 308, as well as resource identifier 310. A collection creation utility can determine that resource identifier 302 represents a task to be performed on identifiers 304, 306, and 308. Based on that determination, the collection creation utility can assign relationships 316, 318, and 320 (e.g., "taskOn (task thereon)") to define the association between resource identifier 302 and resource identifiers 304, 306, and 308. In other examples, relationships as described above can be asserted 316, 318, and 320. Additional relationships such as the "hasDiscussion (discussion)" relationship 322 can be manually asserted by a developer or asserted from an add-in of an email application that analyzes the content of email 101. While specific types of resources and relationships are as Figure 3A described, those skilled in the art will recognize that other types of resources and / or relationships can be included in the isolated collection without departing from the spirit of the present disclosure.

[0053] Figures 3B - 3E An example query model that can be used to traverse collection 300 is shown. In various aspects, a query can be executed via an interface provided by the collection creation utility. The query can be executed against one or more files and / or directories that include information such as resource identifiers, resource types, resource metadata, permission data, etc. The query results can be visualized in graphical form as one or more collections, such as collection 300. For example, the entire collection 300 data set can include only those elements shown in collection 300 (e.g., resource identifiers 302, 304, 306, 308, 310, 312, and 314, and relationships 316, 318, 320, 322, 324, and 326). In this particular example, resource identifier 312 can represent an email that includes the subject "API Design", and resource identifier 314 can represent an email that includes the subject "Collection". A query 'http: / / ... / collection300 / taskl23' can be executed against collection 300. The query results can include resource identifier 302 and be visualized as Figure 3B shown. In Figure 3C , the query has been modified to 'http: / / ..Jcollection300 / taskl23?$expand=taskOn' and executed against collection 300. The query results can include resource identifiers 302, 304, 306, and 308, and relationships 316, 318, and 320, and be visualized as Figure 3C shown. In Figure 3DIn it, the query has been modified to 'http: / / ..Jcollection300 / taskl23?$expand=taskOn($expand=attachmentOn)' and executed against collection 300. The query results may include resource identifiers 302, 304, 306, 308, 312, and 314, as well as relationships 316, 318, 320, 324, and 320, and the visualization is as shown in Figure 3D shown. In Figure 3E it, the query has been modified to 'http: / / ..Jcollection300 / taskl23?($expand=taskOn($expand=attachmentOn)($filter=Subject eq 'Setsets'))' and executed against collection 300. Since only resource identifier 314 and the subject "Sets" are included, the query results may include resource identifiers 302, 306, and 314, as well as relationships 318 and 326, and the visualization is as shown in Figure 3E shown.

[0054] Figure 4An overview of an example isolated set 400 is shown. The isolated set 400 can include Person 1 402 and Person 2 416, which can be user resources as described herein. The private key 404 and the public key 406 can be associated with Person 1 402 through relationships 408-14. In some examples, the private key 404 and the public key 406 can be key identifiers, where the actual cryptographic keys can be stored in a key vault or other data store (not shown). When Person 1 402 first obtains access to the isolated set 400, the private key 404 and the public key 406 may have been provided by Person 1 402. In another example, the private key 404 and the public key 406 may have been automatically generated. Relationships 408 and 412 use solid arrows to indicate the relationships asserting the existence of a "key" between Person 1 402 and the private key 404 and between Person 1 402 and the public key 406, respectively. Relationships 408 and 412 are directional because they indicate that both the private key 404 and the public key 406 are keys for Person 1 402 and not the other way around. Similarly, relationships 410 and 414 use dashed arrows to indicate the inferred relationships of "keyFor" between the private key 404 and Person 1 402 and between the public key 406 and Person 1 402, respectively. Relationships 410 and 414 are directional because they indicate that the private key 404 is the key for Person 1 402 and the public key 406 is the key for Person 1 402 and not the other way around.

[0055] Similarly, the key store 418 can be associated with Person 2 416 through relationships 420 and 422. The key store 418 can be a key store as described herein and can be used to store cryptographic keys associated with Person 2 416. In some examples, the key store 418 can store public and private keys, store only public keys, asymmetric keys, symmetric keys, encrypted or unencrypted keys, or any combination thereof. In one example, the key store 418 can be stored in the isolated set 400, while in other examples, the key store 418 can be a resource identifier associated with a key store stored elsewhere (e.g., in a data store, a hardware security module, etc.). When Person 2 416 first obtains access to the isolated set 400, the keys stored in the key store 418 may have been provided by Person 2 416. In another example, keys can be automatically generated. The key store 418 can store a combination of the provided keys and the generated keys. Relationship 420 uses a solid arrow to indicate the asserted relationship of "keys" existing between Person 2 416 and the key store 418. Relationship 420 is directional because it represents that the key store 418 stores keys for Person 2 416 and not the other way around. Similarly, relationship 422 uses a dashed arrow to indicate the inferred relationship of "keysFor" existing between the key store 418 and Person 2 416. Relationship 422 is directional because it indicates that the key store 418 is the key store for Person 2 416 and not the other way around.

[0056] Both Person 1 402 and Person 2 416 can be authors of the shared resource 424. This can be indicated by the relationships 426 and 428, which are asserted "author" relationships in the direction as shown by the solid - direction arrows between the shared resource 424 and Person 1 402 and between the shared resource 424 and Person 2 416, respectively. In contrast, the "authorOf" relationships 430 and 432 are inferred relationships, indicated by the dashed lines between Person 1 402 and the shared resource 424 and between Person 2 416 and the shared resource 424, respectively. While the specific relationships between the user resources 402 and 416 and the shared resource 424 are described herein, those skilled in the art will recognize that other types of relationships can exist between resources without departing from the spirit of the present disclosure. For example, other exemplary relationships include, but are not limited to, "ownerOf", "senderOf", "editorOf", etc. The shared resource 424 can be a resource as described herein and can be used by other users of the isolated set 400. Thus, the shared resource 424 can be signed by Person 1 402 and / or Person 2 416, enabling other users to verify the status of the resource upon signature. Signature verification can be performed by identifying the cryptographic keys (e.g., public keys) associated with Person 1 402 and / or Person 2 416 (e.g., public key 406 and the public key stored in the key store 418, respectively). The shared resource 424 and its signature can then be verified based on the identified cryptographic keys.

[0057] Conversely, the encrypted resource 434 can be an encrypted communication or other resource communicated between Person 1 402 and Person 2 416. As shown, Person 2 416 sends the encrypted resource 434 to Person 1 402. This is indicated by the relationship 438, which is the asserted directional "sender" relationship between the encrypted resource 434 and Person 2 416. Conversely, the relationship 442 is the inferred directional "send" relationship, which indicates that Person 2 416 sends the encrypted resource 434. Similarly, the asserted directional "receiver" relationship 436 indicates that the receiver of the encrypted resource 434 is Person 2. Conversely, the inferred directional "receive" relationship 440 indicates that Person 1 402 receives the encrypted resource 434. Person 2 416 can sign the encrypted resource 434 using a private key (e.g., a key stored in the key vault 418 or at least associated with the key vault 418), after which Person 2 416 may have identified the cryptographic key associated with the recipient Person 1 402. Person 2 may have used the identified cryptographic key (e.g., the public key 406) to encrypt the encrypted resource 434.

[0058] Person 1 402 can generate a decrypted representation of the encrypted resource 434 using the private key 404, which is the private key of a key pair that includes the public key 406. After decrypting the encrypted resource 434, by examining the relationships associated with the encrypted resource 434 (e.g., based on the relationship 438), Person 1 402 can determine that Person 2 416 is the sender. As a result, Person 1 402 can identify the cryptographic key associated with Person 2 416. In some examples, the cryptographic key can be the public key stored in the key vault 418, and Person 1 402 can use the public key to verify the signature of the unencrypted representation of the encrypted resource 434.

[0059] Figure 5AShows an overview of an example encrypted conversation stored in the isolated set 500. The isolated set 500 includes Message 1 502, Message 2 504, and Message 3 506. Message 1 502, Message 2 504, and Message 3 506 can be messages (or references to messages) transmitted during a conversation session as disclosed herein. Relationships 508 and 510 use solid arrows to indicate relationships where a "replyTo" assertion exists between Message 2 504 and Message 1 502 and between Message 3 506 and Message 2 504, respectively. Relationships 508 and 510 are directional because they indicate that Message 2 is a reply to Message 1, and Message 3 is a reply to Message 2, and not the other way around. Similarly, relationships 512 and 514 use dashed arrows to indicate inferred relationships where a "repliedToBy" relationship exists between Message 1 502 and Message 2 504 and between Message 2 504 and Message 3 506, respectively. Relationships 512 and 514 are directional because they indicate that Message 1 502 is replied to by Message 2 504, and Message 2 504 is replied to by Message 3 506, and not the other way around.

[0060] The isolated set 500 also includes a ConvlEncKey 516, which can be a cryptographic key (or a reference to a cryptographic key) for encrypting messages transmitted during a conversation session. More specifically, the ConvlEncKey 516 can be generated when the conversation session is initialized and used to encrypt Message 1 502, Message 2 504, and Message 3 506. Thus, the relationships 518, 520, and 522 use solid arrows to indicate the "encryptedBy" asserted relationships that exist between Message 1 502 and ConvlEncKey 516, Message 2 504 and ConvlEncKey 516, and Message 3 506 and ConvlEncKey 516. In this way, the relationships 518, 520, and 522 indicate that Message 1 502, Message 2 504, and Message 3 506 are each encrypted by the ConvlEncKey 516. Additionally, the relationships 524, 526, and 528 use dashed arrows to indicate the "usedToEncrypt" inferred relationships that exist between ConvlEncKey 516 and Message 1 502, ConvlEncKey 516 and Message 2 504, and ConvlEncKey 516 and Message 506, respectively.. As a result, it can be determined that the ConvlEncKey 516 is used to encrypt Message 1 502, Message 2 504, and Message 3 506.

[0061] Figure 5B An overview of an exemplary key store 530 associated with an encrypted conversation session is shown, the encrypted conversation session being, for example, a conversation session stored in the isolated set 500 as discussed above with respect to Figure 5A As discussed above. The key store 530 can be associated with a user (e.g., "Participant 1") and stored in the isolated set. The key store 530 can include one or more key entries, where each key entry can include a key identifier and a key value. As discussed above, the key identifier can be a key fingerprint, a hash of the key, or information related to the key (e.g., MD5, SHA-1, etc.), or an identifier (e.g., GUID, URI, etc.) and others. The key value can be data related to the cryptographic key stored in the key store.

[0062] The key store 530 may include first key entries 532A - B and second key entries 534A - B. The first key entry includes a key identifier ConvlEncKey 532A and a key value 532B. Similarly, the second key entry includes a key identifier Conv2EncKey 534A and a key value 534B. In some examples, the exemplary key store 530 may be indexed according to the key identifiers 532A and 534A such that the key identifiers (e.g., "ConvlEncKey" or "Conv2EncKey") can be used to search for the associated key values (e.g., key values 532B and 534B).

[0063] Figure 5C An overview of an exemplary key store 540 associated with an encrypted conversation session, such as the conversation session stored in the isolated set 500 as discussed above with reference to Figure 5A as discussed. As discussed herein, the key store 540 may be associated with a user (e.g., "Participant 2") and stored in the isolated set. In some examples, the key store 540 may be the key store 418 associated with Person 2 416, as Figure 4 shown. The key store 540 may include one or more key entries, where each key entry may include a key identifier and a key value. As described above, the key identifier may be a key fingerprint, a hash of the key, or information related to the key (e.g., MD5, SHA - 1, etc.), or an identifier (e.g., GUID, UR, etc.) among others. The key value may be data related to the cryptographic key stored in the key store.

[0064] The key store 540 may include first key entries 542A - B and second key entries 544A - B. The first key entry includes a key identifier ConvlEncKey 542A and a key value 542B. Similarly, the second key entry includes a key identifier Conv3EncKey 544A and a key value 544B. In some examples, the exemplary key store 540 may be indexed according to the key identifiers 542A and 544A such that the key identifiers (e.g., "ConvlEncKey" or "Conv3EncKey") can be used to search for the associated key values (e.g., key values 542B and 544B).

[0065] Reference Figures 5A - 5C, a session participant (e.g., "Participant 1" or "Participant 2") may wish to access messages stored in the isolated set 500 (e.g., Message 1 502, Message 2 504, and / or Message 3 506). At least one of the session messages can be accessed and used to determine the cryptographic key required to decrypt the session message. In an example, the appropriate cryptographic key can be determined by evaluating at least one of the relationships 518, 520, or 522 to determine that ConvlEncKey 516 should be used to decrypt the conversation message. As a result, it can be determined whether ConvlEncKey 516 can be accessed to decrypt the conversation message. In some examples, the key store 530 or the key store 540 can be accessed to determine whether there is an identifier that matches the identifier of ConvlEncKey 516. If it is determined that the conversation participant can access the cryptographic key associated with the key identifier "ConvlEncKey" (e.g., key identifiers 532A or 542A for Participant 1 or Participant 2, respectively), the key value (e.g., key values 532B or 542B, respectively) can be decrypted using the participant's private key. The decrypted key can then be used to decrypt the messages stored in the isolated set 500.

[0066] Conversely, if it is determined that the cryptographic key associated with the key identifier "ConvlEncKey" is not available, a request can be provided to Participant 1 and / or Participant 2. If the current participant authorizes the access request, the current participant's private key can be used to decrypt the current participant's key with the identifier "ConvlEncKey", and then it can be re-encrypted using the requester's public key. The re-encrypted cryptographic key can then be provided to the requester. The requester can decrypt the received key as described above to access the conversation session stored in the isolated set 500.

[0067] Figure 6 An overview of an example method 600 for verifying signatures within an isolated set is shown. Method 600 begins at operation 602, where a signed resource can be received. The signed resource can be the shared resource 424, as Figure 4 shown. The signed resource may be received as a result of an indication provided by a user (e.g., Person 1 402 or Person 2 416). The signed resource can be stored in an isolated set (e.g., the isolated set 400). In some examples, method 600 can occur automatically when accessing the signed resource.

[0068] Move to operation 604, where the signer can be determined for the resource. Determining the signer can include evaluating one or more relationships associated with the signed resource to identify the user resource associated with the signer. In some examples, metadata or attributes associated with or stored with the signed resource can provide indications that can be used in the determination. After identifying the signer, the process moves to operation 606, where the public key associated with the signer can be identified within the isolated set. Identifying the public key can include accessing the user resource associated with the signer to evaluate one or more relationships of the user resource. In some examples, the user resource can have one or more "key" relationships (or similar associations) with a resource including a key vault, cryptographic key, or cryptographic key identifier. In another example, there can be multiple relationships, and identifying the public key can include evaluating multiple cryptographic keys. In one example, the signed resource can include metadata or attributes that can provide an indication of a specific cryptographic key that can be used in the identification.

[0069] At operation 608, the public key can be accessed from the isolated set. Accessing the public key can include retrieving the public key from a cryptographic key resource associated with the signer's user resource, as identified in operation 606. In another example, the cryptographic key resource can include an identifier that can be used to access the public key in a key vault or other data store. Move to operation 610, where the public key can be used to verify the signature of the signed resource. In some examples, at least one of various indicators (e.g., visual, auditory, electronic, etc.) can be used to indicate the result of the verification. In one example, options (e.g., an option to continue even if the verification fails or is incomplete, an option to ignore the signed resource, etc.) can be presented in response to the result of the verification. The process terminates at operation 610.

[0070] Figure 7 An overview of an example method 700 for encrypting a resource within an isolated set is shown. In the example, a resource (e.g., Figure 4 the encrypted resource 434 in) can be encrypted by a sender such as Person 2 416 and received by a receiver such as Person l 402. Method 700 begins at operation 702, where the private key of the sender can be accessed. In some examples, the private key of the sender can be accessed from the isolated set (e.g., the same isolated set that stores the resource to be encrypted), where access to the private key is restricted. In other examples, the private key can be stored elsewhere, such as in a private data store or an encrypted hardware device, etc. In another example, the private key may not be accessed directly, and instead the resource can be provided to another component for signing (e.g., a key vault or an encrypted hardware device, etc.).

[0071] At operation 704, the private key of the sender can be used to sign the resource. Signing the resource can include storing or associating additional information with the resource related to the cryptographic signature (e.g., as metadata, attributes, etc.). In some examples, one or more relationships can be formed between the resource and the user resources associated with the sender. Moving to operation 706, the public key associated with the recipient can be identified within the isolated set. Identifying the public key can include accessing the user resources associated with the recipient to evaluate one or more relationships of the user resources. In some examples, the user resources can have one or more "key" relationships (or similar associations) with resources including a key vault, cryptographic keys, or cryptographic key identifiers. In another example, there can be multiple relationships or keys, and identifying the public key can include evaluating multiple cryptographic keys based on, for example, the type of data to be encrypted, the identity of the sender or recipient, the relationship between the sender and recipient, etc.

[0072] At operation 708, the public key identified in operation 706 can be accessed from the isolated set. Accessing the public key can include retrieving the public key from a cryptographic key resource associated with the recipient's user resources, as identified in operation 706. In another example, the cryptographic key resource can include an identifier that can be used to access the public key in a key vault or other data store.

[0073] At operation 710, the public key of the recipient accessed in operation 708 can be used to encrypt the resource. Encrypting the resource can include embedding or associating metadata or attributes that may assist in determining the cryptographic key when decrypting the resource. Moving to operation 712, the encrypted resource can be provided to the recipient. Providing the resource can include storing the resource in the isolated set and generating one or more relationships between the encrypted resource and other resources in the isolated set. As an example, relationships can be generated between the encrypted resource and the sender and between the encrypted resource and the recipient. The recipient can receive an indication that the resource is available in the isolated set. In another example, the encrypted resource or a resource identifier associated with the encrypted resource can be provided to the recipient. The process terminates at operation 712.

[0074] Figure 8An overview of an example method 800 for encrypted group communication among participants within an isolated set is shown. As an example, a conversation stored by an isolated set 500 as shown in FIG. 5 can be created by performing operations similar to method 800. Method 800 begins at operation 802, where a cryptographic key can be generated. As described above, the cryptographic key can be an asymmetric key pair or a symmetric key, among others. The cryptographic key can be generated when initiating a conversation session. In some examples, the cryptographic key can be generated during an ongoing conversation session (e.g., in response to an event) to rotate the cryptographic key used for the conversation session. In one example, an identifier associated with the cryptographic key can be stored in the isolated set such that a relationship can be formed between it and a message encrypted using the cryptographic key. This can provide an indication to the participants regarding the cryptographic key required to decrypt messages sent during the conversation session.

[0075] Moving to operation 804, the cryptographic key generated in operation 802 can be encrypted for each participant using the public key of each participant. In some examples, for each participant, identifying the public key can include accessing user resources associated with the participant to evaluate one or more relationships of the user resources. The user resources can have one or more "key" relationships (or similar associations) with resources including a key vault, a cryptographic key, or a cryptographic key identifier. In another example, there can be multiple relationships or keys, and identifying the public key can include evaluating multiple keys based on, for example, the type of data to be encrypted, the identity of the sender or receiver, or the relationship between the sender and the receiver, among others. Then, the determined public key of each participant can be used to encrypt the cryptographic key for each participant.

[0076] At operation 806, the encrypted cryptographic key can be provided to each participant. Providing the cryptographic key can include storing each cryptographic key in a key vault associated with the participant. In one example, an indication for indicating the location of the cryptographic key can be provided to each participant. In another example, the cryptographic key can be sent to each participant. Those skilled in the art will appreciate that any method of delivering the cryptographic key can be used without departing from the spirit of the present disclosure.

[0077] Moving to operation 808, a message can be received from a participant. The message can include any type of data, including but not limited to text data, image or video data, audio data, or any combination thereof. The message can be received from a computing device of the participant (e.g., a mobile computing device, a tablet computing device, a personal computing device, etc.). In some examples, the message can be received from Figure 1 client devices 102A-C in

[0078] At operation 810, the encrypted password key of the participant can be decrypted using the participant's private key. In some examples, the private key can be stored in a key vault, in an isolated set, or using an encrypted hardware device among others. Similarly, the encrypted password key can be stored in a key vault, in an isolated set, etc. The password key and the private key can be stored in similar or different locations. In some examples, the decrypted password key can be cached so that it does not need to be continuously decrypted during the conversation session.

[0079] Moving to operation 812, the decrypted password key can be used to encrypt a message. In some examples, the message can be signed before or after performing the encryption operation. The private key of the participant can be used to sign the message so that other session participants can use the public key associated with the private key to verify the signature, which can be associated with the user resources associated with the participant.

[0080] At operation 814, the encrypted message can be provided to the session participants. Providing the encrypted message can include storing the message (e.g., as a resource in an isolated set) or a reference to the message (e.g., as a resource including a resource identifier in an isolated set). A relationship can be formed between the message and the key identifier of the password key within the isolated set. In one example, a participant can receive an indication that a new message is available in the isolated set, or the participant can periodically poll the isolated set to determine if there is a new message. In another example, the encrypted message can be sent to the conversation participants. As the session participants continue to communicate with each other, the process can loop through operations 808 - 814 during the conversation session. In some examples, session participants can be added to the session, as discussed in more detail below with reference to Figure 9 discussed in more detail.

[0081] Figure 9 An overview of an example method 900 for a new participant to obtain access to a group conversation session is shown. Method 900 begins at operation 902, where a request for access to the group session can be received. The request can be received from a computing device (e.g., a mobile computing device, a tablet computing device, a personal computing device, etc.) of a potential participant requesting access to the conversation. In some examples, the message can be received from Figure 1 client devices 102A - C in

[0082] At operation 904, the current participants of the conversation session can be determined. The determination can be made based on the relationships that exist between the messages of the conversation and one or more user resources (e.g., a "sender" or "recipient" relationship can exist between the messages stored within an isolated set and the user resources). In one example, a participant list or other data structure can be associated with the conversation such that it can be evaluated to determine the conversation participants. In another example, a relationship can exist between the key identifier associated with the cryptographic key used to encrypt the conversation session and the user resources associated with the conversation participants. As a result, the relationship of the key identifier can be evaluated to determine one or more user resources associated with the conversation participants.

[0083] Moving to operation 906, an authorization request can be sent to one or more of the determined conversation participants. The authorization request can include various information, including but not limited to the context surrounding the session, identity information about the requester, or information about the current list of session participants. The participant can authorize or deny the request. In some examples, the participant can provide an earlier indication that can be used when responding to the authorization request. As an example, the participant can specify that these requests should be automatically accepted, denied, or ignored among others. In another example, the participant can create one or more rules that can be evaluated when responding to the authorization request.

[0084] At operation 908, authorization can be received from the participant. The authorization can include an indication to add the requester to the conversation. In one example, the indication can include one or more requirements regarding how the cryptographic key associated with the session must be stored (e.g., the encryption strength or encryption algorithm that must be used among others).

[0085] Moving to operation 910, the private key of the participant can be used to decrypt the cryptographic key associated with the conversation. In some examples, the participant may have provided the decrypted cryptographic key when providing the authorization indication. In another example, the private key of the participant can be retrieved from a location indicated by the participant (such as a key vault or data store etc.). In one example, the cryptographic key can be provided to another component (e.g., a key vault, an encryption hardware device etc.) which can use the private key of the participant to provide the decrypted cryptographic key as a response.

[0086] At operation 912, the decryption password key can be encrypted using the requester's public key. Encrypting the key using the requester's public key can include identifying the public key by accessing user resources associated with the requester to evaluate one or more relationships of the user resources. In some examples, the user resources can have one or more "key" relationships (or similar associations) with resources including a key vault, a password key, or a password key identifier. In another example, there can be multiple relationships or keys, and identifying the public key can include evaluating multiple password keys based on, for example, the type of data to be encrypted, the identity of the requester, requirements provided by other session participants or authorized participants, and others.

[0087] Moving to operation 914, the password key can be provided to the requester. Providing the password key can include storing the password key in a key vault associated with the requester. In one example, an indication of the location of the password key can be provided to the requester. In another example, the password key can be sent to the requester. The requester can then use the password key to access and participate in a group session (e.g., by performing Figure 8 the operations 808 - 814 therein). The process terminates at operation 914.

[0088] Figures 10 - 13 and the associated description provide a discussion of various operating environments in which aspects of the present disclosure can be practiced. However, the devices and systems shown and discussed are for purposes of example and illustration and do not limit the numerous computing device configurations that can be used to practice aspects of the present disclosure described herein. Figures 10 - 13 The devices and systems shown and discussed are for purposes of example and illustration and do not limit the numerous computing device configurations that can be used to practice aspects of the present disclosure described herein.

[0089] Figure 10 is a block diagram showing the physical components (e.g., hardware) of a computing device 1000 that can be used to practice aspects of the present invention. The computing device components described below can be applicable to the above computing devices, including client computing devices 102A - C and server computing devices 106A - C. In a basic configuration, the computing device 1000 can include at least one processing unit 1002 and a system memory 1004. Depending on the configuration and type of the computing device, the system memory 1004 can include, but is not limited to, volatile memory (e.g., random access memory), non - volatile memory (e.g., read - only memory), flash memory, or any combination of these memories. The system memory 1004 can include an operating system 1005 and one or more program modules 1006 suitable for performing various aspects disclosed herein, such as a password key identification component 1024 and an automatic encryption operation component 1026. For example, the operating system 1005 can control the operation of the computing device 1000. Additionally, embodiments of the present disclosure can be practiced in conjunction with a graphics library, other operating systems, or any other application, and are not limited to any particular application or system. This basic configuration is shown in Figure 10are illustrated by those components within dashed line 1008. Computing device 1000 may have additional features or functionality. For example, computing device 1000 may also include additional data storage devices (removable and / or non-removable), such as magnetic disks, optical disks, or magnetic tapes. Such additional storage is Figure 10 illustrated by removable storage device 1009 and non-removable storage device 1010.

[0090] As described above, multiple program modules and data files may be stored in system memory 1004. When executed on processing unit 1002, program modules 1006 (e.g., applications 1020) may perform the following processing, including but not limited to these aspects as described herein. Other program modules that may be used in accordance with aspects of the present disclosure may include email and contact applications, word processing applications, spreadsheet applications, database applications, slide presentation applications, drawing or computer-aided application programs, and the like.

[0091] In addition, embodiments of the present disclosure may be implemented in circuitry including: discrete electronic components, a packaged or integrated electronic chip containing logic gates, circuitry utilizing a microprocessor, or a single chip containing electronic components or a microprocessor. For example, embodiments of the present disclosure may be practiced via a system-on-chip (SOC), where Figure 10 each or many of the components illustrated therein may be integrated onto a single integrated circuit. Such SOC devices may include one or more processing units, graphics units, communication units, system virtualization units, and various application functions, all of which are integrated (or "burned") onto a chip substrate as a single integrated circuit. When operating via an SOC, the functions regarding the capabilities of the client switching protocol described herein may be operated via dedicated logic integrated with other components of computing device 1000 on a single integrated circuit (chip). Embodiments of the present disclosure may also be practiced using other technologies capable of performing logical operations such as, for example, AND, OR, and NOT, and such other technologies include but are not limited to mechanical, optical, fluidic, and quantum technologies. In addition, embodiments of the present disclosure may be implemented in a general-purpose computer or any other circuitry or system.

[0092] Computing device 1000 may also have one or more input devices 1012, such as a keyboard, mouse, pen, voice or speech input device, touch or swipe input device, etc. Output devices 1014 such as a display, speaker, printer, etc. may also be included. The above devices are examples, and other devices may be used. Computing device 1000 may include one or more communication connections 1016 that allow communication with other computing devices 1050. Examples of suitable communication connections 1016 include but are not limited to radio frequency (RF) transmitter, receiver, and / or transceiver circuitry; universal serial bus (USB), parallel, and / or serial ports.

[0093] As used herein, the term computer-readable medium may include computer storage media. Computer storage media can include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information such as computer-readable instructions, data structures, or program modules. System memory 1004, removable storage device 1009, and non-removable storage device 1010 are all examples of computer storage media (e.g., memory storage). Computer storage media can include RAM, ROM, electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile disk (DVD) or other optical storage devices, magnetic tape cassettes, magnetic tape, disk storage or other magnetic storage devices, or any other article that can be used to store information and can be accessed by computing device 1000. Any such computer storage media can be part of computing device 1000. Computer storage media does not include carrier waves or other propagated or modulated data signals.

[0094] Communication media can 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 transmission mechanism, and includes any information delivery media. The term "modulated data signal" can describe a signal having one or more 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), infrared, and other wireless media.

[0095] Figure 11A and Figure 11B FIG. shows a mobile computing device 1100, e.g., a mobile phone, a smart phone, a wearable computer (such as a smart watch), a tablet computer, a laptop computer, etc., by means of which embodiments of the present disclosure can be implemented. In some aspects, the client can be a mobile computing device. Refer to Figure 11A, which shows one aspect of the mobile computing device 1100 for implementing these aspects. In a basic configuration, the mobile computing device 1100 is a handheld computer with input and output elements. The mobile computing device 1100 typically includes a display 1105 and one or more input buttons 1110 that allow a user to input information into the mobile computing device 1100. The display 1105 of the mobile computing device 1100 can also be used as an input device (e.g., a touchscreen display). If included, the optional side input element 1115 allows for further user input. The side input element 1115 can be a rotary switch, a button, or any other type of manual input element. In alternative aspects, the mobile computing device 1100 can include more or fewer input elements. For example, in some embodiments, the display 1105 may not be a touchscreen. In yet another alternative embodiment, the mobile computing device 1100 is a portable telephone system, such as a cellular phone. The mobile computing device 1100 can also include an optional keypad 1135. The optional keypad 1135 can be a physical keypad or a "soft" keypad generated on a touchscreen display. In various embodiments, the output elements include a display 1105 for presenting a graphical user interface (GUI), visual indicators 1120 (e.g., light-emitting diodes), and / or audio transducers 1125 (e.g., speakers). In some aspects, the mobile computing device 1100 includes a vibration transducer for providing haptic feedback to the user. In yet another aspect, the mobile computing device 1100 includes input and / or output ports, such as an audio input (e.g., a microphone jack), an audio output (e.g., a headphone jack), and a video output (e.g., a UDMI port), for sending signals to or receiving signals from external devices.

[0096] Figure 11B is a block diagram showing the architecture of one aspect of a mobile computing device. That is, the mobile computing device 1100 can incorporate a system (e.g., an architecture) 1102 to implement certain aspects. In one embodiment, the system 1102 is implemented as a "smartphone" capable of running one or more applications (e.g., a browser, email, calendar, contact manager, messaging client, game, and media client / player). In some aspects, the system 1102 is integrated as a computing device, such as an integrated personal digital assistant (PDA) and wireless phone.

[0097] One or more applications 1166 can be loaded into the memory 1162 and run on or associated with the operating system 1164. Example programs of applications include a telephone dialer program, an e-mail program, a personal information management (PIM) program, a word processing program, a spreadsheet program, an Internet browser program, a messaging program, and the like. The system 1102 also includes a non-volatile storage area 1168 within the memory 1162. The non-volatile storage area 1168 can be used to store persistent information that should not be lost if the system 1102 loses power. The applications 1166 can use and store information in the non-volatile storage area 1168, such as e-mail or other messages used by an e-mail application. A synchronization application (not shown) also resides on the system 1102 and is programmed to interact with a corresponding synchronization application residing on a host computer to keep the information stored in the non-volatile storage area 1168 synchronized with the corresponding information stored in the host computer. It should be appreciated that other applications can be loaded into the memory 1162 and run on the mobile computing device 1100 described herein (e.g., a search engine, an extractor module, a relevance ranking module, an answer scoring module, etc.).

[0098] The system 1102 has a power supply 1170, which can be implemented as one or more batteries. The power supply 1170 can also include an external power supply, such as an AC adapter or a power docking cradle, which supplements or recharges the battery.

[0099] The system 1102 can also include a radio interface layer 1152 that performs the functions of sending and receiving radio frequency communications. The radio interface layer 1152 facilitates a wireless connection between the system 1102 and the "outside world" via a communication carrier or service provider. Transmissions to and from the radio interface layer 1152 are controlled by the operating system 1164. In other words, communications received by the radio interface layer 1152 can be propagated to the applications 1166 via the operating system 1164, and vice versa.

[0100] The visual indicator 1120 can be used to provide visual notifications, and / or the audio interface 1154 can be used to generate audible notifications via the audio transducer 1125. In the illustrated embodiment, the visual indicator 1120 is a light-emitting diode (LED) and the audio transducer 1125 is a speaker. These devices can be directly coupled to the power supply 1170 such that when activated, they remain on for a duration indicated by the notification mechanism even if the processor 1160 and other components may be turned off to conserve battery power. The LED can be programmed to remain on indefinitely until the user takes an action to indicate the powered-on state of the device. The audio interface 1154 is used to provide audible signals to the user and receive audible signals from the user. For example, in addition to being coupled to the audio transducer 1125, the audio interface 1154 can also be coupled to a microphone to receive audible input, for example to facilitate a telephone conversation. According to an embodiment of the present disclosure, the microphone can also be used as an audio sensor to facilitate control of notifications, as described below. The system 1102 can also include a video interface 1156, which enables operation of the on-vehicle camera 1130 to record still images, video streams, etc.

[0101] The mobile computing device 1100 implementing the system 1102 can have additional features or functionality. For example, the mobile computing device 1100 can also include additional data storage devices (removable and / or non-removable), such as magnetic disks, optical disks, or magnetic tapes. Such additional storage is Figure 11B illustrated by the non-volatile storage area 1168.

[0102] As described above, data / information generated or captured by the mobile computing device 1100 and stored via the system 1102 can be stored locally on the mobile computing device 1100, or the data can be stored on any number of storage media that can be accessed by the device via the radio interface layer 1152 or via a wired connection between the mobile computing device 1100 and a separate computing device associated with the mobile computing device 1100, the separate computing device being, for example, a server computer in a distributed computing network, the distributed computing network being, for example, the Internet. It should be appreciated that such data / information can be accessed via the radio interface layer 1152 or via the distributed computing network via the mobile computing device 1100. Similarly, such data / information can be easily transmitted between computing devices for storage and use according to well-known data / information transfer and storage means, including email and collaborative data / information sharing systems.

[0103] Figure 12FIG. 0 illustrates one aspect of an architecture of a system for processing data received at a computing system from a remote source (e.g., a personal computer 1204, a tablet computing device 1206, or a mobile computing device 1208), as described above. Content displayed at the server device 1202 may be stored in different communication channels or other storage types. For example, a directory service 1222, a network port 1224, a mailbox service 1226, an instant message store 1228, or a social networking site 1230 may be used to store various documents. An automatic encryption operation component 1221 may be used by a client communicating with the server device 1202, and / or a cryptographic key identification component 1220 may be used by the server device 1202. The server device 1202 may provide data to and from client computing devices such as a personal computer 1204, a tablet computing device 1206, and / or a mobile computing device 1208 (e.g., a smart phone) via the network 1215. By way of example, the computer system described above may be embodied in a personal computer 1204, a tablet computing device 1206, and / or a mobile computing device 1208 (e.g., a smart phone). In addition to receiving graphical data that may be used for preprocessing at a graphics initiation system or postprocessing at a receiving computing system, any of these embodiments of the computing device may obtain content from the storage 1216.

[0104] Figure 13 FIG. 4 illustrates an exemplary tablet computing device 1300 that may perform one or more aspects disclosed herein. Additionally, the aspects and functions described herein may operate on a distributed system (e.g., a cloud-based computing system), where application functions, memory, data storage and retrieval, and various processing functions may operate remotely from each other via a distributed computing network (e.g., the Internet or an intranet). A user interface and various types of information may be displayed via an in-vehicle computing device display or via a remote display unit associated with one or more computing devices. For example, various types of user interfaces and information may be displayed and interacted with on a wall surface onto which the user interface and various types of information are projected. Interaction with the multiple computing systems that may practice embodiments of the present invention includes keystroke input, touchscreen input, voice or other audio input, gesture input, where the associated computing device is equipped with detection (e.g., a camera) functionality for capturing and interpreting user gestures for controlling the functions of the computing device, etc.

[0105] As can be understood from the foregoing disclosure, one aspect of the present technology relates to a system, comprising: at least one processor; and a memory storing instructions that, when executed by the at least one processor, perform a set of operations. The operations include accessing resources stored by an isolated set; identifying user resources in the isolated set based on one or more relationships of the resources, wherein the user resources are related to the resources; identifying cryptographic key resources in the isolated set based on one or more relationships of the user resources, wherein the cryptographic key resources are associated with the user resources; accessing a cryptographic key based on the cryptographic key resources; and performing a cryptographic operation on the resources using the cryptographic key. In an example, the cryptographic operation is one of the following: encrypting resources for a user associated with the determined user resources; and verifying a cryptographic signature of the resources, wherein the resources are cryptographically signed by a user associated with the determined user resources. In another example, the identified cryptographic key resources are a key vault for storing cryptographic keys associated with the user resources, and accessing the cryptographic key includes accessing the cryptographic key in the key vault. In another example, the identified cryptographic key resources include a key identifier, and accessing the cryptographic key includes evaluating the key identifier to determine the location of the cryptographic key. In yet another example, verifying the cryptographic signature of the resources further includes: providing an indication when it is determined that the cryptographic signature cannot be verified, wherein the indication is at least one of a notification, a visual indication, and an audible indication; and providing an indication when it is determined that the cryptographic signature can be verified, wherein the indication is at least one of a notification, a visual indication, and an audible indication. In yet another example, the resources are one of the following: a document; information related to a file; a conversation; and a message. In another example, the cryptographic key is the public key of a cryptographic key pair, and the private key of the cryptographic key pair is not stored in the key vault.

[0106] In another aspect, the technology relates to a computer-implemented method. The method includes: generating a cryptographic key for use by a plurality of computing devices during a conversation session; for each of the plurality of computing devices, encrypting the cryptographic key using the public key associated with the computing device and providing the encrypted cryptographic key to the computing device; receiving a message of the conversation session from the computing device; generating an encrypted message of the message using the cryptographic key; storing the encrypted message in an isolated set, wherein the encrypted message is associated with the cryptographic key; and providing an indication of the encrypted message to one or more of the plurality of computing devices. In an example, the method further includes: receiving a request from a new computing device for access to the conversation session; sending an authorization request to at least one of the plurality of computing devices; receiving authorization from at least one of the plurality of computing devices; based on the received authorization: accessing the encrypted cryptographic key associated with at least one computing device; generating an unencrypted cryptographic key from the encrypted cryptographic key based on the private key associated with at least one computing device; generating a re-encrypted cryptographic key from the unencrypted cryptographic key based on the public key associated with the new computing device; and providing the re-encrypted cryptographic key to the new computing device. In another example, generating the encrypted message further includes: signing the message using the private key associated with the computing device. In another example, the cryptographic key is stored in escrow by a trusted third party. In yet another example, sending the authorization request to at least one of the plurality of computing devices further includes: identifying at least one of the plurality of computing devices based on one or more relationships of the encrypted messages in the isolated set. The computing device. In another example, the received authorization includes information that can be used when generating the unencrypted cryptographic key.

[0107] In another aspect, the technology relates to another computer-implemented method for providing an encrypted conversation session. The method includes: accessing a resource stored by an isolated set; identifying a user resource in the isolated set based on one or more relationships of the resource, wherein the user resource is related to the resource; identifying a cryptographic key resource in the isolated set based on one or more relationships of the user resource, wherein the cryptographic key resource is associated with the user resource; accessing a cryptographic key based on the cryptographic key resource; and performing an encryption operation on the resource using the cryptographic key. In an example, the encryption operation is one of the following: encrypting a resource for a user associated with the determined user resource; and verifying a cryptographic signature of the resource, wherein the resource is cryptographically signed by a user associated with the determined user resource. In another example, the identified cryptographic key resource is a key vault for storing a cryptographic key associated with the user resource, and accessing the cryptographic key includes accessing the cryptographic key in the key vault. In another example, the identified cryptographic key resource includes a key identifier, and accessing the cryptographic key includes evaluating the key identifier to determine the location of the cryptographic key. In yet another example, verifying the cryptographic signature of the resource further includes: providing an indication when it is determined that the cryptographic signature cannot be verified, wherein the indication is at least one of a notification, a visual indication, and an audible indication; providing an indication when it is determined that the cryptographic signature can be verified, wherein the indication is at least one of a notification, a visual indication, and an audible indication. In yet another example, the resource is one of the following: a document; information related to the document; a conversation; and information. In another example, the cryptographic key is a public key of a cryptographic key pair, and the private key of the cryptographic key pair is not stored in the key vault.

[0108] For example, the above has described aspects of the present disclosure with reference to block diagrams and / or operational illustrations of methods, systems, and computer program products according to aspects of the present disclosure. The functions / actions labeled in the blocks may not occur in any order of any flowchart shown. For example, two consecutive blocks shown may actually be executed substantially simultaneously, or the blocks may sometimes be executed in the reverse order, depending on the functions / actions involved.

[0109] The description and illustration of one or more aspects provided in this application are not intended to limit or restrict the scope of the present disclosure in any way. The aspects, examples, and details provided in this application are considered sufficient to convey possession and enable others to make and use the best mode of the claimed invention. The claimed disclosure should not be construed as limited to any aspect, example, or detail provided in this application. Whether shown and described combinatorially or individually, various features (structures and methods) are intended to be selectively included or omitted to produce embodiments having a specific set of features. Having provided the description and illustration of this application, those skilled in the art can envision variations, modifications, and alternative aspects that fall within the spirit of the broader aspects of the general inventive concept embodied in this application, which do not depart from the broader scope of the claimed disclosure of this application.

Claims

1. A system for performing cryptographic operations, comprising: At least one processor; And A memory storing instructions which, when executed by the at least one processor, implement a set of operations including: Accessing resources with which a user interacts from an isolated set, the isolated set including the resources, user resources, and cryptographic key resources; Identifying the user resources based on one or more relationships of the resources; Identifying the cryptographic key resources based on one or more relationships of the user resources; Accessing a cryptographic key based on the cryptographic key resources; and Using the cryptographic key to perform a cryptographic operation on the resources.

2. The system according to claim 1, wherein, The cryptographic operation is one of the following: Encrypting the resources for a user associated with the user resources; or Verifying a cryptographic signature of the resources, wherein the resources are cryptographically signed by the user associated with the user resources.

3. The system according to claim 2, wherein Verifying the cryptographic signature of the resources further includes: When determining that the cryptographic signature cannot be verified, providing an indication, wherein the indication is at least one of the following: a notification, a visual indication, and an audible indication; and When determining that the cryptographic signature can be verified, providing an indication, wherein the indication is at least one of the following: a notification, a visual indication, and an audible indication.

4. The system according to claim 1, wherein, The identified cryptographic key resources include a key identifier, and accessing the cryptographic key includes evaluating the key identifier to determine the location of the cryptographic key.

5. The system according to claim 1, wherein, The resources are one of the following: A document; Information related to the document; A conversation; and A message.

6. A computer-implemented method for providing an encrypted conversation session, the method comprising: Accessing resources with which a user interacts from an isolated set, the isolated set including the resources, user resources, and cryptographic key resources; Identifying the user resources based on one or more relationships of the resources; Identifying the cryptographic key resources based on one or more relationships of the user resources; Accessing a cryptographic key based on the cryptographic key resources; And Using the cryptographic key to perform a cryptographic operation on the resources.

7. The computer-implemented method according to claim 6, wherein, The identified cryptographic key resources are a key repository for storing cryptographic keys associated with the user resources, and accessing the cryptographic key includes accessing the cryptographic key in the key repository.

8. The computer-implemented method according to claim 6, wherein, The identified cryptographic key resources include a key identifier, and accessing the cryptographic key includes evaluating the key identifier to determine the location of the cryptographic key.

9. The computer-implemented method according to claim 7, wherein, The cryptographic key is the public key of a cryptographic key pair, and the private key of the cryptographic key pair is not stored in the key repository.

10. The computer-implemented method according to claim 6, further comprising: Generating a cryptographic key for use by multiple computing devices during a conversation session; For each of the multiple computing devices, encrypting the cryptographic key using the public key associated with the computing device and providing the encrypted cryptographic key to the computing device; Receiving a message of the conversation session from a computing device; Using the cryptographic key to generate an encrypted message of the message; Store the encrypted message in an isolated set, wherein the encrypted message is associated with the cryptographic key through the relationship between the encrypted message and the cryptographic key resource; And Provide an indication of the encrypted message to one or more of the plurality of computing devices.

11. The computer-implemented method according to claim 10, further comprising: Receiving a request from a new computing device to access the conversation session; Sending an authorization request to at least one of the plurality of computing devices; Receiving authorization from at least one of the plurality of computing devices; Based on the received authorization: Access the encrypted cryptographic key associated with the at least one computing device; Generate an unencrypted cryptographic key from the encrypted cryptographic key based on the private key associated with the at least one computing device; Generate a re-encrypted cryptographic key from the unencrypted cryptographic key based on the public key associated with the new computing device; And Provide the re-encrypted cryptographic key to the new computing device.

12. The computer-implemented method according to claim 10, wherein, Generating the encrypted message further comprises: Signing the message using the private key associated with the computing device.

13. The computer-implemented method according to claim 11, wherein, Sending the authorization request to at least one of the plurality of computing devices further comprises: Identifying at least one of the plurality of computing devices based on one or more relationships of the encrypted messages in the isolated set.

14. The computer-implemented method according to claim 10, wherein, The cryptographic key is stored in escrow by a trusted third party.

15. The computer-implemented method according to claim 11, wherein, The received authorization includes information that can be used when generating the unencrypted cryptographic key.

Images