Architectural Considerations for Scalable, Secure, Mobile Computing With Location Information

One-line summary: Describes a suite of useful mobile/ubiquitous apps, some components of a HW/SW infrastructure to support these apps, show how the apps are built on top of the components, and show how component functionality and app semantics change as privacy goals are introduced and as the environment becomes less and less "trusted".

Overview/Main Points

• uni- or multicast message delivery
• scoreboard: display useful location info in "screen saver" form
• find: locate nearby person(s) matching some qualification
• note distribution (e.g. at a meeting)
• AIR (activity-based info retrieval): query a log of everything that has happened to you, helping you remember things by association.
• location: determine someone's location
• visitor guidance
• responsive environment (automatic lighting, doors, etc, as in "ubicomp")

• Sources of location information (GPS, active badge, etc)
• Location Service: answers query about where someone is, or who is at a given loc.
• Terminal agent: interface to I/O device (WS, Tab, etc)
• User agent: collects user's location info, and supplies it to Location Service (LS). Can also directly answer queries from interested parties.

• Locate and FInd can only find persons willing to reveal themselves
• AIR log may not reflect "true" history - some events may be blocked by user agent
• UA-centric arch: Let UA (not LS) apply access controls; it can be as simple or sophisticated as it wants, without pushing this responsibility to centralized LS.
• Trusted escrow service can implement "I'll answer your query if you reveal yourself."
• Secret groups: membership known only to members; access control done by handing out memberships. Eliminates need for escrow.

• Group membership auth: either all group members share some secret, or can construct a "verifier" that can be independently verified by receiver.
• Location auth: entity to be located must possess some unique distinguishing feature, and there must be a trusted sensor that can detect this feature.
• Since these constraints are hard to meet in practice, Locate and Find must treat location info as hints rather than truth.

• Intermediate trusted "address laundering" agent can decouple source/dest address of messages; prevents communication patterns from being leaked.
• Untrusted LS (e.g. in another domain) implies that only a UA-centric arch is practically scalable to large systems.
• Traffic analysis: practically impossible if intruder can observe all traffic and perform arbitrary computations over it; a compromise ("coarse-grained location") can be achieved by sending messages to user by broadcasting it to a slowly changing set of cells covering a large area.

Relevance

• Combination of absolute privacy guarantees together with reliable location-aware apps is impossible because we can't provide authenticated location info for people (as opposed to the devices they carry) and we cannot protect against traffic-analysis attack.
• However, useful apps with reasonable privacy guarantees can be built.
• UA-centric is best for scaling across domains; LS-centric can provide some services better if inside a trusted env.
• Solution is to provide a "moded" heterogeneous environment.

Flaws