WO2021225570A1

WO2021225570A1 - Regulating authentication tokens

Info

Publication number: WO2021225570A1
Application number: PCT/US2020/031287
Authority: WO
Inventors: Thalia May LAING; Joshua Serratelli SCHIFFMAN; Gaetan WATTIAU; Mark Ryan; Eduard MARIN
Original assignee: Hewlett-Packard Development Company, L.P.
Priority date: 2020-05-04
Filing date: 2020-05-04
Publication date: 2021-11-11

Abstract

In some examples, a method of regulating use of an authentication token comprises, in response to a request to access the authentication token, distributing a challenge to a set of nodes logically encoding a set of policy domain layers, each policy domain layer in the set of policy domain layers associated to a different cryptographically enforced logical operation, and generating a response to the challenge, the response comprising data from the set of nodes indicating possession of the authentication token, wherein the response is constructed from multiple partial shares of the authentication token obtained on the basis of the cryptographically enforced logical operations performed over predetermined threshold numbers of nodes in each of the set of the layers.

Description

REGULATING AUTHENTICATION TOKENS BACKGROUND Authentication is a process that verifies the claimed identity of an entity, such as a device or user. Once a system has verified an identity, access to services or data can be granted. Authentication systems use authentication factors to determine an identity. An authentication factor may be, e.g., something that is known, possessed, or an attribute. An authentication factor can depend on possession of devices, such as phones or laptops for example. In some cases, multiple devices can be used for authentication. BRIEF DESCRIPTION OF THE DRAWINGS For a more complete understanding of the present disclosure, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which: Figure 1 is a schematic representations of access structure; Figure 2 is a schematic representations of access structure; Figure 3 is a schematic representation of cryptographic access structure according to an example; Figure 4 is a schematic representation of cryptographic access structure according to an example; Figure 5 is a schematic representation of a cryptographic access structure according to an example; Figure 6 is a schematic representation of a method according to an example; and Figure 7 is a schematic representation of a processor associated with a memory according to an example. DESCRIPTION Example embodiments are described below in sufficient detail to enable those of ordinary skill in the art to embody and implement the systems and processes herein described. It is important to understand that embodiments can be provided in many alternate forms and should not be construed as limited to the examples set forth herein. Accordingly, while embodiments can be modified in various ways and take on various alternative forms, specific embodiments thereof are shown in the drawings and described in detail below as examples. There is no intent to limit to the particular forms disclosed. On the contrary, all modifications, equivalents, and alternatives falling within the scope of the appended claims should be included. Elements of the example embodiments are consistently denoted by the same reference numerals throughout the drawings and detailed description where appropriate. The terminology used herein to describe embodiments is not intended to limit the scope. The articles “a,” “an,” and “the” are singular in that they have a single referent, however the use of the singular form in the present document should not preclude the presence of more than one referent. In other words, elements referred to in the singular can number one or more, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises,” “comprising,” “includes,” and/or “including,” when used herein, specify the presence of stated features, items, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, items, steps, operations, elements, components, and/or groups thereof. Unless otherwise defined, all terms (including technical and scientific terms) used herein are to be interpreted as is customary in the art. It will be further understood that terms in common usage should also be interpreted as is customary in the relevant art and not in an idealized or overly formal sense unless expressly so defined herein. Authentication is used to establish the identity of an entity. Authentication is used in a variety of contexts such as to allow a user to gain access to services or data. Users can authenticate themselves to a local device or a server remote from the user over a network for example. To authenticate, a user can be asked to present an authentication factor. An authentication factor may be ‘something you are’, ‘something you know’, or ‘something you have’. For example, a user may be authenticated if they can demonstrate possession of an identification card. In another case, a user may be authenticated if they know a password. Due to the weaknesses of passwords, many authentication schemes rely on the user having access to a device. This is an improvement over a password as the device, unlike a human, can store a cryptographically secure password and can use public key cryptography. When the user wants to authenticate, an authenticating party, also referred to as a relying party, can send the device a challenge. The challenge is signed by the device using a private key corresponding to a previously enrolled public key. A valid signature shows the relying party that someone with access to the device wants to authenticate i.e., that the user is in possession of the device. The relying party does not learn the private key and so cannot leak information about the key if compromised at a later date. In particular, possession of the authentication factor can be demonstrated without revealing secure information relating to the authentication factor. Authentication systems which rely on a user having a device have several security and usability flaws. For example, if an attacker steals the device, the attacker can impersonate the user using the authentication factor on the device. If the authentication device is lost, there may be no secure method for the user to recover access to their account. If the device is physically attacked or the software is compromised the device may wrongly or falsely authenticate or leak information. If the user does not have access to the single device momentarily, they may be locked out of their account until they can regain access. Finally, by using a single device to authenticate, the user is relying on the availability and trustworthiness of the single device. In some authentication procedures, an authentication factor is distributed across multiple devices. When the user is asked to authenticate themselves, they demonstrate possession of a subset of devices across which the authentication factor is distributed. If the combined information from the subset of devices is sufficient to demonstrate possession of the authentication factor, then the user is authenticated. In these authentication systems, different subsets of devices may be presentable to demonstrate possession of the authentication factor. For example, in some systems if a user can present a threshold number of devices from a set of devices across which the authentication factor is distributed, then the user may be authenticated. Distributing an authentication factor across multiple devices increases security and usability of a system. In these systems, an adversary has to obtain a number of different devices to imitate the authorised user. If a device is lost, corrupted, or damaged, or is locked out to a user, they can still authenticate by presenting a different subset of devices in their possession when it is time to authenticate. However, such threshold access policies are flat and treat all shareholders as equals. A threshold signature scheme that allocates more than one share of a signing key to a single entity, thereby weighting the entity so it contributes, say, twice as much as some other entity is flexible, but an entity that has two shares can be replaced by two entities that each have one share. Furthermore, clear distinctions between different roles or capabilities are not provided. According to an example, there is provided a method for regulating the use of or access to an authentication factor (or token) that provides the flexibility of access policies such that the authentication token is constructed and/or accessed when a threshold number of different roles are satisfied. For example, access to an authentication token in the form of, e.g., a signature can be provided when: 1. Some set of t_a approvers out of a possible n_a approvers authorises the signature, and 2. Some set of t_s supervisors out of a possible n_s supervisors authorises the signature, and 3. A server authorises the signature. Or if some set satisfies some defined capabilities, such as: 1. Some set of t_a devices out of a possible n_a devices is required to collaborate, and 2. At least one of the t_a collaborating devices must have a certain hardware security feature. According to an example, a cryptographic access structure combines threshold signature schemes to create flexible access structures that can used to encode a range of policy domains representing capabilities and requirements of entities in a system. Such threshold signature schemes can be combined, and the combination can reflect different access structures and requirements on entities. In an example, a set of nodes (e.g. end user devices), can be used to logically encode a set of policy domain layers. That is, multiple nodes can form a set defining a policy domain. A node may lie in more than one such set. Each policy domain layer can be associated to a different cryptographically enforced logical operation. Accordingly, a set of nodes can logically define a policy domain layer in an access structure, which policy domain layer implements a selected cryptographically enforced logical operation. As such, different policy domain layers can be used to implement multiple different cryptographically enforced logical operations, and various combinations can be used to enforce compliance with policies before access to an authentication token is provided. For example, an access structure can be defined that embodies some combination of Boolean ‘and’ access structure nodes, and ‘threshold’ access structure nodes. In a Boolean ‘and’ access structure node, each entity represented by a node has to participate in order to produce a valid signature. For example, if there are two entities, A and B, both A and B are to participate in order to produce a signature. In a ‘threshold’ access structure node, any t of the n entities may participate. For example, if there are three entities, A, B, and C, and the threshold is t=2, then any two of the three entities may participate. Here, this can either be A and B, A and C, or B and C. Figures 1 and 2 are schematic representations of access structures. Figure 1 depicts an exemplary access structure formed using Boolean ‘and’ access structure nodes 101a-c, and Figure 2 depicts an exemplary access structure formed using threshold access structure nodes 201a-c. In the examples of figures 1 and 2, an authentication token ‘d’ (103, 203) is the source of multiple partial shares, d_n. A combination of the partial shares can be used to reconstruct the token (103, 203). In the example of figure 1, the nodes 101a-c encode a cryptographically enforced logical operation in the form of the Boolean ‘and’ operation that enables the token 103 to be constructed from the shares in the nodes 101a-c when all nodes participate – that is, when the partial shares from all nodes 101a-c are used in the reconstruction process. In the example of figure 2, the nodes 201a-c encode a cryptographically enforced logical operation in the form of a threshold operation that enables the token 203 to be constructed from the shares in the nodes 101a-c when a threshold number, t, of nodes participate – that is, when the partial shares from a threshold number of the nodes 201a-c are used in the reconstruction process. According to an example, in both ‘and’ and ‘threshold’ access structure structures, such as those depicted in figure 1 and 2, each node (101a-c; 201a-c) is either provided: - to a single entity, or - to every entity in a set, or - iteratively distributed according to another access structure node. Note that a set of entities refers to some grouping of entities in a system, which may be according to, for example, different roles, physical location or capabilities (or some mix). Each set of entities may not be distinct: i.e., some entity may be contained in two sets. Note also that an entity may refer to a person, a device, a system, or part of a device. According to an example, each node in an access structure defines a policy domain specifying how a share in the root node may be accessed or used by the descendent nodes based on the choice of ‘and’ or ‘threshold’ nodes. Combining different access structure nodes can therefore be used to cascade these requirements to sub-domains. Figure 3 is a schematic representation of cryptographic access structure according to an example. In the example of figure 3, the cryptographic access structure 300 comprises and is defined by multiple nodes that logically encode policy domain layers 301, 303. Each policy domain layer 301, 303 is associated to a different cryptographically enforced logical operation. That is, the nodes thus encode two cryptographically enforceable logical operations. A first set of nodes 301 encodes a first cryptographically enforceable logical operation in a first policy domain layer in the form of a Boolean ‘and’ operation performed over the nodes in the first set of nodes. A second set of nodes 303 encodes a second cryptographically enforceable logical operation in a second policy domain layer in the form of a threshold operation performed over the nodes in the second set of nodes. In the example of figure 3, the layer 303 forms a sub-domain of layer 301. Accordingly, fulfilment of the first cryptographically enforceable logical operation is itself dependent on fulfilment of the second cryptographically enforceable logical operation. Access to or use of the authentication token 305 is regulated by permitting reconstruction of the token 305 from the multiple shares (d_n in the first set of nodes, and d_n,m in the second set of nodes) when the logical operations encoded in the policy domain layers by the nodes are correctly fulfilled. That is to say, on the basis that participation in each of the layers is sufficient to satisfy the requirements of the logical operations. In the example of figure 3, this means that the logical operation of domain layer 301 is satisfied when all of the shares d_n the nodes are combined, which itself is dependent on t out of m shares from nodes in domain layer 303 being combined. In the example of figure 3, ‘t’ represents a predetermined threshold number of shares to be combined. In an example, the m shares in layer 303 are formed from the share d_n. Alternatively, the m shares in layer 303 can be formed from authentication token 305. That is, the authentication token can be used to provide n + m shares that are distributed according to, for example, the structure as depicted in figure 3. Figure 4 is a schematic representation of cryptographic access structure according to an example. In the example of figure 4, an alternative cryptographic access structure 400 comprises multiple nodes that logically encode policy domain layers 401, 403. As with the structure of figure 3, each policy domain layer 401, 403 is associated to a different cryptographically enforced logical operation. A first set of nodes 401 encodes a first cryptographically enforceable logical operation in a first policy domain layer in the form of a threshold operation performed over the nodes in the first set of nodes. A second set of nodes 403 encodes a second cryptographically enforceable logical operation in a second policy domain layer in the form of Boolean ‘and’ operations performed over the nodes in the second set of nodes. In the example of figure 4, the layer 403 forms a sub-domain of layer 401. As with the example of figure 3, fulfilment of the first cryptographically enforceable logical operation is itself dependent on fulfilment of the second cryptographically enforceable logical operation. Thus, access to or use of the authentication token 405 is regulated by permitting reconstruction of the token 405 from the multiple shares (d_n in the first set of nodes, and d_n,m in the second set of nodes) when the logical operations encoded in the policy domain layers by the nodes are correctly fulfilled. That is to say, on the basis that participation in each of the layers is sufficient to satisfy the requirements of the logical operations. In the example of figure 4, this means that the logical operation of domain layer 401 is satisfied when any t out of n shares are combined, which itself is contingent on all m of the shares d_n,m of the nodes in layer 403 being combined. Again, ‘t’ represents a predetermined threshold number of shares to be combined. In the example of figure 4, since layer 401 defines a threshold, it is possible that node d₁ does not form part of a valid operation. In this case, the token 405 may still be constructed from the other shares obtained from layer 401 providing the threshold number is reached. Accordingly, it may be the case that only when node d₁ is used as part of the threshold operation of layer 401 does layer 403 come into play. Alternatively, layer 401 may be formed as a hybrid in which a threshold number shares to include d₁ are to be used to construct the token 405. This can include the case where t is one for example. With reference to figures 3 and 4, two illustrative examples of access structures are described. In the first example, the entities are employees and servers, and each set of entities is distinct. In the second example, the entities are user owned devices and the sets of entities are intersecting. Firstly, consider a system where signed commands are sent to nodes that form endpoint devices, such as user equipment for example. In an example, an endpoint device will verify a signature on the command and execute the command if the signature is valid. The company sending the commands specifies that a command is to be sent when: 1. 3 out of 5 employees listed as having an ‘admin’ role authorise the command; AND 2. 2 out of 3 employees listed as having a ‘supervisor’ role authorise the command; AND 3. the server has recorded the command. With reference to figure 3, this corresponds to the situation in which n = 3 (according to three roles: employees as admins, employees as supervisors and a server), and: 4. d1 is distributed using a (3,5)-threshold scheme amongst employees listed as admins; 5. d2 is distributed using a (2,3)-threshold scheme amongst employees listed as supervisors; and 6. d3 is given to the server. In this example, each set of entities is likely to be unique and so each entity will store only one share. Next, consider a system where devices belonging to a user collectively authenticate them by signing a challenge sent from a relying party. The user has three devices, two of which can register user intent, which provides an indication that a user actually intends or wants to authenticate. The user wants to authenticate if: 1. 2 of their 3 devices are present; AND 2. 1 of their devices registers user intent. With reference to figure 3, this corresponds to the situation in which n = 2 (as there are two sets: user devices, and user devices that can register intent), and: 3. d1 is distributed using a (2,3)-threshold scheme amongst all the user devices; 4. d2 is given to each of the two devices that can register user intent. In this example, the set of user devices that can register intent is a subset of the set of user devices, and therefore some devices will receive two shares, as they are in two sets. Figure 5 is a schematic representation of a cryptographic access structure according to an example. In the example of figure 5, three logical policy domain layers (501, 503, 505) are encoded. The policy domain layers are iteratively combined in the form of 'and' (layers 501 and 505) and 'threshold' (layer 503) access structure nodes. Accordingly, access to or use of the authentication token 507 is regulated by permitting reconstruction of the token 507 from the multiple shares (d_n in the first set of nodes, d_n,m in the second set of nodes, and d_n,1,r in the third set of nodes) when the logical operations encoded in the policy domain layers encoded by the nodes are correctly fulfilled. That is to say, on the basis that participation in each of the layers is sufficient to satisfy the requirements of the logical operations. In the example of figure 5, this means that the logical operation of domain layer 501 is satisfied when all of the shares d_n the nodes are combined, which itself is dependent on t out of m shares from nodes in domain layer 503 being combined, which itself is dependent on all r of the shares d_n,1,r of the nodes in layer 505 being combined. As with the example of figure 4, similar considerations can apply in the case that node d_n,1 does not form part of the m shares. Cryptographic access structures as described herein can be used to enforce a multi-tiered authorization policy for, e.g., issuing security critical remote management commands to devices enrolled in a device as a service (DaaS) system. For example, a company using DaaS can assign an “approver” role to users to sign off on remote lock and erase commands. Examples as described herein enable the inclusion of additional roles such as a supervisor that may be obligatory for issuing the command. Thus, the supervisor and approver roles are two separate policy domains in the access structure for a single signing key. Further, cryptographic access structures as described herein can be used to enforce user consent on user devices in multi-device-based authentication schemes. For example, different capabilities of the devices participating in an authentication protocol can be encoded. Some devices may be trusted (or are capable) of registering a user’s intent to authenticate while others are not. This capability can be represented as a separate policy domain and those devices capable of consent can be given shares from that domain. Thus, desirable access policies can be enforced in systems without using management logic. This means there is no single point of failure that an attacker could target and try to manipulate so that the access policy is not enforced. Furthermore, the system is interoperable with existing verification processes. Thus, according to examples, there is provided a method of encoding and enforcing a differentiated access control policy over the issuance of a digital signature. A private key in a signature scheme can be secret shared into multiple shares associated with a policy domain. Each domain may represent different policy requirements for the use of the signing key and shareholders within the domain are expected to have different rights and duties. For example, domains may represent approvers, supervisors, privileged actors, or simply diversity of actors. Each policy domain is associated with logical properties (such as a context) and an additional hierarchical sub-access structure. This enables a policy author to construct a signature scheme whereby the policy of each domain must be satisfied for a valid signature to be produced. Moreover, each policy domain can have heterogeneous thresholds for satisfying that domain’s policy. The resulting signatures are interoperable with existing verification processes and only use a single public key. This enables the enforcement of more complex policies using a single key pair that would normally use multiple signing key pairs. This is especially useful for distributing shares in a threshold setting to shareholders with heterogeneous rights and privileges. As such, distributed digital signatures can be constructed if some pre-defined, flexible access policy is satisfied. In some examples, this is achieved by distributing the signing key amongst entities (or nodes) in the system, meaning the access policy is encoded and distributed in the shares of the signing key, and not in management logic. The digital signature produced is indistinguishable from a ‘traditional’ digital signature and thus the access policy will be transparent to the verifier. A wider range of access policies than those currently achievable can be defined, whilst maintaining the requirement that the single signature produced is fully interoperable with existing signature verification procedures. The methods and systems described herein may be implemented with monotonic access structures. Monotonic access structures are access structures with the property that any superset of the set satisfying the access structure satisfies the access structure. Threshold access structures are therefore an example of monotonic access structures. Figure 6 is a schematic representation of a method according to an example. More particularly, figure 6 is a flow chart 600 of method of regulating use of an authentication token according to an example. In block 601, in response to a request to access the authentication token, a challenge is distributed to a set of nodes logically encoding a set of policy domain layers. Each policy domain layer in the set of policy domain layers is associated to a different cryptographically enforced logical operation. In block 603, a response to the challenge is generated. The response can comprise data from the set of nodes indicating possession of the authentication token, and the response can be constructed from multiple partial shares of the authentication token obtained on the basis of the cryptographically enforced logical operations performed over predetermined threshold numbers of nodes in each of the set of the layers. Examples in the present disclosure can be provided as methods, systems or machine-readable instructions, such as any combination of software, hardware, firmware or the like. Such machine-readable instructions may be included on a computer readable storage medium (including but not limited to disc storage, CD-ROM, optical storage, etc.) having computer readable program codes therein or thereon. The present disclosure is described with reference to flow charts and/or block diagrams of the method, devices and systems according to examples of the present disclosure. Although the flow diagrams described above show a specific order of execution, the order of execution may differ from that which is depicted. Blocks described in relation to one flow chart may be combined with those of another flow chart. In some examples, some blocks of the flow diagrams may not be necessary and/or additional blocks may be added. It shall be understood that each flow and/or block in the flow charts and/or block diagrams, as well as combinations of the flows and/or diagrams in the flow charts and/or block diagrams can be realized by machine readable instructions. The machine-readable instructions may, for example, be executed by a general-purpose computer, a special purpose computer, an embedded processor or processors of other programmable data processing devices to realize the functions described in the description and diagrams. In particular, a processor or processing apparatus may execute the machine- readable instructions. Thus, modules of apparatus may be implemented by a processor executing machine-readable instructions stored in a memory, or a processor operating in accordance with instructions embedded in logic circuitry. The term 'processor' is to be interpreted broadly to include a CPU, processing unit, ASIC, logic unit, or programmable gate set etc. The methods and modules may all be performed by a single processor or divided amongst several processors. Such machine-readable instructions may also be stored in a computer readable storage that can guide the computer or other programmable data processing devices to operate in a specific mode. For example, the instructions may be provided on a non-transitory computer readable storage medium encoded with instructions, executable by a processor. Figure 7 is a schematic representation of a processor associated with a memory according to an example. In the example of figure 7, the memory 720 comprises computer readable instructions 730 which are executable by the processor 710. The instructions 730 can be used to regulate use of an authentication token, and can include instructions to generate a challenge for distribution to a set of devices that logically encode a set of policy domain layers, each policy domain layer in the set of policy domain layers associated to different cryptographically enforced logical operations, receive a response to the challenge comprising data representing multiple partial shares of the authentication token from devices in each of the policy domain layers, determine whether the received multiple partial shares correspond to predetermined threshold numbers of devices in each of the set of the layers, and on the basis that device participation in each of the layers is sufficient to satisfy the predetermined threshold numbers, construct the authentication token from the multiple partial shares for use. Such machine-readable instructions may also be loaded onto a computer or other programmable data processing devices, so that the computer or other programmable data processing devices perform a series of operations to produce computer-implemented processing, thus the instructions executed on the computer or other programmable devices provide an operation for realizing functions specified by flow(s) in the flow charts and/or block(s) in the block diagrams. Further, the teachings herein may be implemented in the form of a computer software product, the computer software product being stored in a storage medium and comprising a plurality of instructions for making a computer device implement the methods recited in the examples of the present disclosure. While the method, apparatus and related aspects have been described with reference to certain examples, various modifications, changes, omissions, and substitutions can be made without departing from the present disclosure. In particular, a feature or block from one example may be combined with or substituted by a feature/block of another example. The features of any dependent claim may be combined with the features of any of the independent claims or other dependent claims.

Claims

Claims: 1. A method of regulating use of an authentication token, the method comprising: in response to a request to access the authentication token, distributing a challenge to a set of nodes logically encoding a set of policy domain layers, each policy domain layer in the set of policy domain layers associated to a different cryptographically enforced logical operation; and generating a response to the challenge, the response comprising data from the set of nodes indicating possession of the authentication token, wherein the response is constructed from multiple partial shares of the authentication token obtained on the basis of the cryptographically enforced logical operations performed over predetermined threshold numbers of nodes in each of the set of the layers. 2. The method as claimed in claim 1, further comprising registering a node as part of a policy domain layer on the basis of a set of node attributes. 3. The method as claimed in claim 1, wherein a predetermined threshold number of nodes for a policy domain layer is selected on the basis of the cryptographically enforced logical operation for that layer. 4. The method as claimed in claim 1, wherein a predetermined threshold number of nodes for a policy domain layer comprises a sub-set of nodes of the layer. 5. The method as claimed in claim 1, wherein a predetermined threshold number of nodes for a policy domain layer comprises all nodes of the layer. 6. The method as claimed in claim 1, further comprising: generating the response on the basis of partial shares obtained from nodes in multiple layers. 7. The method as claimed in claim 1, further comprising: confirming compliance with a cryptographically enforced logical operation by determining whether participation by nodes in each of the layers is sufficient to satisfy the predetermined thresholds. 8. The method as claimed in claim 1, wherein a node is a device or part thereof, or a system or part thereof. 9. A cryptographic access structure for regulating access to an authentication token by a requesting entity, shares of the authentication token being distributed across multiple nodes defining a set of policy domain layers of the structure, wherein access to the authentication token is based on fulfilment of cryptographically enforced logical operations executed over a predetermined threshold number of nodes in each layer of the set of the layers. 10. The cryptographic access structure as claimed in claim 9, wherein a threshold number of nodes in a layer is selected on the basis of the cryptographically enforced logical operation for that layer. 11. A non-transitory machine-readable storage medium encoded with instructions for regulating use of an authentication token, the instructions executable by a processor a machine whereby to cause the machine to: generate a challenge for distribution to a set of devices that logically encode a set of policy domain layers, each policy domain layer in the set of policy domain layers associated to different cryptographically enforced logical operations; receive a response to the challenge comprising data representing multiple partial shares of the authentication token from devices in each of the policy domain layers; determine whether the received multiple partial shares correspond to predetermined threshold numbers of devices in each of the set of the layers; and on the basis that device participation in each of the layers is sufficient to satisfy the predetermined threshold numbers, construct the authentication token from the multiple partial shares for use. 12. The non-transitory machine-readable storage medium as claimed in claim 11, further comprising instructions to: construct a cryptographic access structure by specifying a number of devices used to logically encode a policy domain layer. 13. The non-transitory machine-readable storage medium as claimed in claim 12, further comprising instructions to: select a predetermined threshold number of devices used to comply with a cryptographically enforced logical operation for the policy domain layer. 14. The non-transitory machine-readable storage medium as claimed in claim 11, further comprising instructions to: define a cryptographic access structure comprising multiple devices defining a layer that forms a sub-domain of a logically different layer. 15. The non-transitory machine-readable storage medium as claimed in claim 11, further comprising instructions to: populate a policy domain layer using devices with selected attributes.