A Bloom Filter Based Model for Decentralized Authorization

A decentralized authorization mechanism is proposed that uses Bloom filters to implement authorization delegation. This lightweight mechanism is unlike conventional approaches that typically rely on public key certificates to implement distributed delegation. In taking an approach based on one‐way hash functions, the mechanism may be preferable for use in computationally constrained environments where public‐key cryptography is not desirable.


INTRODUCTION
Access control systems such as in Refs. 1-3 are intended to provide a decentralized approach to constructing and interpreting authorization relationships between principals (public keys). Unlike a centralized authorization server-based approach, authorization rules are defined and signed locally by issuing principals and these cryptographic delegation credentials can be distributed in any manner to suit the principals involved. In computational terms, and assuming nonthreshold delegation, a delegation action requires a public-key based signing operation, whereas a verifier must carry out a public-key based signature verification operation. These relatively computationally expensive operations may not be desirable in applications where performance and/or energy consumption are constrained. Such applications include sensor networks, radio-frequency identification systems, and some smart cards.
One-way cryptographic hash functions have been used previously to provide alternatives to symmetric key cryptography in the implementation of authentication protocols, for example, in Refs. 4 and 5. These lightweight implementations are motivated by constraints on computation and power consumption, 5 or other concerns, such as the availability of cryptographic operations. 4 This paper extends this idea by developing a distributed authorization delegation mechanism that is constructed entirely using one-way cryptographic hash functions. It is suggested in Ref. 6 that hash chains, used, for example, in micropayment 7,8 and password systems, 9 can be used to provide a rudimentary form of authorization delegation. In Ref. 6, a hash chain provides a total ordering of permissions and delegation corresponds to expose a hash value to a recipient whereas authorization verification corresponds to a test for chain membership. However, a hash chain is not useful as a general authorization system since it can only support sets of permissions that form total orderings. By implementing permissions as Bloom filters, 10 the approach described in this paper supports the more practical lattice and partial orderings of permissions.
The paper is structured as follows. Section 2 provides a review of Bloom filters and some particular properties that are used in the development of Bloom permissions, which are described in Section 3. Section 4 considers potential attacks on the system and provides an analysis of the security of the proposed mechanism. Finally, Section 5 discusses the proposal with regard to related work and Section 6 concludes the paper.

BLOOM FILTERS
The proposal relies on the use of Bloom filters introduced by B. H. Bloom in 1970, 10  Bloom filters are mostly used as probabilistic data structures to encode sets of elements. Examples of their application include Google's BigTable distributed storage system, 11 which uses them to check in-memory data to reduce disk lookups, and the Squid Web Proxy, 12 which implements its cache digest with Bloom filters.
In addition to being an efficient data structure for encoding sets, Bloom filters have some interesting security characteristics. Given a value, it is fast and easy to check whether the element is in the filter. However, given a suitably configured filter, it is not feasible to calculate the list of elements contained in the filter. the output determines the value of k in the filter (number of hash functions in the original model).
The scenario proposed by this work is that of privacy-preserving searches. That is, given a user B with a set of values, another user A can send an encrypted value to B. Then B can check if the value is in its set, without gaining knowledge about the value sent by A. To that end a trusted third party (TTP) is used to avoid key distribution problems. The user A computes E k A (x) and sends it to the TTP. The TTP has all values r ij = k j • k i for all i, j , and can then compute The value E k B (x) is returned to A. Now A can send this value to B, who can check if the respective value x is in the filter.
There are similar approaches for encrypted Bloom filters such as, 15 which uses an encryption functions as simple hash functions, however the approach requires the generation and distribution of keys, which indirectly can lead to the use of a TTP if we consider a generic distributed scenario. In Ref. 16, the authors attempt to remove the need for a TTP, however that comes at the expense of using publickey cryptography, either with blind signatures or using oblivious pseudorandom functions, which require at least a modular exponentiation.
In the approach proposed in this paper, the use of a TTP or a complex key distribution scheme is avoided. Moreover, although the Pohlig-Hellman algorithm is relatively efficient, it is still expensive when compared with the original Bloom filter model. We therefore opt to use the Bloom filter in its original formulation. We will argue that, assuming a suitable configuration of the Bloom filter, we can obtain a tolerable degree of security without relying on the use of more complex cryptographic operations.

False Positives in Bloom Filters
Bloom filters may present false positives. This section discusses several definitions of the false positive rate of Bloom filters, which have been considered in the literature.
The first estimation of the false positive rate of Bloom filters appeared in Ref. 17. Given a Bloom filter of size m, a family of k hash functions and n elements, this first approach (denoted as fp1) is given by That is, if p is the probability that a specific bit is still 0 after adding n elements in the filter, then Departing from Eq. 1, the false positive rate can be minimized in terms of the parameter k. Thus, given m and n, an optimal configuration is achieved for k = m n ln 2 (2) Moreover, in this case we have that fp1(k, n, m) = (1/2) k ≈ (0.6185) m/n18 . Recently, in Ref. 19 the authors found Equation 1 to be slightly imprecise. They determined the probability of a false positive in a Bloom filter as where kn i is the Stirling number of second kind, 20 defined as In the same paper 19 the authors provide an upper and lower bound for fp2(k, n, m).
Given the current state of the art, fp1 is considered as a first approximation of the false positive ratio of Bloom filters, while fp2 and fp3 do provide the exact estimation. The error in the original estimation of the false positive given by fp1 from Equation 1 is that given the result of the hash functions y 1 , . . . , y k for a given element, the events B(y i ) and B(y 1 ) = B(y 2 ) = · · · = B(y k ) = 1 were assumed to be independent. This was found to be imprecise, that is, minimum. 22 Moreover, the relative error diminishes with large values of m, where large is considered to be m ≥ 1024 bits. 21 For the sake of simplicity, in this paper we will consider the events B(y i ) and B(y 1 ) = B(y 2 ) = · · · = B(y k ) = 1 to be independent. We also consider relatively large filters reducing the error that this last assumption may introduce.

Filter Intersection and Union
Set operations such as union and intersection can be carried out on the filters, which can be regarded as sets of elements. Consider two sets of elements A and B Contrary to the union, the intersection of Bloom filters does not always correspond to the intersection of their relative sets.

Vector Subset Ordering
We define an ordering on Bloom filters, based on set inclusion, that is, vector subset. Given two sets of elements A and B and their respective Bloom filters, B(A) and B(B), then the following holds: This filter ordering can be expressed in terms of filter intersection as In this case, the probability of obtaining the intersection by the bitwise AND operation will always be P r( ) = 1, since |A \ A ∩ B| = 0 (see Equation 6). We also note that the inverse is not true for the general case, that is, However, the event of this inverse relation not being true is unlikely. In order for this to happen, the filter B(A) has to have at least an element x not contained in A ∩ B, which overlaps with the other elements in A. That is, a false positive. Thus, the following is considered to hold: with probability fp(k, n, m).
It is important to note that the binary relation is an order relation since it is  These properties are ensured on the basis of the false positive probability noted above. It will be demonstrated in the later section that this relation can be used to determine a partial ordering or lattice on a set of Boom filters.

Hash Chains as Total Orderings of Permissions
Bloom Permissions are inspired by previous work on micropayment systems 6-8 , which makes use of a hash chain to represent coins, and where the knowledge of a value from a hash chain entitles a user to use the coin. In Ref. 6, it is observed that such hash chains can also be used to provide a rudimentary form of authorization delegation. In this scheme, permissions are represented by hash values and a principal generating a hash chain h n (s) defines a total ordering between hash-permission values as h n (s) h n−1 (s) . . . h(s) s, where s is secret and represents the highest permission and h n (s) is the lowest permission and is known by all. In the absence of knowledge of the secret s, a third party delegated permission value The hash values can be used as secret permission credentials that confer access rights to the holder. However, Ref. 6 is not useful as a general authorization system since it only support sets of permissions that form total orderings.

Bloom Filters as Partial Orderings of Permissions
Let (P , ≤) be a lattice of permissions P with a supremum denoted as and infimum denoted as ⊥. Given x, y ∈ P , then the ordering x ≤ y is interpreted to mean that if a user holds permission y then the user also implicitly holds permission x. Note that techniques such as in Refs. 24 and 25 can be used to transform arbitrary partial orders of permissions to a lattice ordering.
The Bloom filter B forms a lattice under vector subset that is isomorphic to the permission lattice (P , ≤) under the mapping B(a) for values a ∈ P . Thus, we have that (with probability bounded by fp(k, n, m)), for a, b ∈ P then The lattice ordering (P , ≤) is also isomorphic to the powerset lattice with subset ordering ⊆ under the mapping a = {x ∈ P | a ≤ x}, that is we have for a, b ∈ P then 26 : Therefore, we have (with probability bounded by fp(k, n, m)), We denote this isomorphic lattice as (B, ), where each element in B is a Bloom filter that encodes the corresponding set from the powerset of (P , ≤). A Bloom filter belonging to B is called a Bloom permission.
As an example consider the lattice from Figure 1. The corresponding isomorphic powerset lattice is depicted in Figure 2, and the Bloom permission lattice is built by replacing each subset by its corresponding Bloom filter.

Securing Bloom Permissions
The owner of the policy (P , ≤) generates a set of Bloom permissions of the form B( a ) for each a ∈ P . These are the permission values that are used as delegation tokens. Following the examples in Figures 1 and 2, Figure 3 depicts the Bloom permission lattice generated by the authority.
A principal that knows the value for (holds) a Bloom permission B( x ) is considered to be authorized for an action requiring permission x ∈ P . The delegation mechanism works on the basis that it is not feasible for a principal to compute a Bloom permission B( x ) unless the principal holds (has been delegated) the value for some B( y ), where x ≤ y. In the proposed scheme, the supremum permission ∈ P is treated as a seed value and is assumed to be a secret that is known

Authorization Delegation
Given a principal holding Bloom permission B( y ), for y ∈ P , then in order to (attempt to) delegate permission x ∈ P , the principal computes B( y ) B( x \ { }). Note that the principal may not know the secret and so can only compute y \ { }. Since the set B of all Bloom permissions forms a lattice, then it follows that Thus, the computed Bloom permission for x will be valid only if the principal carrying out the delegation does know B( y ) and x ≤ y. Otherwise, the generated Bloom permission will not correspond to any permission from the policy (the Bloom permission lattice). This is consistent with the interpretation of the permission ordering: given x, y ∈ P then x ≤ y means that if a user holds permission y then the user also holds (and may delegate) the permission x.
As an example, consider the permission lattice from Figure 1 and a user who holds permission a. This user has the Bloom permission B( a ) and wants to delegate permission e to another user. The user constructs the Bloom filter B({c, d, e}) and then easily computes B( e ) = B( a ) B({c, d, e}), or equivalently, in the generic case B ( e ) = B( a ) B( e \ ) = B( a ) B({a, c, d, e}).

Authorization Verification
A principal presents Bloom permission (bit vector) X to a service owner (verifier) who requires permission x for authorization for some requested action.
This request is authorized if and only if the following is verified to be true.
One might be tempted to permit a requester to present a Bloom permission Y corresponding to permission B( y ), where x ≤ y and have the verifier test B( x ) Y . However, this is not secure since any requester can present a Bloom filter corresponding to the empty set ∅ and we have B( x ) ∅ under the Bloom permission ordering.
Alternatively, suppose that the requesting principal holds permission y ∈ P such that x ≤ y and requests an action requiring permission x. In this case, he/she can easily compute Note that while the requester could present B( y ) and the verifier could compute B( x ), there is the risk that the requester implicitly delegates a permission B( y ) that the verifier previously did not hold.

Bloom Permission Authentication
In this paper, we do not prescribe how the Bloom permissions might be securely exchanged between principals. In the case of delegation, the delegator must securely transfer value B( x ) to a recipient. This could be done over a secure network connection, if available, or via a physical exchange of the value; for example, a transfer of the Bloom permission from a reader to a smart card. In Ref. 27, a wireless sensor network application is outlined where Bloom permissions are installed at sensor deployment or via handheld sensor access devices.
In the case of verification, the requester must prove knowledge of the required permission/secret to the verifier. In addition, to prevent an implicit delegation, the requester needs to be sure that the verifier also holds the given permission. This can be achieved by a mutual authentication protocol whereby both parties prove that they know the secret (Bloom permission): Bloom permissions can be treated as secrets (keys) that are shared between principals. The reader is referred to Refs. 4, 5 and 28 for examples of lightweight authentication protocols that are also implemented in terms of one-way cryptographic hash functions.

SECURITY OF BLOOM PERMISSIONS
The security of the previously described scheme is based on the difficulty of forging a Bloom permission.   In order for the proposed scheme to be secure, all three cases must be difficult to achieve. This difficulty can be ensured by the properties of a suitably configured Bloom filter, as will be shown in this section. The first case, computing B( x ) without knowledge of any other information, can be regarded as a brute-force attack, which is clearly unfeasible in the general case. We will discuss the other two cases.

PROPOSITION 2. It is not feasible for a principal to compute B( x ) when knowing only the permission set P \ { }.
To be able to compute B( x ), the principal cannot use x , since he does not know . The principal, however, might try to guess Consider an empty Bloom filter. In this case, the principal needs to guess the position of the k bits corresponding to the element in the filter vector. Assume that the k bit positions are selected randomly. There are m+k−1 k possible combinations (note that a bit can be selected more than once for the same element), and thus the probability for the principal to forge B({ }) without the knowledge of is Figure 4 depicts this probability for a filter with m = 1024 and k : 0.50. This attempt to forge B({ }) can be seen as a brute-force attack on B({ }), which becomes very difficult even with low values of k. Thus, assuming that is the secret ensures that it is not feasible for a principal to create arbitrary Bloom filters containing valid permissions that have not been delegated to the principal.
Consider the more general case, whereby the principal might not only know P \ { }, but may also know any Bloom permission B( z ) such that z ≤ x. Note that permission x could also be the top permission , thus the proposition can be paraphrased as is not feasible for a principal to compute B({ }) even with the knowledge of P \ { } and any Bloom permission other than B({ }). There are several ways in which an attacker might attempt to use Bloom permissions B( z ) such that z ≤ x to obtain B( x ). r By removing elements from an existing filter: In this case, the attacker has the filter B( z ) and attempts to remove all elements z \ x from the filter by setting some given bits to 0 in the filter. This case is considered in Section 4.1.
r By filter intersection: In this case the attacker attempts to intersect two filters to obtain the required element. The success of the attack will be determined by the probability of intersecting Bloom filters given by Equation 6. Section 4.2 discusses this case.

Removing Elements from a Bloom Filter
As previously stated, a property that makes Bloom filters particularly suited to security applications is the fact that removing an element from a filter is difficult. It is interesting to note that this is normally considered a drawback of Bloom filters, and there are versions of Bloom filters that allow the removal of elements. 29 In the proposed scheme, the difficulty of element removal is important as it ensures the difficulty of forging Bloom permissions.
By removing one or more elements, a principal who holds a Bloom permission can try to obtain B({ }) but can also attempt to scale privileges. For instance, from the example in Figure 3, a user who holds permission d, has the Bloom permission B ( d ) = B({ , a, d}). This user can try to remove the element d from the filter, and end up with a filter equivalent to B ({ , a}), thus gaining the Bloom permission that implements a.
To remove a given element x from a Bloom filter, one must set some specific bits B[x i ] = 0 while being aware that r Setting B[x i ] = 0 may cause the deletion of other elements if they overlap the same bit r Given that filter equality is going to be used to test the authorization (see Section 3.5), one has to remove all bits B[x i ] corresponding to the element x, if and only if they have not been overlapped by other elements. Note that if instead, we only used element inclusion to test the resulting filter, it will be enough to remove one bit belonging to element x that has not been overlapped. This last point is the primary reason to require filter equality as an authorization proof as opposed to filter inclusion.  We are interested in configurations of Bloom filters that have a high probability of overlapping bits. That is, a bit set to 1 in the vector representing the Bloom filter corresponds to more than one element.
Let E1 be the event that at least one bit is overlapped by more than one element. That is, the same bit B[i] = 1 for more than one element. Then, let E0 be the event that no element overlaps any bit. So P r(E1) = 1 − P r(E0).

Aggregation Attacks
The lowest upper bound operator in the permission lattice can be used to define permission aggregation: A principal holding permissions a, b ∈ P may be considered to hold their aggregation a ⊕ b ∈ P . In general, if a ⊕ b is the lowest upper bound of permissions a and b of lattice P then it follows that  The probability of success, given by the probability of Bloom filter intersection from Equation 6, will be determined first by the parameters m and k of the filters. If we consider m = 1024, the probability of the success on the intersection in terms of k is shown in Figure 7.
Although it might seem a relatively high probability from a security point of view, we have to consider the other parameter that affects this probability. As shown in Equation 6, the success in the attack also depends on the value of |A \ A ∩ B| *  |B \ A ∩ B|. Let ρ denote the number of elements in A but not in A ∩ B, that is, ρ = |A \ A ∩ B|, and assume that it is equal to |B \ A ∩ B|. As ρ increases, the probability of intersection is reduced as depicted in Figure 8.
In this case, if we take n = 50 the value of k, which minimizes the false positive probability following Equation 2 is k = m/n ln 2 14.2, so with k = 14 we have a false positive of approximately fp1(k, n, m) = 5.36 × 10 −5 , and with ρ = 5 a probability of intersection P r( ) = 8.3 × 10 −3 , which we consider to be quite acceptable. Moreover, one can sacrifice the false positive rate by increasing, to a small degree, the value of k, which provides a lower P r( ) if a lower ρ is expected. For example, Figure 9 depicts the intersection probability in filters with m = 1024, k = 14 (n = 50), for ρ : 0.. 10 It is necessary to select a trade-off between the probabilities of false positives and intersection. By increasing k, we can reduce the probability of success for this attack but it comes with the cost of increasing the probability of false positives. Table I shows the false positive (fp1) and intersection probabilities P r( ) for some different values of k and ρ. Many lattice-based permission models rely on an assumption that if a principal holds a number of permissions then the principal also holds the lowest upper bound on those permissions. For example, holding a read permission and a write permission implies possession of a read-write permission. The proposed Bloom permission model effectively requires this assumption since a principal has the potential to determine B( a ⊕ b ) from knowing B( a ) and B( b ). In practice, this means that the potential for permission aggregation to escalate authority must be considered during the design of the permission ordering. For example, returning to the lattice in Figure 1, a principal that holds permissions c and b, implicitly holds = c ⊕ b, and therefore also holds permissions a and d. If this escalation is considered undesirable, then one could modify the original lattice to include a distinct permission to reflect the aggregation of c and b. In general, a powerset lattice of individual permissions could be used to provide distinct aggregate permissions.

DISCUSSION AND RELATED WORK
Bloom permissions are a form of software capability whereby possession of the capability entitles the principal to engage in specified actions. Many existing applications, ranging from Web authorization cookies 30 to embedded systems, 5 implement forms of software capabilities based on a keyed one-way hash of the permissions. For example, on receipt of capability h k (y) for a request requiring permission x, the verifier checks x ≤ y and validates the capability using a secret k known only to the verifier. The holder of a capability h k (y) can delegate it to a third party by revealing the value h k (y). However, without knowing the secret k, the holder cannot delegate a lesser capability h k (x) where x < y. This issue could be solved if in being delegated authority for y, the recipient was given a copy of every capability h k (x), where x ≤ y. However, this is undesirably complex and is not practical for low-power/computation systems. The recipient of a Bloom permission B( y ) can compute, and therefore further delegate, any permission B( x ), where x ≤ y; this computation does not require knowledge of the underlying secret . Thus, Bloom permission delegation and verification does not require coordination with a central authority (the owner of ) and can be decentralized across the network.
Trust management systems 1-3 also provide a decentralized approach to delegation of permissions between public keys. Authorization is defined in terms of whether trust management capabilities (credentials) provide a delegation chain, for the given permission, from the verifier to the requester. This is unlike Bloom permissions, whereby possession of a permission is sufficient to determine authorization. In addition, it is not possible to delegate a Bloom permission prior to holding the permission. Typical trust management systems allow a principal to issue a delegation certificate independent of the permissions it may hold at that time, with an assumption that other necessary credentials to make up the delegate chain will be obtained prior to verification.
Lattice-based permission orderings are found in a variety of both Mandatory and Discretionary Access Control models. In addition to providing sensitivity orderings for Multilevel security and Chinese Walls, 25 role hierarchies in role-based access control, 31 they are used in application-level security, for example, the implies ordering across Java permissions. Bloom permissions can be used in the implementation of these models. In Ref. 27, a prototype of a wireless sensor network is outlined whereby, among other security requirements, Bloom permissions are used to determine access to sensors by readers. The permission lattice is defined as a Cartesian product of sensor categories and actions. For example, a medic's reader has permission ({fire, EMT}, {rd}) reflecting authority to read fire service and EMT service sensors.
It has been demonstrated 32 that public-key operations can be carried out by devices with limited computational power. Thus, in principle, the access control model described in this paper could be implemented by a conventional Trust Management system. However, this is not considered, as the objective of this paper is the design of an authorization model that does not rely on relatively expensive public-key operations.
Verification of authorization requires evidence that the requester knows the (secret) Bloom permission. This corresponds to a mutual authentication between requester and verifier. While Section 3.6 suggests that existing authentication mechanisms could be used, investigating mechanisms that support Bloom permission authorization and delegation for specific applications such as Ref. 27 is a topic of ongoing research.
Rivest 33 notes that conventional revocation mechanisms such as certificate revocation lists and the online certificate revocation protocol can put a burden on the authorization verifier. He argues that short-lived credentials move this (computational and network) burden from the verifier to the requester. This view is particularly true for the kinds of applications that are intended for Bloom permissions. A date value, defining the validity period, could be incorporated into each Bloom permission. However, this date value would have to be immutable. That is, the holder of a Bloom permission y valid until date d can only delegate a permission x (x ≤ y) that is also valid until the same date d. With the existing mechanism it would not be possible to delegate x with an earlier expiry date d as it would presume the existence of a date ordering d ≤ d implemented in the Bloom filter. Investigating whether this could be effectively addressed using a date-(hash) chaining mechanism such as Ref. 34 is a topic for future research.

CONCLUSIONS
A model for decentralized authorization implemented in terms of Bloom filters is proposed. Bloom filters provide a permission structure that is isomorphic to the required permission ordering with the property that it is not feasible for a principal to compute the Bloom permission for some permission x unless the principal already knows the value of a Bloom permission for some y, where x ≤ y in the original permission ordering. This provides a basis for a lightweight authorization mechanism whereby knowledge of the Bloom permission value indicates authorization, and delegation and verification is implemented in terms of one-way hash function calculations.