Role Signatures for Access Control in Open Distributed

Role Signatures for Access Control in Open Distributed Systems Jason Crampton University of London Hoon Wei Lim SAP Research, France Presented by EMRAH ATILGAN 1 9/25/2020

Outline Introduction Access Control - RBAC Open Systems Hierarchical Identity-Based Cryptography Role Signatures Security Architecture Questions 2 9/25/2020

Introduction In an open and distributed system, implementing access control efficiently and effectively is a challenging problem. Such as, User’s request to remote resources may be unknown to the authorization service that controls access to the requested resources. Verifying the authenticity of user credentials or attributes can be difficult. Predefined mappings of principals in one domain to those in the domain containing the resources are needed. 3 9/25/2020

Approaches Using a hierarchical identity-based signatures scheme: Verification keys are based on generic role 4 identifiers defined within a hierarchical namespace. The verification of a role signature serves to prove that the signer is an authorized user and is assigned to one or more roles. Individual member organizations of a virtual organization are not required to agree on principal mappings. User authentication and credential verification is unified in the authors’ approach and can be achieved through a single role signature. 9/25/2020

Possible solutions… Access requests may be received from a user that is not known to the authorization service. It is possible to use signed assertions and PKI to determine that the user has been previously authenticated by a security domain , but not known by , to which the request was directed. Also, it is possible to similar assertions to determine that a user has a particular attribute, role Difficult to interpret r , in r in ’s authorization policy. There must be prior agreement between and what 5 . r should mean to about . 9/25/2020

Possible solutions. . (cont. ) These approaches and existing authentication frameworks rely on some form of certificate-based PKI Key. Note, SPKI/SDSI, RBTM These frameworks rely on signed statements or 6 assertions, attesting to the user or the associated public key having a particular attribute. A set of such attributes is used to map the user to principals in the relevant authorization policy. Existing approaches require the processing, particularly verification, of a large number of digitally signed credentials. 9/25/2020

In this paper… Hierarchical structure within a virtual organization (VO) or a federation helps to solve problems of principal mapping, credential verification and credential chain discovery. VO have a hierarchical structure, enabling member organizations (MOs) and principals within those organizations to be identified uniquely within a hierarchical namespace. Access requests are signed using a hierarchical identity-based signature scheme (HIBS), in which signing keys correspond to role identifiers. 7 9/25/2020

In this paper… Identifiers are based on the hierarchical namespace in VO and associated with some generic roles defined by the VO. If the identifiers are correctly formed and the associated signature on the request can be verified, then the user is known to be authorized for those roles in his home organization. 8 9/25/2020

Access Control Mechanism to enforce access rights to resources and data Users can access resources and data to which they have access rights Users cannot access resources and data to which they don’t have access rights Need: Proper user identification and authentication Information specifying the access rights are protected from modification 9 9/25/2020

Access Control Models All accesses Discretionary AC Mandatory AC 10 Role-Based AC 9/25/2020

Role-Based Access Control (RBAC) Multi user systems Multi-application systems Permissions are associated with roles Role-permission assignments are persistent v. s. user permission assignments Intuitive: competency, authority, and responsibility Express organizational policies Separation of duties Delegation of authority Flexible: easy to modify to meet new security requirements 11 9/25/2020

RBAC �Supports �Least-privilege / Separation of duties / Data abstraction �Allows to express security requirements but cannot enforce these principles �Roles: �User group: collection of user with possibly different 12 permissions �Role: mediator between collection of users and collection of permissions �RBAC independent from DAC and MAC (they may coexist) �RBAC is policy neutral: configuration of RBAC 9/25/2020 determines the policy to be enforced

RBAC 3 consolidated model RBAC 1 RBAC 2 constraints role hierarchy RBAC 0 base model 13 9/25/2020

RBAC 0 Users, roles, permissions, sessions U Users assignment S Sessions 14 R Roles Permission P assignment Permissions . . . 9/25/2020

RBAC 1 U Users S Sessions 15 User assignment R Roles Permission P assignment Permissions . . . 9/25/2020

RBAC 1 Role Hierarchy Specialist Physician Primary-care Physician Inheritance of privileges Health-care provider 16 9/25/2020

RBAC 1 Limit scope of inheritance Private Roles Project Supervisor Test Engineer Programmer Project Member 17 Test Engineer’ Project Supervisor Test Engineer Programmer’ Programmer Project Member 9/25/2020

RBAC 2 – Constraints Same as RBAC 0 + Constraints U Users assignment S Sessions 18 R Roles Permission P assignment Permissions . . . Constraints 9/25/2020

RBAC 3. User U Users assignment S Sessions 19 R Roles Permission P assignment Permissions . . . Constraints 9/25/2020

Closed v. s. Open Systems Closed System Open System (minimum privilege) Access requ. Exists Rule? yes Access permitted 20 no Access denied (maximum privilege) Access requ. Allowed accesses Disallowed accesses Exists Rule? no Access permitted yes Access denied 9/25/2020

Hierarchical Identity-Based Cryptography In general, Generating public keys based on user names, or some other publicly available information could uniquely identify a user Such as an e-mail address. Private keys are computed and distributed by Private Key Generator (PKG) Trusted third party attest to the authenticity of public keys. In identity-based cryptography, Public keys are derived from public information and 21 their authenticity obviates the requirement for certificates 9/25/2020

Hierarchical Identity-Based Signatures HIBS reduces the burden of key generation on the PKG It is assumed that entities can be arranged in a rooted tree. Entities at one level are trusted to issue private keys to entities immediately below them in the tree. Level 0 ----The root PKG Produces private keys for entities at level 1. Level 1 ----- entities now act as PKGs Produces private keys for entities at level 2. 22 So on…. 9/25/2020

Tree � Each node in the has an identifier. � The identifier of an entity is the concatenation of the node identifiers in the path from the root to the node associated with the entity. Level 1 Level 2 Level 3 � Generally, represents an entity at level t, whose ancestor at level 1 has an identifier , and whose ancestor at level j has identifier 23 9/25/2020

Gentry-Silverberg HIBS scheme Works on the idea of; The root PKG computes a master secret and a set of system parameters, and every other entity chooses a secret value. Each non-leaf entity is a PKG and is responsible for computing private keys for each of its children using each child’s identifier. Each entity may sign messages using the private key generated by its parent. Any other entity may verify the validity of a signature using the signed message, the signer’s identifier and the system parameters as inputs. 24 9/25/2020

Role Signatures � They assumed that there exist a hierarchical structure within an A open distributed system. trusted authority (TA) Virtual Organizations (VOs) Member Organizations (MOs) Generic Roles Level 0 Level 1 Level 2 Level 3 � It is also important clarify that they are using identifiers (for VOs, MOs, and generic roles) rather than user identities. 25 9/25/2020

Applying Gentry-Silverberg HIBS TA is responsible for issuing signing keys to VOs. If the TA issues a signing key to principal , this means that is a legitimate VO principal (recognized by TA). This signing key is derived from the identifier Similarly, if the principal to , this means that, principal in. . issues signing key is a legitimate MO This signing key is derived from the identifier . may issue a signing key to user u, based on the generic role identifier. 9/25/2020 Finally, 26

RBAC Policies for Open Distributed Systems In this paper, the authors assume: a VO comprises a countable set of MOs. Membership of this set may change over time. VO defines a finite set of generic role identifiers . Internal Access Control Policy (ACP) A policy decision point ( ) for a resource controlled by uses ( ) to decide request for access to that resource from users authenticated directly by that organizations. External Access Control Policy Each MO extends its ACP so that users in that MO are 27 assigned to zero or more of the generic roles. These role identifiers is used to map users to one MO to roles in another MO. ACP must be extended to specify how members of generic 9/25/2020 roles in other MOs are mapped to local roles.

Internal ACPs They use RBAC 96 syntax for internal ACPs. VR for the set of generic roles identified within a VO. Each MO defines an internal set of roles and defines A permission-role assignment relation A role hierarchy relation A user-role assignment relation is the set of authorized users in. Pi is the set of permissions for resources maintained and protected by ( , ) is a directed and acyclic graph A user 28 may be assigned directly to a generic role vr via the relation, or assigned implicitly via 9/25/2020 inheritance in the relation.

External ACPs Each MO needs to decide which other MOs it trusts, and which generic roles defined by those organizations can be mapped to internal roles. RT family : Role Based Trust Management language defines four different types of rule: A. r is an assertion made by A that assigned to role r Equivalent to , where assignment relation defined by A. r member of role r. 29 is is the user-role. is a policy statement by A that any is also a member of the 9/25/2020

RT 0 language (cont. ) A. r is a policy statement made by principal A that says any member of a role , where B itself a member role , is a member of role r. Statements of this form allow A to delegate responsibility (to member of principals to role ) for assigning A. r is a statement made by principal A that says that any member of roles and is also a member of role r. 30 9/25/2020

Applying RT rules to this paper. member. Org (1) VO. member. Org defines a role called member. Org and any member of VO. member. Org is also a member of the local member. Org role . vr (2) . member. Org. vr Any member of a generic role vr defined by a member role member. Org is also a member of the generic role defined by. VO says that 31 is a member organization and says that u is a member of generic role vr, then 9/25/2020 is prepared to accept u as a member of vr as

Applying RT rules (cont. ) � � � could map generic roles directly to local role. member. Org VO. member. Org (3). . member. Org. vr (4) �The external ACP includes rules that map multiple. member. Org. generic roles to local roles and vice versa. � � . r (5). member. Org (6) VO. member. Org �Any user who is a member of each of the generic 32 roles 9/25/2020

Access Request Signing And Verification �Associate each generic role with a unique identifier within the VO namespace and use this to generate a private key that is used to sign access requests – role signatures. �Signature verification is performed using a key that can be derived from the identifier by any principal, thereby enabling that principal to verify that user is indeed a member of a particular generic role. �So, rules (3) and (4) can be reduced to � VO. member. Org. vr �If a user can provide a credential proving that she is a member of a generic role vr in a MO of the VO, then she can be mapped directly to role vr in. 33 9/25/2020

How does it work? �A user u uses a signing key, such as the one associated with role identifier , to sign an access request. �If the PDP in can verify the signature by using the verification key associated with , Then the PDP in can be convinced that is a legitimate VO (as far as the TA is concerned), is the legitimate MO (as far as the VO is concerned), and u is a legitimate user assigned to role vr (as far as the MO is concerned). �The use of multi-key signatures enables a user to 34 9/25/2020 prove authorization for multiple roles in a single

Fine-Grained Identifiers Key Lifetimes: User-Role Revocation Many applications prefer short-lived keys. Minimize the risk of exposing long-term keys. In this proposal, Role identifiers include a lifetime L. // only valid for time User-Role Bindings: Include a local user identifier . 35 u in a role identifier 9/25/2020

Fine-Grained Identifiers (cont. ) Generic Role Sets There may also be situations where it is more appropriate for a user presenting all roles to which she is entitled within a single identifier. The user can obtain, from her organization, a signing key associated with all her roles. ||u||. Advantage: the user is relieved of her responsibility 36 in selecting appropriate signing keys for a particular session. Limitation: it would undermine the principle of least privilege, which may be desirable in some system environments. 9/25/2020

Supporting Multiple Namespaces Distinct hierarchical namespaces having different root TAs, with principals having distinct identities in different namespaces. The only requirement is that the root TAs of these distinct hierarchies must use the same group generator when computing their respective system parameters. The scheme can take as input private keys which correspond to entities at different levels in a hierarchy . r VO. member. Org. member. Uni. 37 MO s and universities belong to different hierarchical namespaces 9/25/2020

Supporting More Complex Namespaces Identifiers are formed from the concatenation of one or more identifier-role pairs. The root can create Level-1 domains Each level-1 domain is provided with a signing key and material with which to generate signing keys for generic roles, including level-2 domains. By doing this, arbitrarily deep hierarchies can be constructed. Identifiers have the form; //vr is a generic role domain|| ||…||domain|| 38 ||vr||u domain||MS||domain||CS||student||alice 9/25/2020

Security Architecture Role signatures can be easily integrated into a security architecture which makes use a hierarchical identity-based cryptography. PECF-GSI : Password-enabled and certificate free grid security infrastructure Single sign-on based on passwords, does not require PKI. A user authenticates to a domain server through a password based TLS protocol. Authentication server acts as a MO, creates a proxy (short lived) credential, compromising a role identifier and its corresponding signing key, and transmits it to the user. The user is only required to sign-on once and use fresh proxy credential generated by the authentication server until the credential expires. 39 9/25/2020

Security Architecture (cont. ) In this paper; No centralized root TA is required. This approach is scalable in the sense that each VO or MO can be associated with a “decentralized” TA that it is willing to trust Role signatures in the decentralized access control model: Higher-level authorities can delegate access control decisions to lower-level authorities/principals. Real world example : Finance sector Head of global financial company main office local branch offices banks customers. 40 9/25/2020

Conclusion �This paper is based on three assumptions: �It is reasonable to define a comparatively small number of generic roles that will be recognized throughout a VO. �The structure of a VO defines a hierarchical namespaces. �Members of VO are trusted to assign their respective users to generic roles. �Role signatures can be used both authenticate 41 users and make access control decisions. �This work provides balance between expressiveness of policy and ease of credentials verification as compared to existing role-based 9/25/2020 access control and trust management framework.

Questions