Using attribute based credentials for auditable access control

February 18, 2015

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.

In case you spot any errors on this page, please notify me!
Or, leave a comment.
Martijn Kaag
, 2015-02-18 15:25:40

Dear Jan Jaap,

As the author of the blog you respond to, I am very happy with your post, because you proof the point I made in my original post.

Your proposed solution for medical transactions has the same privacy properties and the main difference it that you put the burden on each and every service provider, wheres eID offers this out-of-the-box.

> One solution would be to create clearinghouses where all service providers collectively forward some information about the access logs

The privacy concern you have with respect to eID also apply to this solution! Again you have a third party that can see all your transactions, in this case a clearinghouse. I am happy that you agree that this is required in an network of thousands of (e.g. medical) applications.

> using one clearinghouse per company.

This is, in fact, the solution we envision in eID and it is enabled by default.

> Alternatively, delegated rights are not stored as attributes in credentials, but instead a separate (…) for attributes that are highly dynamic (and therefore a burden for users to obtain offline each and every time).

You are describing the claims provider (machtigingenregister) in eID here! Works exactly the same and only after user consent.

> Here different identity providers (…) to create fall back mechanisms in case one of the containers is lost or broken.

The strong point of eRecognition is that it is technology agnostic. If the card I use for logging in turns out to be insecure (remember OV Chipcard?) I have alternative technologies available in the same infrastructure.

Again, I do not see how your solution and eID are competing technologies. eID should not be used for the problem domain you want to use IRMA for and vice versa. I know that eID is claiming that eID should be used for 18+, but I disagree. There is no one size fits all.


, 2015-02-18 15:46:15

Dear Martijn,

Interesting. I would actually argue exactly the opposite, namely that I disprove the point you make in your post, and instead show that ABCs protect privacy better than eRecognition, and that in fact ABCs can be used for all the scenario’s that you claim it cannot be used for.

It does not make sense to have two different, parallel, systems for eID as you seem to suggest: one (ABC based) for so-called 18+ scenario’s and another (federated IDM based) for all other scenario’s. Moreover, the fact that eRecognition provides traceability out of the box is exactly the reason why I strongly oppose the current proposals for using that technology for a nationwide eID system. The Dutch eID system has to respect the privacy of Dutch citizens by design and default. For the simple reason that the system is mandatory for accessing all kinds of government services, and that citizens simply have no choice. The fact that for certain applications some level of tracing and logging is required is no excuse to implement it is as standard (and without any option to switch it off).

Martijn Kaag
, 2015-02-25 08:56:12

Dear Jan Jaap,

I notice that there are two extreme standpoints here:

  • eID claiming that federation is the answer to everything.
  • You claiming that IMRA is the answer to everything.

Both parties neglect the weaknesses of their own solution and fail to see the strong points of the other solution.

I disagree that there is on size fits all.

  • eID has not been designed for applications that require no aggregated tracing and logging. Within the domain it has been designed for it provides at least the same privacy as the alternatives and has important features such as technology neutrality which guarantees long-term continuity.
  • IMRA has not been designed for applications that require aggregated tracing and logging.

Both solutions have their strong-points and they can co-exist is the same infrastructure.

eID has tried to combine the two approaches into one (full privacy of transactions with a federated infrastructure) but the result failed at all ends:

  • No aggregated tracing and logging.
  • No technical guarantees on privacy.

The disagreement between you and eID is becoming religious. That stops all progress and a waste of intellectual resources.