Using attribute based credentials for auditable access control

In a recent (dutch) blog post I argued that the latest change in plans for a nationwide eID system in the Netherlands spelled trouble. Instead of the proposed solution I argued that a system using attribute based credentials (ABCs) would be preferable in terms of both security and privacy. One of the solution providers involved in the eID system responded, arguing that using ABCs would in fact be less privacy friendly than the proposed eID system. His argument was that the Dutch eID system would (also) be used to control access to highly sensitive data, like health records, fiscal records, etc. In such systems it is desirable to log all access attempts, to be able to determine after the fact who accessed which records, and whether that was allowed under the circumstances. The untraceability of transactions guaranteed by using ABCs would, according to the author, make this technology therefore unsuitable for such applications. I will show that this argument is false, and that ABCs are perfectly capable of allowing certain transactions to be traced. Unlike the proposed solutions for the Dutch eDI system however, this tracing is only application specific, with the consent and/or explicit knowledge of the user, and not system wide and uncontrolled.

For certain applications it is indeed important to log access attempts. The examples given in the aforementioned blog post are (loosely translated) the following.

• A fired employee suspects that her employer has accessed her medical records. To prove this she would like to have an overview of all accesses (failed and successful) to her medical files.
• A manager suspects that one of his team members who was given delegated rights to act on behalf of the company has abused these rights while accessing certain government services. The manager would like to have an overview of when these delegated rights were used, for what, and by whom.
• If fiscal intermediaries have access to my financial records, because I use their services to help me file my tax returns for example, then I would like to be able to review such accesses to my data.
• If I, as a citizen, have several means or devices (like a phone, tablet, smart card, certificate, identity document, etc.) to sign in to an array of services, I would like to review which means and devices were used to access which services, even if I myself lost control or access to these means and devices. This is useful to detect attempts of identity fraud.

In such cases the logging and auditing of access attempts is sometimes even necessary to protect privacy, but in this case of the people whose personal data is stored in the database, and not of the people trying to access that data. Publicly announcing that all accesses are logged will help deter abuse of such systems, and allows effective enforcement of any remaining abuse.

It is important to note, however, that this logging typically needs to be done within the application itself, because account details associated with access attempts need to be logged together with these attempts themselves. Otherwise, the service provider would need to rely on the cooperation and the accurate bookkeeping of the eID provider to be able to retrieve the personal details of the perpetrators. (One might argue that in certain cases such cooperation by a third party is in fact a feature in order to protect the users of the service from indiscriminate profiling by the service provider. In that case, if the service provider has good arguments why for certain actions it is necessary to be able to recover the responsible actor, a form of identity escrow within the log files can be used that require the cooperation of such a third party in order to decrypt that information. In fact such an 'inspection' feature is implemented in certain ABC systems like ABC4TRUST.)

Recall that in ABC, users carry credentials issued by credential issuers. These credentials are secure containers of attributes that describe certain properties about the user. These attributes cannot be changed or faked, and the issuer is responsible to ensure that the attributes hold for the user when issuing the credential. This means that a service provider that verifies these attributes can be certain that they are valid and apply to the user revealing them.

Now let us consider how each of the examples listed above could be implemented using ABC technology, allowing the service provider to log all access attempts.

In the case of medical records, it makes sense to encode access rights within the attributes of the users. Medical personnel would be issued credentials that contain attributes that encode their role (specialist, nurse, GP, emergency unit). These credentials would also include their name and a registration number that corresponds to the medical register they belong to. To grant access to a record the service provider should request the name, identifier, and medical role from the requester, and store all these three data items with the log of the request. Access is granted based on the role. (This is a very simplified setup used for illustration purposes only. It does not do justice to the many complexities associated with access to medical data. For one thing, it completely ignores the fact that in principle access should only be granted when explicitly consented to by the patient concerned.) In emergency situations anybody with a valid credential that proves his identity can in principle get access: but in this case the name/identity attribute is stored with the access, and the access is always audited to verify that this indeed concerned an emergency for which the access was warranted.

The use case of delegated rights is slightly more tricky, because it depends where and how one wants to review the use of these delegated rights. The principle idea is that employees are given credentials that contain their name, employee number and delegated rights. The simple case occurs when the manager wants to see if someone abused a delegated right at a particular service. Each service asks these attributes to be revealed, and stores the identity of the requester together with the delegated rights thus obtained with the access requests in the log files, which the manager can request (controlled!) access to. If instead, the manager would like to review all uses of delegated rights over all services, it would be unwieldly for him to have to ask all possible service providers for a list of employees using the particular delegated right. One solution would be to create clearinghouses where all service providers collectively forward some information about the access logs, using one clearinghouse per company. Alternatively, delegated rights are not stored as attributes in credentials, but instead a separate (per company) delegation service can provide these rights in an online fashion, after having asked the employee to reveal his name and employee number attribute. Such a setup may also be desirable for attributes that need to be revocable instantaneously, or for attributes that are highly dynamic (and therefore a burden for users to obtain offline each and every time).

For fiscal intermediaries a similar setup like the health records can be used. In this case the required attributes are name, and an attribute proving that a person is indeed a fiscal intermediary. This latter attribute is then used to grant or deny access. (A more fine grained approach would instead allow citizens to designate access to their own records to particular intermediaries. In that case the setup would be similar to the second case above, of a company delegating rights to employees.)

The example of citizens using several means or devices for authentication is rather specific to the envisioned implementation of the national eID system that very much looks like a federated identity management system. Here different identity providers (called authentication providers) each provide a particular means for authentication, that all can be used to access a service under the same account. Trying to map an ABC on this is quite unnatural, so I will not attempt this here. Note that it is in principle possible to store credentials on different 'containers' (like smart phones or different smart cards), to create fall back mechanisms in case one of the containers is lost or broken.

I hope this blog post has made clear that ABCs can be used for applications where transactions (i.e. authentication attempts) must be logged and audited. This despite the untraceability guarantees an ABC provide by default. The trick is to encode identifying attributes in the credentials, require the disclosure of such attributes when asking for access, and storing the revealed attributes together with the access details in the access logs.