1. Yitao Duan and John Canny UC Berkeley
Protecting User Data in Ubiquitous Computing: Towards Trustworthy Environments
Yitao Duan and John Canny
UC Berkeley
Good morning. My name is Yitao Duan. From UC Berkeley. I am very glad to have this opportunity to present our paper here. The paper is titled … In this paper we address the issue of user privacy in ubicomp. In particular, we focus on the issue of trustworthiness of a ubicomp environment and protection of user data in such an env. This problem is tricky for reasons we will mention later. But the key factor is that in ubicomp systems the trust relationships between the users and the system is different from that of a traditional system. I will elaborate on this and hopefully it will be clear. In this paper we propose two principle for protecting user data and making the env trustworthiness. We also propose a scheme based on encryption to enforce one of the principles.
I have to say up front that ours is not a complete solution. Rather it is a partial one. It is conditioned upon the assumption that the system is honest. If the server is honest and performs the scheme we described, then user data are safely protected. This model is already applicable in many situations. In the end of the talk I will describe ongoing research work for dealing with untrusted servers.

2. Ubiquitous Computing One consequence of Ubicomp
Way more data about us can be gathered (and used).
This is potentially a great thing for collaborative algorithms
But, it’s potentially a great problem because...
Ubicomp has been envisioned as the new way of interacting and using computer systems. In the future people will be moving around with mobile devices and interacting with microprocessors embedded in the environment. One consequence of Ubicomp is that way more data about users such as their location, their picture, etc., will be gathered and used. This can be a great thing for collaborative applications. However, it can potentially be great problem because of its implication on privacy. The major concern many users have when envisioning such a system is about privacy.

3. Issues Addressed
Protection of the user data generated and maintained by the environment
Privacy of individuals who use the env.
Ability of legitimate users to make use of data recorded in the environment
Dealing with high-speed streams of data
Trustworthiness of the environments (in progress)
In this paper we try to address this concern. We show that ubicomp systems can be built with privacy. In particular, we focus on the protection of the data about the users that are generated and maintained by the environment. There is another types of user data. That is those generated and maintained by the users. The 2nd type is relatively easy to protect. We won’t consider it here. By protecting user data we hope to preserve the privacy of individuals who use the env. Of course any solution has to guarantee the ability of legitimate users to make use of data. Also it has to be efficient to deal with streams of data that arrive at high speed. Finally we consider the case where the env is not trusted, we show possible techniques that can be used to make env trustworthy. This is work in progress.
a number of issues related to ubicomp privacy. propose a solution. The issues we address in this paper

4. Challenges Unfamiliar environments Dynamic and ad hoc and shared
difficult to determine access rights
No central control
High data rate
must be processed in real-time
Collaborative applications
There are a few challenges in ubicomp privacy. First of all as I mentioned earlier, the env are often unfamiliar to the users. The trust relationship between the users and the env is different from that in a traditional system. This may make the user uncomfortable to use the env in the first place. Also the envs are typically dynamic and ad hoc with many users sharing the same env. It is difficult to determine access rights – Data are generated everywhere constantly about multiple users, how could you determine which users should have access to what data? Also the system is distributed, with data caching and replication anywhere. There is no central control, no single point where you can enforce access control. In addition data are streaming at high rate and they have to be processed in realtime. Finally many ubicomp applications are collaborative in nature and they require sharing of data.
All these make it challenging to address the issue of ubicomp privacy.

5. Existing Solutions Focus on access control
Based on authentication/authorization model (e.g. RBAC)
Require a piece of running code to actively check permissions
Inadequate for ubicomp
Dynamic, distributed, environment
Protecting agent can be bypassed
Completely ignored the untrusted env issue
There are existing solutions trying to address the data protection issue in ubicomp. Most focus on access control. They are based on authentication/authorization model that is used extensively in centralized systems and small networks. For example, in the role based access control schemes, each user is assigned one or more roles. When you request a piece of data, the system authenticates you. And if this is successful, the system will check your roles against established policy. If you are authorized to access the data, it gives you access, otherwise you will be denied. This model require a piece of running code to actively check permissions. We argue that it is not adequate for ubicomp. This is because the system is dynamic and distributed and there is no single point where you can run this code. It can be bypassed easily, for example a device or a sensor can be stolen. If that happens, any body can plug the hard disk into another machine and read all the data on it. And this threat is more serious in ubicomp. Also these solutions completely ignored the issue of untrusted env. And we have already shown that the trust relation is different here.

6. Our Approach Not rely on access control Make data secure by themselves
In line with philosophy in cryptography:
Obscurity is not security
Assume the adversary has access to the communication
So we take a different approach. We don’t rely on access control. In stead we make data secure by themselves. We believe this is inline with the philosophy in cryptography. That is, you do not hide data from the adversary. In stead you should always assume that the adversary has access to the communication and all the messages. To achieve privacy, you use encryption.

7. Our Principle – Data Discretion
Data discretion: Users should always have access to, and control of (recorded or live) information that would be available to them in “real-world” situations. They should not have direct access in other situations.
Matches “real-world” privacy norms
Consistent with emerging legal principles
Users are involved in decisions regarding data about them – users are in control of their data!
So we proposed the following principle for designing privacy preserving ubicomp envs. The principle is called Data Discretion. Basically it says …
For example, we are here in this room for the PET workshop. We will be here for a few days. There could be some video recorded about this meet and the data Discretion principle says that we should have access to the video. Because in real world we have already seen all the information that would have been on the tape. On the other hand, after we finish, if there is another meeting in the same room in this hotel, we should not have access to the video recorded about that meeting. Unless of course some of us stay for that meeting.
What this principle tries to dictate is real world norms that we all have accepted and lived with for many years. Computer systems should simulate the real world sith respect to data access.
Also it simplifies policy- making regarding access right.: if you can have access to the information in real world, you should also have access in the virtual world. It doesn’t make sense to deny you access to the data if you already have access to the real thing. A subtlety: info in real world tend to be transient while in digital world tend to be permanent. Seeing someone in some space is not equivalent to having a picture of him. – how do we handle this?

8. Smart room Testbed Good example of ubicomp environment
RFID tag reader to establish who’s in the room
4 cameras to record images
Smartborad to log electronic activity
I will describe a scheme that can be used to enforce the data discretion principle. To make it concrete, let me first introduce the test bed system that we built. We used it to implement a prototype system to experience with our assumptions, techniques etc.
The test bed is a smart room system. It is a small meeting room with a single entrance.

9. Enforcing Scheme
Assume all data are stored in files that represent short time intervals
Data file is encrypted with a unique secret key
Now we have proposed the data discretion principle, we also have devised a scheme to enforce it.
We assume all data are stored in files that represent short time intervals. These could be the images from the cameras, the activity logs from the smartboard.
We use encryption to protect the data and a key embedding scheme to embed the access rights of legitimate users within the data. In this way, data are safe by themselves. You don’t need any running code to check permissions and enforce access control. The data themselves will specify who should be able to access them.

10. Enforcing Scheme
The secret keys are encrypted with public keys of the people in the room (determined by the tag reader):
We must make it clear we don’t enable linking ID to data.

11. Enforcing Scheme
User who were in the room can recover the keys and access the data while they were in the room

12. Key Embedding … … Conceal who and how many users have access
Key set: fixed-length data structure with slots > max number of users in the room
hj1 (Fi, K1)
<Secret Key>K1
hj2 (Fi, K2)
… …
< Secret Key>K2
hjn (Fi, Km)
The scheme described so far can protect the data and grant access only to those who were in the room when the data were recorded. This enforces the data discretion principle we just proposed. However, we need to be careful in actually implementing the scheme. We must make sure the implementation does not leak other sensitive information that will endanger user’s privacy. For example, if you can tell from looking at the data file who has access to it, even though you cannot decrypt it, this information can enable you to determine who were in the room at that time. This is personal information that should not to be leaked to those who were not in the room at that time – again data discretion. Knowing this can enable one to track users location, which is very bad for privacy.
To address this issue, we designed a key embedding scheme to conceal the information about who and how many users have access to this piece of data. We use a structure called key set. It is a fixed-length data structure with a number of slots for storing keys. The number of slots is larger than the max number of users than can be comfortably fitted into the room. Each encrypted key will be stored in a slot, the rest will filled with random numbers. The key set is stored together with the data. To make the search faster when the users are accessing the data, we use a family of hash functions to determine the location in the key set for each user.
Although there are n possible keys associated with each .le, it is not necessary to search through them all in steps 2 and 3. We use a family of n hash functions h1, , hn to perform a pseudo-random search. At step 2, the system places user j’s key in the position specified by one of the hash functions applied to the encrypted .le and the user’s public key. The first hash function which hashes to a free key location is used. If we assume that n is at least twice the maximum number of people in the room at one time, then at least half these locations will be free, and on average only log2m such steps will be needed to find a free location. The same method is used to retrieve the key at step
The info about who have access to the data is also sensitive: if you know who have access, you know who were in the room.
< Secret Key>K3
< Secret Key>K4

13. Master Key Escrow
Every encryption key is also encrypted with a master public key.
The master private key is shared by say, 3 people. Any 2 of the 3 can unlock any of the images, but they have to cooperate.
Sometimes it is necessary for those who are not the owners of the data to access them. They could be the police or the building manager, etc. For this purpose we use a master key escrow scheme. This can be done straightforward using threshold crypto.
This provides good level of protection against misuse of the master key and at the same time provides emergency recoverability of the data. We think it is a good compromise between privacy and safety.

14. General Access Structure
Equal access may not be appropriate in some applications
Can realize general access structure
Secret-share the secret key among users
Embed the shares in the key set
An example: AND access
r1, r2, … rm-1 {0, 1}l, rm = r1 r2…rm-1ks
The scheme described so far grants equal access to all users involved. This may or may not be appropriate in some situations. It means I could have access to your picture if we happen to be together in that space. If that is not acceptable, e.g. in a place where occupants are mutually distrustful.

15. Performance Evaluation
We have implemented a prototype system of the scheme and did a number of tests. We did another test to see how efficient our scheme can process data. We feed the system with streams of files with various sizes.
Execution Time includes: Encryption (Triple-DES) + Disk I/O
Platform: PIII 900MHz + Linux Kernel

16. What We Have Achieved? A principle that mimics real-world norms
A scheme to enforce it
“Zero-knowledge”: cancels even the number of users who have access
Efficient to deal with real-time data
Economical to be implemented using commodity hardware
Data sharing made safe
The encryption does not hinder collaboration [Canny 02]

17. Not Enough The scheme works if the environment is honest
Unfamiliar environments  untrusted environments
How can we be sure the system performs the encryption and does not leak data?

18. Dealing With Untrusted Env – Data Transparency
Data Transparency: Encrypted data recorded or transmitted by a ubicomp system should be easily observable.Where possible, the data itself should demonstrate compliance with stated principles.
To deal with untrusted servers, we propose another principle: Data Transparency
This is the same philosophy in crypto: Obscurity is NOT security
In cryptography, you don’t assume the network or the channels are secure. The reason you make such an assumption is that they are out of your control. Not trusted. In ubicomp, the system is the network.

19. Dealing With Untrusted Env – Data Transparency
Data observable but not comprehensible
Obscurity is NOT security!
Security and privacy based on cryptography, not access control
Makes it easy to verify systems’ compliance with any stated privacy policy
This is the same philosophy in crypto: Obscurity is NOT security

20. Towards Trustworthy Environments (In Progress)
Trusted computing framework
Assume most components untrusted
Some devices (from 3rd party) more trusted
Exploit the mutual distrust between them to build trusted system
Verification
ZKP to guarantee access right
Bit commitment to minimize leakage
How to make the env trustworthy is our current research.
Mutually restrict each other’s behavior. If one deviates from the correct protocol, it will be caught.

21. Prototype – Real-time Data Access
Make it backup??
This transition can be done in realtime. One involves multiple users simultaneously requesting the latest video captures while they are moving in and out
of the room randomly. Our system can detect the changes of their presence in the room on time and react to them with the changes of access rights. Thus the users could see the images while they are in the room but are unable to decrypt them when they are not.

22. What would happen if your picture fell into the wrong hands?
An example of losing control of the data about yourself.

23. Outline Motivation Challenges and existing solution Our approach
Principles
Enforcing scheme
Prototype and evaluation
Ongoing work

24. Langheinrich’s Ubicomp Privacy Principles
Notice
users should always be aware of what data is being collected
Choice and Consent
users should be able to choose whether it is used
Anonymity, Pseudonymity
should apply when identity is not needed
Meeting Expectations
systems should mimic real-world norms
Security
different amounts of protection depending on the situation
Access and Recourse
users should have access to data about them
These are good guidelines for designing privacy preserving ubicomp systems. How to design the system so that these principles are supported is not trivial. For example, how should you lay out the system so that users are always able to make decisions about whether or how the data can be used.
Langheinrich’s principles provide very speci.c guidance for our work.

25. Langheinrich’s Ubicomp Privacy Principles
Choice and Consent
users should be able to choose whether data is used
Meeting Expectations
systems should mimic real-world norms
Access and Recourse
users should have access to data about them
All these say that users should be involved

26. Where Do Your Data Go? … And What Could Happen to Them?
Use a backup?
Imagine you go to a ubicomp env. There will be many data gathering devices around you. They will gather data about you. The data will be transmitted to some server, maybe stored somewhere. And maybe used in some way.
This flow of data flow looks scary for many users and privacy has been a major concern for users to accept ubicomp.
$$$