Catálogo de publicaciones - libros

This position paper discusses the relation of privacy, namely pseudonymity, to evidence-based trust (or rather reputation). Critical concepts of evidence-based trust/reputation systems are outlined first, followed by an introduction to the four families of the Common Criteria (for security evaluation) Privacy Class: Unobservability, Anonymity, Unlinkability, and Pseudonymity. The paper then discusses the common problem of many papers that narrow the considerations of privacy to anonymity only, and elaborates on the concept of pseudonymity through aspects of evidence storing, attacks and some of their implications, together with other related issues like use of mixes.

Surely as soon as you link two pseudonyms once, then you can’t take that information away from an adversary. But what you said may be theoretically possible if you could prove that you also have another pseudonym that has good reputation without revealing it, which is really I think the property you’re looking for.

We developed a secure processor that protects foreign software running on an open source operating system (OS). The implementation of such a processor has not been reported yet. The processor is called L-MSP (License-controlling Multi-vendor Secure Processor). In this paper, the relationship between software protection and user privacy is discussed. In general, software protection enables secure distributed computing and copyright protection, but the software might violate user privacy. In the L-MSP system, user privacy is able to be protected by security sandbox and related OS mechanisms which is implemented in an open source. Thus transparency of user privacy protection can be assured on the system.

My talk is about secure systems, one particular secure processor, and the relationship between secure processor and privacy protection. We have implemented a secure processor with features consistent with an open operating system and with software protection, where software protection means protection against reverse engineering, I think all kinds of reverse engineering. The second topic is the relationship of secure processor and privacy: I introduce the remote processing model of software protection, and examine the relationship between software protection and the security sandbox which protects user privacy. Finally I will introduce some examples of software protection for law enforcement between anonymous users.

I think it’s important to understand the purpose behind verification before you actually try and design an authentication protocol, because if you don’t know what you’re trying to achieve there’s not really much point.

The contribution of this paper is a mechanism which links authentication to audit using weak identities and takes identity out of the trust management envelope. Although our protocol supports weaker versions of anonymity it is still useful even if anonymity is not required, due to the ability to reduce trust assumptions which it provides. We illustrate the protocol with an example of authorization in a role based access mechanism.

I’m going to start with the point which Dieter finished with yesterday, that Kerberos was originally intended to have three heads. The first was supposed to be an authentication mechanism, next there was supposed to be an authorisation or access control stage, and then there was supposed to be accounting, auditing and that kind of thing. My perception is that we did the first one, and we were half-way through doing the second one when public key cryptography came along. Then we all disappeared down a rabbit hole for twenty years, and we’ve just emerged now. The effect of public key was that we went back and did authentication again, but we never re-did authorisation, or did audit at all. Traditionally the authentication that’s associated with access control is a strong authentication, and it’s linked directly to the authorisation mechanism. The link between access and audit is indirect, and they’re linked via the identity that was used to do the authentication. There’s something not quite right about this. Even if (partial) anonymity isn’t a requirement, when you sit back and look at it dispassionately, it’s not the right way to do it. The fact that this isn’t quite right has some implications for system infrastructure that I want to raise.

Because it is difficult to predict access needs in advance and the limitations of formal policy languages it is difficult to completely define an access control policy ahead of the actual use. We suggest the use of an policy language which allows for override of denied access in some cases for increased flexibility. The overrides should be audited and we suggest that the access control policy can be used for finding the people who should perform the audit.

Last year, the Swedish Prime Minister was stabbed to death in a shopping mall in Stockholm, and of course the police thoroughly investigated it. They had some privacy problems during the investigation: many policemen just looked at the case, because there was no access control on the police system. They didn’t have a whole system on-line, because they cannot really predict the needs of individual policemen, and they cannot really audit the whole thing either because there were so many accesses. In the case of the prime minister we suspect that something was going on because he was a famous person, and they know from experience that this tends to happen with famous people, but in the case of a policemen accessing his neighbour’s data, or something like that, then there is little reason to notice that something is going on.

Of course, conceptually any problem in Computer Science can be solved by adding another level of indirection. But then there is performance to consider . . .