Cryptographic Role-Based Access Control, Reconsidered ⋆

. A significant shortcoming of traditional access control mechanisms is their heavy reliance on reference monitors. Being single points of failure, monitors need to run in protected mode and have permanent online presence in order to handle all access requests. Cryptographic access control offers an alternative solution that provides better scalability and deployability. It relies on security guarantees of the underlying cryptographic primitives and the appropriate key distribution/management in the system. In order to rigorously study security guarantees that a cryptographic access control system can achieve, providing formal security definitions for the system is of great importance, since the security guarantee of the underlying cryptographic primitives cannot be directly translated into those of the system. In this paper, we follow the line of the existing studies on the cryptographic enforcement of Role-Based Access Control (RBAC). Inspired by the study focusing on the relation between the existing security definitions for such systems, we identify two types of attacks not described in the existing works. Therefore, we propose two new security definitions with the goal of appropriately modeling cryptographic enforcement of Role-Based Access Control policies and studying the relation between our new definitions and the existing ones. In addition, we show that the cost of supporting dynamic policy updates is inherently expensive by presenting two lower bounds for such systems that guarantee correctness and secure access.


Introduction
Traditional access control mechanisms heavily rely on reference monitors, meaning single points of failure operating under protected mode.Though online access control mechanisms with a permanent online presence are necessary in order to serve all access requests by users, this approach must be critically re-examined.The mechanism's inherent limitations greatly affect its scalability and deployability.This issue can be addressed with the help of cryptographic techniques that implement access control policies with the help of cryptographic primitives.This alternative approach is referred to as cryptographic access control.It aims at reducing or even eliminating monitor reliance, as the cryptographic access control policy is achieved in an indirect way: the data is protected by cryptographic primitives and the policies are enforced by distributing appropriate keys to appropriate users.
A main concern in the existing cryptographic access control studies is the gap between the specifications of the enforced access control policies and the actual implementation of the access control systems.In traditional monitor-based access control mechanisms, the correct enforcement of access control policies holds by design.However, in cryptographic access control, the issue becomes more complex.The enforcement relies on security guarantees by underlying cryptographic primitives as well as on the appropriate key distribution/management.Even though some advanced cryptographic primitives are seemingly well-suited for cryptographic access control, their security guarantees cannot be directly translated to security guarantees for the entire system.It is common understanding that there is often a gap between primitives and the applications motivating them.The gap is obscured by uses of similar terms and jargon at both the application and the primitive level.It is unfortunate that in the case of primitives, the security of the motivating application is often omitted.
Formal security definitions for cryptographic access control systems are of crucial importance in order to bridge this gap.However, they are often neglected in the existing research on cryptographic access control.There have been some initial works in this area that focus on new primitives motivated by access control systems [7,2,13] and on access control systems based on said primitives [9,12,14,6].
Throughout the literature, rigorous definitions that examine the security of systems for access control have only been heuristically studied.In the aim of reasoning about the confinement problem, Halevi et al. proposed a simulation-based security definition for access control on a distributed file storage system [5].Their result concerns a particular system rather than a general one.Ferrara et al. defined a precise syntax for cryptographic role-based access control (cRBAC) systems and proposed a formal security definition with respect to secure read access in [4].Following, they extend their results in a setting that supports write access [3], their goal being to reduce the need for trusted monitors mediation for every write access request.Liu et.al. studied security of cRBAC systems in the UC framework [10].They proposed a UC security definition for such systems and showed that this type of security presents an impossibility result due to the commitment problem.
Garrison III et al. studied the practical implications of cryptographic access control systems implementing RBAC policies [8].They analysed the computational costs of two different constructions of cryptographic role-based access control systems via simulations with the use of real-world datasets.Their results indicate that supporting a dynamic access control policy enforcement may prove prohibitively expensive, even under the assumption that write access is enforced with the minimum use of reference monitors.
NEW SECURITY DEFINITIONS.The results presented in [10] show a gap between gamebased and simulation-based security definitions for cRBAC systems, which raises the following question: Do the existing security definitions appropriately capture the secure enforcement of access control policies?
The first security definition is called past confidentiality and refers to security concerns by users, who acquire unauthorised read access to the previous file versions.It serves as a refinement to the existing definition of read security for cRBAC systems.In traditional monitor-based access control, when a user acquires access to the authorised file, it only acquires access to the current content.By "previous contents" we refer to previous file versions written in the past and not considered a part of the file's current content.In cryptographic access control, due to the file system's public accessibility, users can easily obtain previous file versions (even in an encrypted form) by simply monitoring the state of the file system.Therefore, a user recently granted the read permission of a file might retrieve previous contents written at a time, when it did not have access permission -this can be considered as a violation of the implemented access control policy.
Game-based security definitions in the existing work do not appropriately capture the security concern mentioned above [4,3].One should keep in mind that in games, where security is defined with respect to read access, the adversary is not allowed read access to challenge files at any point during the game.This restriction on the adversary cannot rule out the attack mentioned above.In fact, the attack can easily be carried out in the constructions proposed in [4,3].Interestingly, some recently proposed constructions of cryptographic access control systems pose a similar security concern [1,8,11], though they have been proven to securely enforce the corresponding access control policies within their individual frameworks.
LOWER BOUNDS FOR SECURE CRBAC SYSTEMS.Garrison III et al. studied the practical implications of using cryptography to enforce RBAC policies in their recent work [8].They considered a system model making the necessary use of reference monitors to enforce access control on write access and to maintain the metadata of each file in the file system.For this purpose, they developed two different constructions of cryptographic RBAC systems: one is developed with identity-based encryption (IBE) and identity-based signature (IBS) schemes, while the other one is based on traditional public key cryptography and makes use of public key infrastructure (PKI).In order to analyse construction costs they carried out the simulation over real-world RBAC datasets to generate traces.Their experimental results show that even with the minimum use of reference monitors, the computational costs of the cryptographic RBAC systems supporting the idea of a dynamic policy update are still prohibitively expensive.
Motivated by Garrison III et al.'s work, we study lower bounds for secure cRBAC systems to locate the source of the inefficiency.We show that the costs are inherent in secure cRBAC systems and also in those cryptographic access control systems that greatly or solely rely on cryptographic techniques to enforce access control on both read and write access.The main idea is, since the manager is not involved in any read and write operation in the file system, both the users' local states and the file system should reflect the enforcement of the access control policy.Whenever a policy update occurs, the system may inevitably require re-keying and re-encryption to preserve secure access and system correctness.We present two lower bounds for secure cRBAC systems.Our results can be valuable in the design of such systems for practical purposes.

Notations
For assignment, we write x ← y to denote the assignment of the value y to the variable x.If S is a set, x ←$ S denotes that x is being assigned with a value selected uniformly at random from S. Let A be an algorithm, x ← A(y) denotes the assignment of x with the output of running it on the input y, if A is deterministic, while we write x ←$ A(y) for the assignment, if A is probabilistic.
For any integer n ≥ 0, we write 1 n to denote the string of n 1s.If S is a set, |S| denotes its size.If s is a string, |s| denotes its length.Given two strings s 0 and s 1 , s 0 ∥s 1 denotes their concatenation.ϵ denotes the empty string.⊥ denotes an error, though its meaning depends on the context: it could indicate a decryption error or an error returned by an oracle due to an invalid oracle query.
We say f is a negligible function, if for every positive polynomial p, there exists an integer N such that for all integers n > N , it holds that f (n) < 1 p(n) .

Role-Based Access Control
Role-Based Access Control (RBAC) is one of the most popular access control models adopted in large-scale systems.RBAC introduces the significant concept of roles, which are typically associated to a collection of job functions.Roles allow for specifying access control policies that naturally map the organisation structures and therefore reduce complexity when administering permissions.RBAC policies are decomposed into two assignments: the user-role assignment and the permission-role assignment.A user is authorised to a permission, if a user role has been assigned with the permission.In this paper, we will only focus on core RBAC, as it is the most common between the standard models.
The state of a (core) RBAC system consists of: -U : a finite set of users, -R: a finite set of roles, -O: a finite set of objects, -P : a finite set of permissions, where each permission is an object-operation pair, -UA ⊆ U × R: a relation modelling the user-role assignment, -PA ⊆ P × R: a relation modelling the permission-role assignment, For simplicity we assume that the set of roles R is fixed, since role structures in organisations are less frequent to change.Therefore, the state of an RBAC system over a fixed role set R is a tuple (U, O, P, UA, PA).We describe an RBAC system in terms of a state-transition system.We define the set of state-transition rules RULES as the RBAC administrative commands.Given two states S = (U, O, P, UA, PA) and S ′ = (U ′ , O ′ , P ′ , PA ′ , UA ′ ), there is a transition from S to S ′ with q ∈ RULES denotes S q − → S S ′ , if one of the following conditions holds: An execution of an RBAC system is a finite sequence of transitions S 0 q0 , where S 0 is called the initial state of the RBAC system.We denote the read permission and the write permission of a file o ∈ O by (o, read) and (o, write) respectively.A predicate HasAccess(u, p) reflects that a user u has symbolical access to a permission p.It is defined as follows:

System Model and Syntax
The system model we consider in this paper is the one proposed by Ferrara et al. in [3].In their system model, a versioning append-only file system is employed for enforcing access control on (quasi-) unrestricted read and write access to the files.Hence, the need for online monitors is eliminated.
It should be noted that using a file system of this kind, does not consist a limitation.In contrast, it allows for modelling a general class of access control systems.Since the file system itself does not implement any access control mechanisms and the enforcement of access control policies on files is handled using cryptography solely, it can be used to apprehend data outsourcing scenarios, where hosting trusted reference monitors is impossible.Users may even be able to keep track of files (e.g.storing data on public clouds, repositories, decentralised distributed storage networks, etc.).
We consider a cRBAC system as consisting of three main entities: a manager, a file system and a set of users.
The manager is responsible for the administration of access control policies.More specifically, it is in charge of executing RBAC administrative commands that could involve key management/distribution and data encryption/re-encryption.In contrast to the traditional access control policy enforcer (i.e. the reference monitor) that has to be placed in the critical path to check whether an access request is considered compliant to the policy, the manager is not related to any read and write access to the file system.In addition, the manager is assumed to be a trusted party.
The file system is tasked with storing the files subjected to access control and it is publicly accessible to users.In the implementation phase, the system could contain arrays of encrypted files and the related metadata.The file system is assumed to be untrusted in terms of data privacy, but it guarantees the availability of the data it stores.Consider that if users are provided unrestricted write access to the file system, no amount of cryptographic techniques can prevent a malicious user from overwriting the existing contents.Therefore, the file system is further assumed to be append-only and supporting versioning.In this case, users can only append contents, but cannot delete any.The append operations can be interpreted as logical writes to the files.When reading a file, a user first needs to fetch the file versions and then identifies the most recently "validated" one to retrieve the content.As the data owner, the manager may have richer interfaces to the file system than users.Therefore, it can overwrite the file contents and add/delete files.
Users may have (quasi-) direct and unrestricted read and write access to the file system without involving the manager.Since the enforcement of access control policies solely relies on cryptographic primitives and the file system does not implement any access control functionality, only the users with appropriate keys may get authorised access to the files.
Secure channels are assumed between each of any two entities.For simplicity, the execution of any RBAC administrative command is assumed to be implemented by noninteractive multi-party computations.That is, when executing any RBAC command, the manager carries out a local computation in accordance to the 'update messages' command for users and potentially updates the file system.Following, update messages are sent to the users via secure channels.Once a user receives said message from the manager, it updates its local state accordingly.The file system proceeds with the update in a similar manner.
The global state of a cRBAC system at any point during its execution is a tuple (st M , fs, {st u } u∈U ), where st M is the local state of the manager, fs is the state of the file system and st u is the local state for each user u ∈ U in the system.Since the manager is tasked with the access control policy administration, the symbolic RBAC state S = (U, O, P, UA, PA) is considered to be a part of st M .Let ϕ(st G ) denote the RBAC state of the global state st G .
A cRBAC system is defined by a cRBAC scheme consisting in the following algorithms: -Init, the initialisation algorithm: A probabilistic algorithm that takes the security parameter 1 λ and a set of roles R as input and outputs the initialised global state of the cRBAC system.
-AddUser, DelUser, AddObject, DelObject, AssignUser, DeassignUser, GrantPerm, RevokePerm, the RBAC administrative algorithms: Probabilistic algorithms that implement the corresponding RBAC administrative commands.As mentioned, they are non-interactive multi-party computations.Each of the algorithms takes the state of the manager st M , the state of the file system fs and the additional argument for the command arg as input and outputs the updated state for the manager and the file system as well as a set of update messages {msg u } u∈U for each user u ∈ U .-Read, the read algorithm: A deterministic algorithm that allows a user to retrieve the current content of a file.It takes the local state of a user st u , the current state of the file system fs and a file name o as input and outputs the current content of the file o, if the user has the read permission.If not or if the file is empty, the algorithm returns an error ⊥. -Write, the write algorithm: A probabilistic algorithm that allows a user to write content to a file.It takes the local state of a user st u , the current state of the file system fs, a file name o and the content m as input and outputs the updated file system.-Update, the update algorithm: A deterministic algorithm that takes the local state of a user st u and an update message msg u received from the manager and outputs the updated local state.
A comment should be made about the updated file system, forming the output part of some of the algorithms outlined above.More specifically, the algorithms produce update instructions to be carried out on the file system.For example, after running the Write algorithm, a user will get the update instruction info that includes the information of the file name and also the content to be appended to the file system.Then the user uploads info to the file system and the latter gets updated accordingly.The manager proceeds similarly, but the update instructions might be different from that of the users due to the data owner privilege.For simplicity, we will let those algorithms output the updated file system.In terms of effect, all the above algorithms except Read can potentially update the global state of the cRBAC system.Therefore, we may write the execution of a cRBAC algorithm in the following form: where A is one of the algorithms defined above (except for Read), arg is its arguments, Q is an implementation of the algorithm, st G and st ′ G are the global states of the cRBAC system. Let We write the execution trace of the cRBAC system as: where {st Gi } i∈{0,...,n+1} are global states of the cRBAC system.We say a sequence of operations is efficient, if the length of its execution trace is polynomially bounded.
We also introduce the following two notations P r and O r .P r is the set of objects the read permissions of which a user has been "symbolically" assigned with at a certain point.Let S = (U, O, P, UA, PA) be the RBAC state of a system: P r (S, u) ⇔ {o|HasAccess(u, (o, read))}.
Q r is the set of objects to which a user has "computational" read access, i.e. the objects whose contents can be retrieved by performing the read operations with the user's local state.Consider that some file may be empty (i.e. it contains no content) after the initialisation, while a user may be granted the read permission of that file.Therefore, we define Q r as the set of objects.If any user u ′ with write permissions writes content to them at this point, u will be able to read it.Let st G be the global state of a cRBAC system.Q r is defined as:

Security Definitions
In this section, we present our formal security definitions of correctness, past confidentiality and local correctness for cRBAC systems.

Correctness
Correctness was first proposed by Ferrara et al. in [4], but it was omitted in their later work [3], where a new system model was introduced to support write access.Therefore, we will need to reintroduce the definition of correctness.Intuitively, a cryptographic access control system is said to be correct, if every user in the system can acquire access to the resources to which it is authorised according to the symbolic state of the system.In a cRBAC system enforcing access control on both read and write access to a publicly accessible file system, the correctness requirements are specialised as follows: 1. any user that has the read permission for a file should be able to retrieve the current content of the file by reading it, and 2. the current content of a file written by a user with a write permission will be correctly read by any user with a read permission for the file.
We formalise the two requirements above via a game between a challenger, who acts as a manager of a cRBAC system defined by cRBAC scheme Π and a polynomial-time adversary A that attacks the system.The adversary is allowed to request the manager to execute any RBAC administrative command, such that the symbolic state of the system evolves according to its queries.The adversary can also request a user to write to the file system and to query the current state of the file system.At some point of the game, A needs to show that there exists some user, who cannot correctly retrieve the current content of a file to which it has read access.
More specifically, we define the following experiment Exp corr Π,A .The experiment maintains the symbolic RBAC state of the system State, which is set to be (∅, ∅, ∅, ∅, ∅) initially, and an object-indexed list T to record the contents written to the files by authorised users.
After the initialisation of the cRBAC system with a fixed set of roles R, the adversary can ask for the execution of any RBAC administrative command by calling the oracle CMD.Upon receiving a query that consists of an RBAC command Cmd and its arguments arg, the oracle will execute the command symbolically and run the algorithm Cmd, that implements the command.Then the adversary will be provided the current state of the file system fs as a response.The oracle WRITE allows the adversary to request a user u to write some content m to a specified file o.If u has the write permission of o , the oracle runs the write algorithm Write to carry out the write operation and then sets T [o] ← m.In addition, the adversary can check the current state of the file system by calling the oracle FS with the query "STATE".
In this experiment, the adversary is not allowed to take over any user in the system nor update the file system on its own.At some point, A outputs a user-object pair (u * , o * ) and the experiment terminates here.In the case that u * has the read permission of o * , but the content that it can retrieve from o * by running the read algorithm Read does not match the record in T [o * ], the adversary wins the game.Correctness is defined by requiring that any probabilistic polynomial-time adversary does not win the above game with a probability greater than 0.

Definition 1 (Correctness).
A cRBAC system Π defined by a cRBAC scheme for a fixed set of roles.R is correct if for any probabilistic polynomial-time adversary A, it holds that Adv corr Π,A (λ) := Pr Exp corr Π,A (λ) → true is 0, where the experiment Exp corr Π,A is defined as follows: The oracles O corr that the adversary has access to are specified in Figure 1.

Past confidentiality
In the extended cRBAC system model, the enforcement of access control on write access is supported by employing a versioning file storage, where users can append contents only.The versioning file storage allows users to have (quasi-) unrestricted read and write access to the file system, but it is also accompanied by subtle security issues, though the file system itself does not implement any access control mechanism.One of the security issues relates to unauthorised access to the previous contents.This is a severe security concern in cryptographic access control, but not when it comes to traditional mechanisms.Unfortunately, the existing game-based security definitions for secure read access do not suffice to capture this security concern.We propose a security definition called past confidentiality, which is an improved version of the one presented in [3].The security property is formalised via the following experiment Exp pc Π,A , which proceeds similarly to the experiment that defines read security in [3].However, the adversary here is allowed to corrupt the users, who have the read permission for the challenge files under certain conditions.More specifically, the adversary is not allowed to corrupt any user in a position to read the challenge contents (rather than the challenge files in the read security game), until said challenge contents no longer exist in the file.The adversary's goal is to still determine a random bit b ←$ {0, 1} selected at the beginning of the game.
The experiment maintains the symbolic RBAC state of the system State initialised as (∅, ∅, ∅, ∅, ∅) and updated according to A's request for the execution of RBAC commands.The experiment maintains the following lists during the execution: Cr for the corrupt users, Ch for the files with contents specified as challenges, L for the users who have read access to challenge contents and Ud for the files whose current contents are specified as challenges.
In the experiment, the adversary can request any RBAC administrative command for execution, taking over users and requesting an honest user to write to a file with the content it specifies.The adversary can query the current state of the file system and also write (append) new content to it.A can ask for a challenge by specifying a tuple (u, o, m 0 , m 1 ), where u is a user that has the write permission of the file o, and m 0 and m 1 are two messages of the same length.Then the challenger will carry out Write(st u , o, m b ) and provide the current state of the file system to the adversary as the response.A can ask for multiple challenges.When A terminates with an output b ′ , it wins the game if b ′ = b.
To prevent the adversary from winning the game trivially by corrupting a user, withread access to the challenge contents, the experiment maintains the following invariants: 1.No user in Cr can have read access to any file o in Ud : the adversary is not allowed to request read permission of any file from a corrupt user, if the file's current content is specified as a challenge.
2. No user in the list L can be corrupted: any user with direct access to the challenge contents cannot be taken over by the adversary.
Definition 2 (Past Confidentiality).A cRBAC system Π defined by a cRBAC scheme for a fixed set of roles R is said to preserve past confidentiality, when for any probabilistic polynomial-time adversary A, it holds that is negligible in λ, where the experiment Exp pc Π,A is defined as follows: The oracles O pc that the adversary has access to are specified in Figure 2 and discussed below.
The oracle CMD allows the adversary to request for the execution of any valid RBAC command.When A's query leads to an update to Cr , Ch, L or Ud , the lists get updated accordingly.When a user in L loses the read permission of any file in Ch, the file will be removed from the list L. When A requests to grant an honest user with a read permission for the files in Ud , the user will be added to L.
When the adversary requests from an honest user to write content to a file whose current content is specified as a challenge, the file will be removed from the list Ud .From then on, the file's read permission can be granted to a corrupt user.When A requests to place a challenge by calling the oracle CHALLENGE, the oracle returns an error, if there exists some corrupt user that has read access to the specified file.Otherwise, it carries out the write operation and adds the file to lists Ch and Ud .
Compared to the adversary in the game that defines the read security of a cRBAC system, the adversary in the past confidentiality game is obviously more powerful, as it has the ability to take over users, who can acquire read access to the challenged files under certain restrictions.The following theorem confirms the implication between the two security definitions.Theorem 1. Past confidentiality is strictly stronger than secure read access.
Proof sketch.First, we briefly show that any cRBAC system preserving past confidentiality is secure in terms of read access.Given any adversary A attacking a cRBAC system with respect to read security, an adversary B for past confidentiality can be easily constructed.After the initialisation of the cRBAC system in its own game, B runs a local copy of A with the input of the file system's initial state received from the challenger.Then B starts to simulate the read security game for A with the use of the oracles it has access to.During the simulation, B does not maintain the global state of the cRBAC A wins the simulated game.Therefore, any cRBAC system not secure with read access does not preserve past confidentiality.
In addition, the construction of cRBAC scheme presented in [3] has been proven to be secure with respect to read accessThough it clearly does not preserve past confidentiality, because granting the read permission of any file to a user will allow it to access the previous contents encrypted under the same public key.Therefore, one may conclude that past confidentiality is strictly stronger than secure read access.⊓ ⊔

Local Correctness
The local correctness of a cRBAC system can be considered as a sort of correctness, though it is not implied by correctness.It captures the threat from "insiders" with respect to data availability.The append-only versioning file system allows users to get (quasi-) unrestricted write access to the files, but it also poses a new security concern: a user who has the write permission of a file might be able to invalidate the file's future versions written by authorised users.Local correctness guarantees that these systems thwart.This security requirement is formalised via the following experiment Exp l-corr Π,A that involves an adversary A. The experiment maintains a list Cr to record the corrupt users and another object-indexed list T to record the contents written to files by the honest users.After the initialisation of the cRBAC system, the adversary can request the execution of any RBAC administrative command, taking over any user and writing content to a file on behalf of any honest user.A can also query for the current state of the file system and request to append arbitrary content to it.
Here, the list T serves to record whether the files have been unauthorised touched (rather than authorised write access) or not.When an honest user writes content to a file o, this content is recorded in T [o].If the adversary requests to update the file by appending any entry to it, T [o] will store a special value adv.This means the file has been touched after the previously authorised write access.
The experiment terminates when the adversary outputs auser-object pair (u * , o * ), where u * has the read permission of o * .A wins the game, if the content of o * read by u * is different from the record in T [o * ], while T [o * ] cannot be the special value adv.

Definition 3 (Local Correctness
).A cRBAC system Π defined by a cRBAC scheme for a fixed set of roles R is said to preserve local correctness, if for any probabilistic polynomial-time adversary A, it holds that Adv l-corr Π,A (λ) := Pr Exp l-corr Π,A (λ) → true is negligible in λ, where Exp l-corr Π,A is defined as follows: said file.Since the file system is assumed to preserve the file's correct ordering and the metadata can only be updated by the manager, these two parameters will not be affected by potential corrupt user behaviours to the file system.In case, a different option would be that the predicate encryption scheme or the signature scheme are not correct, therefore the authorised user cannot correctly retrieve the content written to the target file.Thus, we can conclude that the construction preserves local correctness under the assumption that both the predicate encryption scheme and the digital signature are correct.⊓ ⊔ 4 Lower Bounds for secure cRBAC systems In this section, we present two lower bounds for secure cRBAC systems.By lower bounds, we refer to the efficiency implications of secure cRBAC systems.To some extent, our results explain why cRBAC systems supporting dynamic policy updates may be prohibitively expensive: permission revocation can be costly.Prior to presenting our results, we will introduce a technical term called Permission Adjustment for an RBAC system.Informally, permission adjustment is a sequence of administrative commands changing the access rights of some users with respect to a set of permissions.In comparison with any sequence of typical RBAC administrative commands that might not bring any change to the access matrix of the system, permission adjustment emphasises the change it will bring to the access matrix.The term can be better understood using the following example.Consider that a user that has been deassigned from a reviewer role still has access to the conference papers, as the user may also serve as a programme committee member.This allows the user to get authorised access.However, for the permission adjustment of cancelling its access to the papers, the user will no longer be able to do so due to the access control policy change.
Definition 4. (Permission Adjustment) Let S 0 = (U, O, P, UA, PA) be the state of an RBAC system over a set of roles R. Given a set of users Ũ ⊆ U and a set of permissions P ⊆ P , where both Ũ and P are non-empty, a sequence of RBAC administrative commands ⃗ q = (q 0 , ..., q n ) is called a permission adjustment for S 0 with respect to Ũ and P : We denote the set of all possible ⃗ q in case (1) by Ũ ↑ P (S 0 ) and the set of all possible ⃗ q in case (2) by Ũ↓ P (S 0 ).
In addition, we introduce two key properties with respect to efficiency.Definition 5. Let st G = (st M , fs, {st u } u∈U ) be the global state of a cRBAC system over a set of roles R at some point during its execution.Given a sequence of RBAC administrative commands ⃗ q = (q 0 , ..., q n ) and a sequence of efficient operations ⃗ Q = (Q 0 , ..., Q n ) such that for each i ∈ {0, ..., n}: Q i implements the command q i .After carrying out ⃗ Q: (1) if the state of the file system remains unchanged, we say that ⃗ q is file system preserving for st G .It is reflected by the following predicate: ) if the local states of a set of users U remain unchanged, we say that ⃗ q is U-user local state preserving for st G .It is reflected by the following predicate: Finally, we introduce the concept of non-trivial execution for a cRBAC system.A non-trivial execution consists of a sequence of operations such that after executing every operation in order for each file in the system, there should exist at least one user with the read permission for it and at least a user with the write permission for it.The non-trivial execution serves as a mild assumption on the execution of a cRBAC system, for the purpose of studying the lower bound of cRBAC systems commonly used in practice.Also, non-trivial execution can prevent trivial implementations of a cRBAC system.For example, in a cRBAC system with users authorised to read but not write to the file system, there is no need to worry about unauthorised read access, while no content will be written to the file system.The same holds in the case of write security.
Before introducing the lower bounds, we present the following auxiliary results.Lemma 1.For any correct cRBAC system, it holds that: where ⃗ Q an efficient non-trivial execution and ϕ(st ′ G ) = (U, O, P, UA, PA).
Proof.Assume that for a cRBAC system Π, the probability that after carrying out the non-trivial execution ⃗ Q, the system will reach some global state st ′ G such that P r (ϕ(st ′ G ), u) ⊆ Q r (st ′ G , u) holds for every user u ∈ U is ϵ < 1.We show that Π cannot be correct in this case.
Consider the following adversary A for Exp corr Π,A (λ).After the system gets initialised, A is provided λ and then calls the corresponding oracles to carry out ⃗ Q in order.Let st ′ G be the current global state of the system.Now A makes a random guess of a tuple (u, u ′ , o) ∈ U × U × O and also comes up with a message m ∈ {0, 1} λ .It then calls the write oracle WRITE with (u ′ , o, m).If WRITE returns an error, A only terminates here; otherwise A terminates with a (u, o) output.Since ⃗ Q is a finite sequence of opertions, A is an polynomial-time adversary.
By assumption, the probability of a user ū ∈ U and a file ō ∈ O satisfying both o ∈ P r (ϕ(st ′ G ), ū) and o / ∈ Q r (st ′ G , ū) is 1 − ϵ.Since ⃗ Q is a non-trivial execution, the condition o / ∈ Q r (st ′ G , ū) further implies that there exists a user ū′ ∈ U has the write permission of ō such that, if, by this point, the message m is written to ō by ū′ it will not be retrieved correctly by running Read with ū's local state.Therefore, if A made a good guess regarding ū, ō, ū′ , the challenger will not be able to retrieve m.The advantage that A can gain in the experiment is: which is obviously non-zero.Therefore, Π cannot be correct.⊓ ⊔ Lemma 2. If a cRBAC system is secure with respect to read access, it holds that: where ⃗ Q is an efficient non-trivial execution, ϕ(st ′ G ) = (U, O, P, UA, PA) and ϵ is a negligible function in λ.
Proof.Assume that for a cRBAC system Π, the probability that after carrying out the non-trivial execution ⃗ Q, it will reach some global state st ′ G such that for all ϵ, P r (ϕ(st ′ G ), u) ⊇ Q r (st ′ G , u) holds for all u ∈ U with probability ϵ 0 < 1 − ϵ.We show that Π cannot be secure with respect to read access.
Consider the following adversary A for Exp read Π,A (λ).After being provided the security parameter λ, A makes queries to the corresponding oracles to carry out ⃗ Q in order.Let st ′ G be the current global state of Π.Now A randomly chooses a user u ∈ U , a file o ∈ O and another user u ′ ∈ {u|HasAccess(u, (o, write))}.It then requests to corrupt u to obtain the local state st u .Next, A calls the challenge oracle CHALLENGE with (u ′ , o, m 0 , m 1 ), where m 0 , m 1 ∈ {0, 1} λ are two random messages of the same length.If CHALLENGE returns an error, A terminates here and outputs a random bit.If CHALLENGE returns the updated state of the file system fs, A then computes m * ← Read(st u , fs, o).Finally, it outputs 0 if m * = m 0 and 1 if m ′ = m 1 ; otherwise, it only outputs a random bit.Since ⃗ Q is efficient, A is an polynomial-time adversary.
It is possible that u has the read permission of o, because A chose u and o randomly from all existing users and files in the system.Therefore, the request of taking over u might lead to an error returned by CHALLENGE.Notice that A can read the content written to the file specified as its challenge only when there exists a user ū ∈ U and ō ∈ O satisfying both ō / ∈ P r (ϕ(st ′ G ), ū) and ō ∈ Q r (st ′ G , ū), and A has made a good guess of them.In all the other cases, A has to output a random bit.By assumption, such ū and ō exist with probability 1 − ϵ 0 .Then, the advantage that A can gain in the