A Mobile Crime-reporting Application
To date, great efforts have been made in database security to create systems that enforce restrictions on users' access to data. These advances have yielded some effective solutions that are now common world-wide, such as role-based access control. However, the rise of inside jobs in organisations and some attackers' ability to sidestep authorisation schemes has led to the exploration of ways to further protect databases. Among these has been the encryption of databases.
Database encryption adds another layer of protection to data by making it unreadable to those who do not possess secret information necessary to decipher it. However, with encryption comes not only a negative impact on the database system's performance, but secure key management mechanisms ought to be implemented too. What is more, it is not sufficient to merely encrypt the whole database with a single key and expose all the data when just a subset of it is needed.
Police organisations tend to have a hierarchy of roles, as well as dynamic forming of teams to work on an investigation, for instance. As such, this part of the project aimed to design, develop and evaluate an implementation of an access control scheme that permits hierarchical access to data and that also adapts (grants and removes the necessary privileges) to the dynamic formation of teams in the hierarchy.
A cryptographic access control scheme, CrAC was implemented. Its key features were:
Independent keys
Cryptographic access control schemes are usually designed to act as a chain - that is, using key derivation techniques, people higher up in the hierarchy can derive the encryption keys of those below them. However, this would not work for the dynamic team-forming aspect of the required scheme. As such, independent keys were assigned to each person in the hierarchy, and the different parts of data encrypted under variations of these keys.
Communication of keys
Because independent keys were used to encrypt different parts of the database, the encryption keys had to be communicated to parties that needed to read the data. As such, the access control scheme had to be implemented in a system with a client-server architecture. Requests for and grants of keys were relayed by the server from and to the relevant officials.
To evaluate the scheme's performance, a non-cryptographic equivalent was implemented using SQL's standard privilege administration constructs (granting and revoking rights). A small simulation of a typical police organisation's information system was developed, with the design being informed by the system used at the offices of the University of Cape Town's Campus Protection Services. The metrics used to gauge CrAC's performance were the speed of query execution and latency.
As expected, results to queries were produced more slowly in the system that used CrAC. In some cases, a query that took 200ms to execute in the non-cryptographic system completed execution in a second in the other system - about four times longer.
With regard to latency, the cryptographic scheme also took much longer than the non-cryptographic one to return the system to a state of every person in the hierarchy having the correct access permissions after a change to the hierarchy had been made (for example, removing a person from the hierarchy or from a team). What was only a dynamic update of views in the non-cryptographic scheme translated to re-encryption of several records in the cryptographic scheme, and this impacted the scheme's performance negatively.
While CrAC seems to perform poorly, the security it offers is better than that given by the non-cryptographic scheme implemented. Using encryption is effective in solving the problem highlighted in the overview, namely, unauthorised viewers both within and outside the organisation. As such, improving and optimising CrAC (for example, finding a way to allow key exchanges even when the owners of the keys are not logged in) is a worthwhile venture.