Infrastructure for Smart Devices -- How to Make Ubiquity an Actuality Panel Discussion on Security and Privacy -- Opening statement Pekka Nikander Ericsson Research http://www.iki.fi/~pnr/ What is different in Ubicomp security, if anything? Basically, in my opinion, there are three issues which change the fundamentals of security in Ubicomp, when compared to more traditional forms of computing. These three issues can be given rough titles of trust management, handling of denial-of-service, and privacy. In this opening statement I do not cover denial-of-service, but the other two areas are briefly covered. It should be noted that the background for these differences lie in the technical infrastructure: in ubicomp, everything is assumed to be both instrumented and networked. And it is exactly this combination of ubiquitous instrumentation and networking that does makes these existing security problems much harder and more pervasive than in more traditional systems. Thus, first, when I use the term "trust management", I basically use the term in the sense Matt Blaze of AT&T introduced in 1996 in his PolicyMaker paper. Current example systems of the technology include SPKI and KeyNote2, both more or less being standardized at the IETF. These technologies provide a number of features that are very desirable for ubicomp, including "anonymous authentication", decentralization, possiblity to use the technology to manage policies, and the fact that the techniques are based on (semi)anonymous credentials, not identities. In the area of trust management, there are a number of hard problems. These include the following. - bootstrapping, or creating initial trust relationships - trusted devices, e.g. Smartcards, PDAs, or CellPhones - situational trust The second imporant point is privacy. The ubiquitous networking of all kinds of devices makes it fundametally easier to track people and devices, unless care is taken in the systems design. Even though people might not care so much about their privacy at the "application level", i.e., when doing electronic commerce and such, I am inclined to think that most people are at least somewhat sensitive when it comes to things like their blood pressure, body temperature, surrounding temperature, or even exact location and sosial surroundings. Thus, I feel that that at least rudimentary privacy is needed since people want it. One of the reasons for this is that we do not know about the stability of the political system. Another, maybe more blatant reason is that if you want to sell your privacy, you cannot have lost it. Thus, privacy must and can be engineered in the systems. It is not only an application level issue but very much a network level issue. Engineering systems that preserve privacy is not that expensive if properly engineered in, but it must be integral part of initial systems design, even more integral than other aspect of security. It really cannot be patched on afterwards. The basic technical issue in network level privacy is the usage of identifiers. We must never use long term public indentifiers, but instead protect out long term identifies with cryptographic means, e.g., Diffie-Hellman. Care must be taken when considering the feasibility and resource concumption of tracking people, i.e. we should make it _expensive_ to track individual persons, even if we probably cannot make if impossible due to legistlation. Thus, as a summary, - we _do_ need to worry about identifiers - we _do_ want to protect your long term identity, i.e., keys - we don't need to worry about your short term identifiers, we can (and must) change them, and they are hard to track anyway