Back to index
Architectural Considerations for Scalable, Secure, Mobile Computing With
Mike Spreitzer and Marvin Theimer, Xerox PARC
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".
Some mobile apps to consider:
The baseline architecture:
- 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
- location: determine someone's location
- visitor guidance
- responsive environment (automatic lighting, doors, etc, as in
It should be pretty obvious how to build the desired apps given these
components in a trusted environment.
Adding privacy (each user can choose whom to reveal location info to):
- 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
Working in the presence of lying programs but trusted infrastructure:
- 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
- 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.
Insecure infrastructure or location service (e.g. cross-domain):
- 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.
- 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
- 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.
A high-level issues paper, not really an architecture paper.
Back to index