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)
Fuzzy Identity-Based Encryption
Amit Sahai and Brent Waters
Annual International Cryptology Conference (EUROCRYPT ’05), Aarhus, Denmark, May 2005.
Vipul Goyal, Omkant Pandey, Amit Sahai and Brent Waters
ACM Conference on Computer and Communications Security (CCS ’06), Alexandria, VA, November 2006.
Network and Distributed System Security Symposium (NDSS ’07), San Diego, CA, March 2007.
John Bethencourt, Amit Sahai, and Brent Waters
IEEE Symposium on Security and Privacy (Oakland ’07), Oakland, CA, May 2007.
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