- Title: Formal Modelling and Automated Trade-Off Analysis of Enforcement Architectures for Cryptographic Access Control in the Cloud
- Authors: Stefano Berlato, Roberto Carbone, Adam J. Lee, Silvio Ranise
Abstract
To facilitate the adoption of cloud by organizations, Cryptographic Access Control (CAC) is the obvious solution to control data sharing among users while preventing partially trusted Cloud Service Providers (CSP) from accessing sensitive data. Indeed, several CAC schemes have been proposed in the literature. Despite their differences, available solutions are based on a common set of entities---e.g., a data storage service or a proxy mediating the access of users to encrypted data---that operate in different (security) domains---e.g., on-premise or the CSP. However, the majority of these CAC schemes assumes a fixed assignment of entities to domains; this has security and usability implications that are not made explicit and can make inappropriate the use of a CAC scheme in certain scenarios with specific trust assumptions and requirements. For instance, assuming that the proxy runs at the premises of the organization avoids the vendor lock-in effect but may give rise to other security concerns (e.g., malicious insiders attackers). To the best of our knowledge, no previous work considers how to select the best possible architecture (i.e., the assignment of entities to domains) to deploy a CAC scheme for the trust assumptions and requirements of a given scenario. In this paper, we propose a methodology to assist administrators in exploring different architectures for the enforcement of CAC schemes in a given scenario. We do this by identifying the possible architectures underlying the CAC schemes available in the literature and formalizing them in simple set theory. This allows us to reduce the problem of selecting the most suitable architectures satisfying a heterogeneous set of trust assumptions and requirements arising from the considered scenario to a decidable Multi-Objective Combinatorial Optimization Problem (MOCOP) for which state-of-the-art solvers can be invoked. Finally, we show how we use the capability of solving the MOCOP to build a prototype tool assisting administrators to preliminary perform a ``What-if'' analysis to explore the trade-offs among the various architectures and then use available standards and tools (such as TOSCA and Cloudify) for automated deployment in multiple CSPs.Complementary Material
Below, you find links to complementary material and additional resources referenced in the paper. Please see the repository for more details on CryptoAC.
Architectural Model
By considering all possible entity-domain pairs that preserves the expected confidentiality, integrity and availability of involved resources, our architectural model is composed of 81 different architectures. The complete list of architectures is available here.
Cloudify Blueprint
We present the Cloudify blueprint we developed for an architecture that we later deployed for the eGovernment scenario. The source code of the Cloudify Blueprint is available here.
Each white rectangle is a node and it represents a cloud service (e.g., security groups, cloud functions). Links are relationships between nodes and are used to control the deployment flow. The blueprint contains three main clusters (blue borders). The cluster on top models the relational database service (i.e., MS, a Relational Database Service in AWS) while the cluster in the middle models the cloud function (i.e., RM, a Lambda function in AWS). The last cluster on the bottom-right corner models the storage service (i.e., DS, a S3 service in AWS). The proxy runs in the users’ computers. Therefore, the proxy is not part of the blueprint.
Fully Working Prototype
We developed a fully working prototype implementing the cryptographic access control scheme developed by Garrison et al.. You can find the source code in the GitHub repository. The prototype was tested with several simulated sequences of operations combining the creation of users and roles, assignment and revoking of permissions and the creation, update and management of files. The prototype offers a user interface based on web technologies and RESTful APIs.
Below, we report four screenshots of the web interface offered by CryptoAC. The first figure presents the login form.
The second figure the home screen; the user is presented with his data and the roles and files he has access to.
The third figure presents a form allowing the user to insert configuration data in the proxy, like the chosen CSP.
The fourth figure contains an example of how the user’s dashboard appears at runtime; the left black sidebar presents the possible actions the user can perform (e.g., if the user is the admin, he/she can add users, roles and manage the AC policy), while the tables list the accessible roles and files.
Web Dashboard
We implemented the Multi-Objective Combinatorial Optimization Problem (MOCOP) in a web dashboard. The dashboard allows selecting the algorithm and metric to use to evaluate architectures and configuring pre-filters. Then, the dashboard allows setting trust assumptions, weights and soft-hard constraints. The optimization problem is solved in real-time and the resulting architectures, along with the effect on the goals, are shown in the last blue section. You can freely interact with the dashboard here.
