COGENERACIÓN CON UN MOTOR DE COMBUSTIÓN INTERNA

We define privacy risk, or privacy threat, as a measure of the possibility that private data, which is desired to stay private, is revealed without the owner having the ability to prevent this. A Privacy leak is defined as any

Pervasive Systems: Enhancing Trust Negotiation with Privacy Support 27 unintentional disclosure of private data, either as a consequence of negli- gence, weak privacy provision methods, or capability to compromise these. Thus, any leak is also a threat, fulfilled threat, and it depends on de- gree of information leaked how big threat it is.

The main goal of the trust negotiation process described above is to grant the supplicant access to the requested resource. The very fact that sensitive attributes are revealed during the negotiation process calls for at- tention, in fact under certain conditions even access control policies can be regarded as private or sensitive information that needs to be handled with special care.

Apart from the straightforward disclosure of private information during manipulation, privacy can be at risk in a far more indirect and opaque sense. Pervasive environments make information processing highly inten- sive and penetrating and can render small pieces of information which can be stepping stones to the disclosure of greater secrets. Quite naturally, a large amount of personal information will already be available to systems in the pervasive environment after a longer period of use of the system. Al- though data have probably been made adequately anonymous as far as possible (compare methods for pseudonymizing in [7] or the virtual iden- tity approach in [9]), inference capabilities of a pervasive environment can aid in correlating sets of anonymous data with each other. This can make aggregating correlated data possible and resolving personal profiles to an extent where it is finally unambiguous in relation to one unique person. This possibility is called linkability of (anonymous) personal information. We want to avoid this is the effect by all means and aggravating this is one of the major concerns of identity management systems in a pervasive envi- ronment (compare again [7, 9]). For this reason we compare the pervasive environment to the example of a chaotic dynamic system with respect to the degree and significance of information disclosed over time. Any in- formation available can consequently result in a disclosure of certain pri- vate data which was not intended in the first place – thereby resulting in a privacy leak. The measures taken to prevent linkability can therefore never be exaggerated and every procedure involved in disclosing private data has to be evaluated from this viewpoint.

In this section we study weaknesses of the described trust negotiation methods that can lead to privacy leaks in the sense of the straightforward disclosure of private data, for example disclosing a sensitive credential, or due to linkability. Some of the weaknesses have already been discussed in literature [4] and some of them reflect our original work. The related leaks and threats pertain to supplier as well as to supplicant, especially straight- forward disclosure. But while the supplier is often (but not necessary) a publicly known entity, it is characteristic for the supplicant to focus more

28 Porekar et al.

relative importance on maintaining anonymity and thus linking is of more threat to supplicant.

Disclosing credentials could be a privacy risk. When the supplicant is requested to disclose certain credentials during the negotiation, it may re- act to the request in various ways. If the credential is not valuable enough to the supplicant in the context of the current negotiation, the supplicant may choose to willingly present the credential without much hassle. An example of such a negotiation situation would the case where a supplicant is trying to buy a camera from an online store and he gets offered a dis- count if he is willing to present credentials that prove that they are a citizen of the European Union. If user is not concerned with anyone finding out that he or she is indeed a citizen of EU, disclosing the credential results in minimal privacy threat. On the other hand if a British Secret Service agent is asked to provide an MI5 membership credential in order to get discount on a camera he is trying to buy, it is a obviously a different matter. MI5 membership credentials is sensitive information that is not to be shown to just anyone and disclosing it could be a serious privacy risk, thus high- lighting another category of linking private data.

Obviously a disclosure of credentials is a potential privacy leak. But the answer to the request for certain credentials can also potentially yield in- formation. An example of such an information leak would be that of a supplier requesting a supplicant present an “MI5 Membership Credential”. In order for the supplicant to determine if the supplier is trusted enough, the supplicant asks the supplier to provide the “Ring of Secret Service trusted Membership” credential. When the supplier receives the additional request from the supplicant it can assume with a certain degree of prob- ability that the supplicant possesses the credential that was requested in the first place. The amount of probability depends on different negotiation strategies that supplicant chooses to pursue and his ability to bluff.

Not disclosing credentials could in some cases also yield useful infor- mation for linking. The sole fact that the supplicant has attempted to access a supplier resource could limit the scope of possible supplicants. Creden- tials may indicate that the supplicant belongs to one of two mutually dis- closing classes of supplicants. Inability to provide the requested credential, either due to disagreement or failing to posses one, could also enable the supplier to categorise the supplicant and thus to help linking of data in the future.

Disclosing access control policies could be a privacy risk. When a supplier is asked to grant access to the requested resource it can provide the feedback about requested credentials back to the supplicant in many

Pervasive Systems: Enhancing Trust Negotiation with Privacy Support 29 different ways. If the supplier has its access control policies on public display, it is fully acceptable for it to return the whole policy back to the supplicant. Afterwards the supplicant accepts can then navigate through many parallel options in order to find the combinations of credential dis- closures that are optimal for him. While this is fully acceptable if the supplier is a governmental organisation that provides its services to citi- zens and has published access control policies; it is not the case when a supplier is a service providing sensitive resources. For example if a sup- plier is a server of the British Secret Service, which is providing sensitive top-secret data to its agents on the road it will not publish its policies to the public, since the policies contain valuable data on the organisational hierarchy of the supplier, and revealing the policies would provide valu- able information which could be potentially misused. Instead, the sup- plier will try to minimize the amount of information provided at each step of negotiation by requesting one credential after the other or maybe choosing not to provide information detailing which credentials should be disclosed to the user at all.

Exploiting negotiation to steal private data – trust negotiation piracy. With careful design of trust negotiation algorithms it can be possible to exploit the trust negotiation protocol to serve private information under pretext of a legal purport. The purport is more likely to be abused by a supplier role in the context of a service provider with a range of services, promised large enough to relate to a wide scope of interesting categories about supplicants. Consider following example.

The supplier is a service offering bets in several categories, depending on the supplicant profile. The supplicant is provided a possibility to apply for the service as a pseudonymous user with its true identity hidden. Systems for auditing in a pervasive platform architecture make non-repudiation of debts possible (compare [10] for example). Although the service might actually provide what it has claimed to provide (it has also been certified so), let us suppose that it also has the intention to aggregate the profile information of supplicants in order to (at least partially) determine their identity. The hand- shaking could possibly proceed as follows:

1. Supplicant: accesses the service web portal.

2. Supplier: “We offer several categories for bets: bets on the outcome of sport events, bets on the outcome of political events, bets on the results of science research … Select your interest …”

30 Porekar et al.

4. Supplier: “Which event from following: the outcome of upcoming elections, …, the outcome of the acceptance of last week’s formal proposal for amendment to act 26.8/2005, …”

5. Supplicant: chooses an event.

6. Supplier: demands a credential that supplicant’s age is above 18. 7. Supplicant: demands credential that supplier will not use this

information for any other purpose than service provisioning. 8. Supplier: provides the credential.

9. Supplicant: provides the credential.

10. Supplier: “We only allow bets above 1.000,00 € for this category.” Demands a credential on supplicant’s financial liability.

11. Supplicant: demands credential that supplier will not use this information for any other purpose than service provisioning. Supplicant: provides the credential.

12. Supplier: provides the credential. 13. Supplicant: provides the credential.

14. Supplier: demands a credential that supplicant is not employed in a state department service. The supplier imposes the restriction based on the fact that access to privileged information would help to win bets, and is not allowed.

15. Supplicant: withdraws.

If we analyze the above sequence we can figure out that supplier could de- liberately design categories to address classes of people and their interest. When the supplicant has revealed his interest via selection in step 3, the supplier can then assign the supplicant to this category. Further suppose that the supplicant designed events according to increasing political awareness, as carefully as it can imply certain political skills and positions. Then selection under step 5 further scopes the category.

After step 5 the true exchange of credentials in the sense of trust nego- tiation starts. The resource here negotiated for is a betting account on a re- spective event. After each credential is received, the supplicant can deter- mine a more focused scope of potential persons satisfying specific attributes: age, financial profile and associated implications … And finally, the supplicant can also determine why a supplicant has withdrawn – possi- ble causes could involve people with significant political positions. More- over, the sequence could be designed as to gradually lead the supplicant through the disclosure of credentials with less privacy threat, and then to present requests for credentials with higher threat so that many credentials will have already been disclosed before the supplicant finally refuses to make further disclosures and withdraws.

Similar services already exist in today’s Internet world and there is no reason to think that such scenarios would not appear in a pervasive

Pervasive Systems: Enhancing Trust Negotiation with Privacy Support 31 environment. The supplier could have sophisticated systems for reason- ing in place, as this is not unusual aspect of pervasive system capabili- ties. If we assume an appropriate degree of information processing and a large enough period of time, the supplier can deduce information about people concerning their bets, their financial status, and their in- terests – and can enable the linking of this information to real persons and then use this for blackmailing and other illegal activities. With this in mind, the above resolutions are not really unbelievable.

The first weakness of trust negotiation apparent from the above example is that disclosing interest in step 3 and 5 is not included in trust negotia- tion. If we consider that in pervasive systems it will be practically impos- sible for a supplicant to perform or even only supervise privacy related procedures because of the high degree of information exchanged in very short time periods, trust negotiation and the remaining subsequent en- forcement has to be done in a computer aided manner. The supplicant will rely on the privacy subsystem in order to have privacy adequately main- tained. Disclosure of this kind of information as in steps 3 and 5 was done willingly, but supplicant software components were not given the chance to evaluate the consequences and make this subject to identity manage- ment. Thus this could represent a privacy threat and allow future privacy leaks. General terms about the attitude towards abstract notions of disclos- ing, as for example a specific interest, which needs to be identified in the overall negotiation and provided for processing to enforcement systems. For example, this is necessary for identity management if it should be able to extract information on how big a threat of linking is with respect to the disclosed interest and what virtual (or partial) identity should be selected.

The second weakness is that at the end of the above sequence the sup- plicant didn’t get access to the resource, but has still revealed quite a large amount of personal information. Trust negotiation cannot happen in pure general terms arguing on meaning of resources and credentials in advance. By applying purely general terms of negotiation we could resolve colli- sions in attitudes of supplier and supplicant before any resources or cre- dentials are disclosed, and thus supplier is left only information about sup- plicant attitudes, while credentials were preserved.