Attribute-Based Systems

Attribute-based systems use attributes of principals and resources as they may exist, for instance, in an enterprise database, as a foundation for security and messaging operations. There are at least three areas of significant progress on such techniques. Attribute-Based Access Control (ABAC) promises greater flexibility and integration than access control lists and roles because of its ease of integration with existing enterprise data systems, all of which maintain databases of attributes for principals. Attribute-Based Messaging (ABM) enables the use of addresses and routing based on recipient attributes to make messaging more dynamic and targeted. Attribute-Based Encryption (ABE) allows data to be encrypted based on attributes so that only the principals with specified attributes are able to decrypt it.

Attribute-Based Access Control (ABAC)

ABAC is an access control strategy that centers access control decisions on the attributes of principals and resources. It can be contrasted with the more traditional notions of Identity Based Access Control (IBAC) and Role Based Access Control (RBAC). In IBAC identities of principals are used as a foundation for access control, typically in the form of Access Control Lists (ACLs), which are associated with resources and provide a list of parties having various access rights to the resource. The maintenance of such lists is a problem. For instance, if all managers are meant to have access to a file then the ACL for the file needs to change each time the group of managers changes. One way to address this problem is RBAC, in which a role describes a bundle of privileges. Principals are assigned roles (like manager) and these roles are used to authorize privileges (like access to the file for managers). Thus a new manager only needs to be assigned his role and the access right to the file will be derived from this automatically. A drawback to using such roles is that they require deliberate design and not all organizations have a system of roles for their principals. Moreover, when new resources are created, new access classes need to be defined: RBAC will require defining new roles for each new access class.

ABAC allows privileges to be derived directly from the attributes of principals (using relevant policies). So, a file that should be accessible to managers is marked as such by indicating that it is available to principals that have the manager attribute. More complex access policies can be specified in terms of a boolean formula on the attributes, like manager OR (programmer AND senior) (where the literals manager, senior etc. are boolean variables indicating whether the principal has that attribute). In fact a flexible design would typically use numerous fine-grained attributes (possibly arranged in hierarchical attribute spaces), and then many of the policies would use non-trivial combinations of multiple attributes. ABAC can be effectively combined with IBAC and RBAC in various ways, like using attributes to populate an ACL or assign a role, so there is not a rigid distinction between these techniques and advances in ABAC will contribute to IBAC and RBAC.

A Uniform Framework for Regulating Service Access and Information Release on the Web
P. A. Bonatti and P. Samarati
Journal of Computer Secuity, 10(3): 241–271, 2002.

Supporting Structured Credentials and Sensitive Policies through Interoperable Strategies for Automated Trust Negotiation
T. Yu, M. Winslett, and K. E. Seamons
ACM Transactions on Information Systems Security (TISSEC) 6(1): 1-42, 2003.

A Logic-Based Framework for Attribute-Based Access Control
Lingyu Wang, Duminda Wijesekera, and Sushil Jajodia
ACM Workshop on Formal Methods in Security Engineering (FMSE ’04), Washington DC, November 2004.

Attribute-Based Encryption (ABE)

ABE is a collection of encryption tools based on attributes and policies assigned to the users by an authority. In particular, it allows one to attach attributes and policies to a message being encrypted so that only a receiver who is assigned compatible policies/attributes can decrypt it. The attributes are boolean variables with arbitrary labels, and the policies are computations represented as boolean circuits over the attribute variables (which evaluate to true or false). ABE is a relatively new innovation that generalizes Identity Based Encryption (IBE). In IBE the only attribute is a single string – the identity of the receiver – with no values associated to it. In fact current ABE schemes are built by cleverly combining the basic techniques of IBE with a linear secret sharing scheme. These schemes can support addressing policies which are in the form of monotonic boolean formulas over the attribute variables. This can be extended to nonmonotonic formulas as well. Though this is a fairly expressive class of policies, it is not powerful enough to represent arbitrary computation. These policies must be applied to attributes of the receiver only (called ciphertext-policy ABE) or to the attributes of the message only (called key-policy ABE, which was the setting in which it was originally proposed). The policy and attributes that are part of the message are unencrypted.

Fuzzy Identity-Based Encryption
Amit Sahai and Brent Waters
Annual International Cryptology Conference (EUROCRYPT ’05), Aarhus, Denmark, May 2005.

Attribute-Based Encryption for Fine-Grained Access Control of Encrypted Data
Vipul Goyal, Omkant Pandey, Amit Sahai and Brent Waters
ACM Conference on Computer and Communications Security (CCS ’06), Alexandria, VA, November 2006.
Secure Attribute-Based Systems
Matthew Pirretti, Patrick Traynor, Patrick McDaniel, and Brent Waters
ACM Conference on Computer and Communications Security (CCS ’06), Alexandria, VA, November 2006.
Attribute-Based Publishing with Hidden Credentials and Hidden Policies
(This work builds on proxy encryption techniques and SELS – Secure Email List Services)
Apu Kapadia, Patrick P. Tsang and Sean W. Smith
Network and Distributed System Security Symposium (NDSS ’07), San Diego, CA, March 2007.
Ciphertext-Policy Attribute-Based Encryption
John Bethencourt, Amit Sahai, and Brent Waters
IEEE Symposium on Security and Privacy (Oakland ’07), Oakland, CA, May 2007.

Attribute-Based Messaging (ABM)

Today, mailing lists are used to provide such messaging, however, recipient lists are overly broad because creating and maintaining more specific lists requires a non-trivial amount of work. ABM is the concept of allowing lists to be formed dynamically by using attributes of intended recipients as addresses. ABM enhances the relevance of messages to the recipient and allows the sender to send confidential messages knowing that the messages would be only delivered to the intended recipients. This concept can be applied to any collection of attributes that are available in enterprise databases. Practical ABM raises some interesting challenges, however. First, there is the challenge of finding a manageable way to deal with access control. If anybody can send a message based on any set of attributes, this may increase rather than decrease the number of unwanted communications. It also entails some privacy issues. For instance: who, if anyone, is allowed to send an email message to faculty that make a salary of more than $100,000? Second, there is the challenge of finding a plausible deployment avenue for ABM that allows the clients to send and receive attribute-based messages via the existing enterprise messaging systems. Third, there is the problem of making ABM sufficiently efficient. And fourth, there is the challenge of extending ABM to inter-domain systems so it can work in messages between organizations.

Attribute-Based Messaging: Access Control and Confidentiality
Rakesh Bobba, Omid Fatemieh, Fariba Khan, Arindam Khan, Carl A. Gunter, Himanshu Khurana and Manoj Prabhakaran
ACM Transactions on Information and Systems Security (TISSEC), volume 13, number 4, December 2010.

Secure Role Based Messaging
David Chadwick, Graeme Lunt and Gansen Zhao Issrc
IFIP Conference on Communication and Multimedia (CMS ’04), 2004.

Attribute-Based Secret Handshake (ABSH)

ABSH protocols allow two users to perform a handshake (or key-exchange) only if each user has attributes specified by the other user. In addition, they have the additional feature that, if a user does not satisfy the specified attributes of the other party involved in the handshake, not only the key-exchange fails but the parties learn nothing about each others’ attributes. Recent ABSH techniques use generalized Identity Based Encryption or Fuzzy Identity Based Encryption to achieve the above mentioned goals.

Secret Handshakes with Dynamic and Fuzzy Matching
G. Ateniese, M. Blanton, and J. Kirsch
Network and Distributed System Security Symposuim (NDSS ’07), SanDiego, CA, February 2007.

Last updated on Thursday, June 26, 2014, 12:33 pm