Pervasive Computing Security - About me | Rene · PDF file · 2007-08-062007-08-03 Pervasive Computing Security 1 ... human-verifiable authentication with personal mobile device ...

2007-08-03 Pervasive Computing Security

1

Pervasive Computing Security

BaCaTeC Summer School: Pervasive Healthcare Systems3. August 2007, 11:00

Rene MayrhoferLancaster University, UK

2007-08-03 Pervasive Computing Security 2

Security in Pervasive Computing

● Security is currently one of the largest problems in computer science (not the only one though...)

● Possible reason: often added as an after-thought

● Examples of large-scale security problems: Blaster (2003), Sasser (2004), Phishing/Pharming (2005ff)

● Security issues in server- and desktop-based computing already have a large impact on real life: ATM machines, UK coast guard, private online banking, …

● Ubiquitous/pervasive computing aims to embed computer systems into objects of the real world, transparently, networked, and – most of the time – invisible

● Many projects mention that “security will be added in future research”


● Privacy is the user ability to control what happens to personal information

● Security is a necessary building block for privacy, but is not sufficient

● Privacy needs organizational, legal, and social measures!

„When making public policy decisions about new technologies for the Government, I think one should ask oneself which technologies would best strengthen the hand of a police state. Then, do not allow the Government to deploy those technologies. This is simply a matter of good civic hygiene.“

(Phil Zimmerman, author of PGP, to the congress of the US)

Security vs. Privacy

Aspects of SecurityPervasive Computing and Security

ApproachesSpecific Projects

PrivacyTerminology and basic requirementsPrimitivesAuthentication


Usual security requirements:

● Secrecy/confidentiality (prevent unauthorised reading)

● Integrity (prevent unrecognised modification)

● Authenticity (prevent impersonation)

● Non-repudiability (authenticity to third parties)

Additional terms:

● Identification

● Authentication

● Authorisation

● Availability

Basic computer security terminology





Encryption solves the requirement of secrecy

Digital signature and cryptographic hashes solve the requirement of integrity

● Cryptography can provide technical solutions to secrecy and integrity, but for authenticity (and non-repudiability), we need authentication

● Remark: identification, authorisation, and availability can only be considered in conjunction with social, organisational, and legal aspects

Basic computer security terminology




Sender RecipientLorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. …

5210B0385B39746325FCB1BC15D36D85117B021EE41FC1ACC95DE4AC4365A5210B085B377463225FCB1B15D36D85C117B02 …

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. …


41FC1ACC95DE4AC436 5A5210B08

Sender RecipientLorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. …



Identification vs. Authentication

● Typical systems: first identify subject (username), then authenticate identity (password)

● But: authentication does not require unique identification ⇒ anonymous or pseudonymous communication⇒ one possibility to improve user privacy

● For pervasive computing most of the time unimportant how the service is called, only want to use it!

– Physical identities matter more than network identities

– Identities difficult with different realms of administration

Authentication is a basic requirement





● Which subject should be authenticated?

– user

– device

– action

● Which property?⇒ depends on the subject

● Users

– what I know (password)

– what I have (token, smart card)

– what I am (fingerprint, iris)

What to authenticate?





● Pervasive computing builds upon the notion of context

● Users

– what I know (password)

– what I have (token, smart card)

– what I am (finger print, iris)

– where I am

– what I am doing

– who is with me

– what I ate

– how I feel

– ...

What to authenticate?




(hopefully not...)

(hopefully not...)


If security and/or privacy and usability collide, then usability always wins!

Most important aspect: Usability




● When security methods or implications on users' privacy are not properly understood, systems will be used incorrectly

● Annoying and obtrusive security measures are simply deactivated so that users can get their jobs done

● For example:

– sharing passwords, never logging out

– writing PIN on back of card, most often used PINs “1234” and “0000”

– “ALERT: The URL says www.mybank.com, but the certificate is for cracker.net, really continue?” - “Yeah, whatever, just let me enter my PIN and TAN codes now...”




Difference to desktop-based securityWhy not standard approaches? - main issuesAdditional issues

Pervasive Computing: What is different?





Pervasive Computing: What is different?

● Wireless communication

● Small devices

– restricted user interfaces

– limited resources (battery life!)

● Many devices

– integrated into physical objects

– communicate among each other

– many devices communicate with one user

● Sensors

⇒ Devices and communication become invisible, unverifiable, and uncontrollable


Main issue 1: Wireless communication is insecure

● Potential attacker can

– eavesdrop

– modify

– remove

– insert

● Especially problematic for spontaneous interaction: no a priori information about communication partners available

⇒ User needs to establish shared secret between devices

Wireless communication





Secret key exchange over wireless channels

● Can use Diffie-Hellman (DH) for key agreement

● Problem of Man-in-the-Middle (MITM) attacks:

⇒ Secret keys need to be authenticated

Why is wireless a problem?





Options for authentication

● Entering PINs (e.g. Bluetooth), passwords (e.g. WEP/WPA)

● Verifying hashes of public keys (e.g. web site certificates)

Main issue 2: Lack of powerful user interfaces

● A headset doesn't have a classical user interface (display + keypad)

User interfaces





Main issue 3: User attention does not scale

● Vision of ubiquitous computing: using hundreds of services each day, seamlessly embedded into daily live, spontaneous usage, different realms of control

● Who would like to enter passwords or biometric data into each of them?

General approach: using trusted personal devices

● A personal device for each user (2006: 478.4 million mobile phones in the EU, 108% mobile phones rate in Austria [DerStandard.at, 2007/03/30])

● Important: personal device device may be trusted, but wireless connections are not ⇒ human-verifiable authentication

And somebody needs to do it...





● Mobile devices

– attacker may have physical access to device

– losing devices ⇒ losing keys/access/money? (revocation issues)

– different security levels of environment

● Privacy

– which sensors record what about whom, when, and who has access?

– what can a personal, trusted, mobile device reveal about its owner?

● Physical replacement, matching physical with virtual entities

● Side-channel attacks

● Understanding how the whole system works (mental models)

What else is difficult?





Issues

● wireless

● spontaneous interaction

● restricted user interfaces

● scalability

Approaches

● authentication

● peer-to-peer, context

● human-verifiable authentication with personal mobile device

What needs to be solved?



SummaryPersonal device authenticationOut-of-band channelsSensor-based/context authentication


Trusting your mobile phone




● User authentication works well for the “1:1” (one user, one device) and “n:1” (many users, one device) cases, i.e. for typical server- and desktop-computing

● But: scales poorly for the “1:n” (one user, many devices) approach that pervasive computing is proclaiming

● Intuitive alternative to direct user authentication: a trusted personal device that authenticates its user once (e.g. when being switched on) and is assumed to be owned and used by a single user:

– comparable to conventional key chain

– mobile phone, wrist watch, etc.

Advantage: unobtrusive, scales well to many devices

Challenges: this device must be physically secure

● Authentication is thus shifted from user-to-device to device-to-device


How to authenticate devices?




First suggestion: direct electrical contact [F. Stajano: “Security for Ubiquitous Computing”, Wiley]

but: ...

● direct electrical contact is fragile and wears out

● is often infeasible because of distances


Wireless is not enough

Typical approach for secure channel setup:

● Key agreement: typically select peer device + Diffie-Hellman

● Peer authentication: various options

– commitment schemes

– interlock-based protocols

● Verification based on some out-of-band channel

– verification of key hashes: display+user+yes/no

– transmission over secret and/or authentic channel: display+user+keypad, infrared, ultrasound, laser, display+camera, audio, NFC, ...

– shared secret: common data, possibly “fuzzy”





One out-of-band channel won't do either...

Different scenarios in which authentication is required, examples:

● Home environment

– pair new TV set with existing universal remote control

– associate borrowed Bluetooth headset with mobile phone for a single call

– allow guests to temporarily access (parts of) music and video collection, and to use TV set to remotely access their own collection from their home

● Untrusted environment

– use public printer or user interface terminal to enhance personal mobile device capabilities (think of building-size public displays)

– use personal device as electronic wallet

– direct transfer of data between two (or multiple) personal devices with different owners





Security properties of out-of-band channels

Out-of-band channels can be

● confidential

● authentic

● provide partial integrity

or any combination





Recent protocol proposals

● “MANA I-III” (display/keypad) [C. Gehrmann, C. J. Mitchell, and K. Nyberg: “Manual authentication for wireless devices”, RSA Cryptobytes 7, 2004]

● Balfanz “pre-authentication” [D. Balfanz, D. K. Smetters, P. Stewart, H. C. Wong: “Talking to Strangers: Authentication in Ad-Hoc Wireless Networks”, NDSS 2002]

● Hoepman “ephemeral key exchange φKE” [J.-H. Hoepman: “The Emphemeral Pairing Problem”, Financial Cryptography, 2004]

● Vaudenay “SAS” [S. Vaudenay: “Secure Communications over Insecure Channels Based on Short Authenticated Strings”, CRYPTO 2005]

➔ MANA IV family of protocols [S. Laur and K. Nyberg: “Efficient Mutual Data Authentication Using Manually Authenticated Strings”, CANS 2006]





Recent protocol proposals: standards

● Bluetooth pairing in current standard and WEP are completely broken[Y. Shaked and A. Wool: “Cracking the Bluetooth PIN”, Mobisys 2005][F.-L. Wong, F. Stajano, and J. Clulow: “Repairing the Bluetooth pairing protocol”, Security Protocols 2005][E. Tews, R.-P. Weinmann, and A. Pyshkin: “Breaking 104 bit WEP in less than 60 seconds”, Cryptology ePrint Archive 2007/120]

● Bluetooth Simple Pairing [Bluetooth SIG: Simple Pairing Whitepaper, 2006]

– “just works” - insecure against MITM

– “numeric comparison” of six digit number, yes/no on both devices

– “out of band” e.g. with NFC

– “passkey entry” with transferring a six digit number (human as out-of-band channel)

● Wi-Fi Protected Setup

– “push button configuration” - insecure against MITM

– “PIN” with four to eight digit number

– “out-of-band” e.g. with NFC





Usability analysis are slowly being done...

● Good summary of recent protocol proposals and initial protocol taxonomy[J. Suomalainen, J. Valkonen, and N. Asokan: “Security Associations in Personal Networks: A Comparative Analysis”, ESAS 2007]

● Usability analysis for Bluetooth Simple Pairing and Wi-Fi Protected Setup [C. Kuo, J. Walker, and A. Perrig: “Low-cost Manufacturing, Usability, and Security: An Analysis of Bluetooth Simple Pairing and Wi-Fi Protected Setup”, USEC 2007]

● More general usability analysis on security in pervasive computing [E. Uzun, K. Karvonen, and N. Asokan: “Usability Analysis of Secure Pairing Methods”, USEC 2007][T. Kindberg, A. Sellen, and E. Geelhoed: “Security and Trust in Mobile Interactions: A Study of Users' Perceptions and Reasoning”, HP Labs Techreport HPL-2004-113][D. Balfanz, G. Durfee, R. E. Grinter, and D.K. Smetters: “In Search of Usable Security: Five Lessons from the Field”, IEEE Security&Privacy 2(5), 2004]

● Common issues:

– small and/or non-representative group of subjects

– bias/obvious results





Context-based authentication

● main threat scenario: MITM on wireless communication channel

● intended communication partners A and B share some context

● attacker E has inferior access to this context

● respective aspect of context represented by sensor data streams ⇒ shared (weakly) secret information





Context-based authentication

● We can define context authentication as:

A group of devices is authenticated with each other when certain aspects of their context match.

● Appropriate sensors to ensure that two or more devices are in common context

● Tim Kindberg et al: Concept of “constrained channel”:[T. Kindberg, K. Zhang, N. Shankar: “Context Authentication Using Constrained Channels”, WMCSA 2002]

– channels that are restricted by contextual constraints

– either send- or receive-constrained

● Dirk Balfanz et al: “location-limited channel”:[D. Balfanz, D. K. Smetters, P. Stewart, H. C. Wong: “Talking to Strangers: Authentication in Ad-Hoc Wireless Networks”, NDSS 2002}

– requires “demonstrative identification”: identification based on physical context (i.e. location)

– requires authenticity of channel





Location/position as context

Conventional methods:

● GPS

● other RF time of flight/signal strength (e.g. GSM)

● ultra sound

Methods depending more on qualitative than on quantitative factors:

● visible light (laser, but also LED/display and camera)

● infrared

● audio

● motion

But never forget the users: we design for users, so be aware of their perception of how secure an authentication method seems to be![T. Kindberg, A. Sellen, E. Geelhoed: “Security and Trust in Mobile Interactions: A Study of Users’ Perceptions and Reasoning”, HP Labs Research Report]





From sensor data to keys: first steps

1. Sensor data acquisition

● potential problem: side-channel attacks

2. Temporal alignment

● triggering

● synchronization

3. Spatial alignment

● when using multi-dimensional input data, these dimensions may be in different reference systems on different devices

4. Feature extraction

● raw data usually unusable, domain-specific





Remark: what to do after authentication?

● Devices also need internal state and key management

● e.g. “Resurrecting Duckling” [F. Stajano and R. Anderson: “The Resurrecting Duckling: Security Issues for Ad-hoc Wireless Networks”, 7th Workshop on Security Protocols, 1999]

● Key storage

– securing keys against physical access

– securing keys in memory

– deleting keys

● Trust

– building trust (user assigned, reputation approaches)

– revoking trust

– trust delegation

● Without a public key infrastructure





“Spatial Reference”

[R. Mayrhofer, H. Gellersen, M.Hazas: “Security by spatial reference: Using relative positioning to authenticate devices for spontaneous interaction”, Ubicomp 2007]




● General assumption: all wireless attacks possible

● E0 outside room: only RF, no US

● E1 in room: E0 + US eavesdropping, insert own messages

● E2 equidistant positions: E1 + US correct distance measurements

● E3 in line: E1 + US correct angle measurements from A

● E4 in between: R3 + US correct angle measurements from A and B

Threats depending on attacker position



[R. Mayrhofer and H. Gellersen: “On the security of ultrasound as out-of-band channel”, SNN 2007]


● E0 outside room:a) DoSb) cause erroneous distance measurementsc) modify shared measurements

● E1 in room: d) eavesdrop on USe) insert US pulses and messagesf) block US transmission

● E2 equidistant positions: g) appear at same distance (also b + e)

● E3 in line:h) appear from same angle as B to A

● E4 in between: i) appear from same angle to bothj) cancel or modify US in transit

Threats depending on attacker position





● Replacement: DoS attack on B, E3 or E4 misrepresented as Bno interaction between A and B

● Asynchronous MITM: replacement, then interaction between E and Bapplication-level interaction between A and B with delay

● Synchronous MITM: full attack, only possible as E4

Difficult when:

● A and B are mobile

● B positioned so as to make E3 impossible

Threats depending on applications





Sender

Trick: mapping messages to distances

Receiver





“IPSecME” using Spatial References




IPSecME (IPSec Made Easy): creating IPSec connections using a spatial authentication proxy




[R. Mayrhofer and R. Gostner: “Using a spatial context authentication proxy for establishing secure wireless connections”, Journal of Mobile Multimedia 3, 2007]














Shaking is common movement

● both (all) devices will experience very similar movement patterns

● both (all) devices will experience very similar accelerations

⇒ not only use it as interaction technique, but also for generating keys

Acceleration is a local physical phenomenon

⇒ difficult for an attacker (MITM) to estimate or replicate

● Not used for identifying users, only as shared context!

Shaking as shared context



[R. Mayrhofer and H. Gellersen: “Shake well before use: Authentication based on accelerometer data”, Pervasive 2007]


Shaking is

● intuitive

● vigorous

● varying

Accelerometers are

● small

● cheap

● (relatively) power-efficient

Reasons for using shaking





Shake well before use: Authentication based on Accelerometer Data

“Shake well before use”





3 experiments:– How do people shake?– “Hacking” competition– Live mode – does it work?

First experimental results

Results:– Parameters for no false positives– False negatives 10.24%, 11.96%– 25/30 subjects successful





Current developments:

● Implementing the method on embedded devices

– “Nokia 5500 Sport” – includes 3D accelerometer with API

– Intel iMote 1 with TinyOS – to emulate headset

● Bluetooth instead of TCP and UDP

– different way of communication setup

– no broadcast

● Improving classification accuracy

Scaling it down





● Laser diode (sender):

– cheap

– small

– reliable

– (relatively) power efficient

– intuitive

● Suggested before for confidential transmission of secrets[T. Kindberg and K. Zhang: “Secure spontaneous devices association” Ubicomp 2003]

● But: laser channel is not confidential

Properties of the laser channel




● Personal and remote devices are trusted (for the particular interaction)

● Wireless communication completely open to attack

● Laser channel is not confidential

attacker can read

● Laser channel is not completely authentic ⇒ “semi-authentic”

attacker can modify (add but not subtract)

Assumptions and threat model

[R. Mayrhofer and M. Welch: “A human-verifiable authentication protocol using visible laser light”, ARES 2007]




Sender

● Prototype with pulsed laser based on iMote1 (ARM7, 12 MHz) and TinyOS

● Missing: implementation of (EC)DH and opportunistic connection management with Bluetooth

Receiver

● Prototype for connecting to standard serial port based on photo resistor and simple high-pass and thresholding

● Missing: improvements of reception quality and transmission speed

Not quite there yet ...





Improving laser transmission

● Modulation instead of on/off pulsing

● Receiver filtering for modulation frequency only to alleviate problems with changing lighting conditions

● Higher transmission rates

Sender

● Reducing battery consumption

● “Nicer” packaging

● Integrating with mobile phones

... but work continues





“Network-in-a-Box”

Infrared as out-of-band channel

[D. Balfanz, G. Durfee, R. E. Grinter, D. K. Smetters, and P. Stewart: “Network-in-a-Box: How to Set Up a Secure Wireless Network in Under a Minute”, 13th USENIX Security Symp., 2004]




“Seeing-is-Believing”

Visual out-of-band channel[J. M. McCune, A. Perrig, and M. K. Reiter: “Seeing-Is-Believing: Using Camera Phones for Human-Verifiable Authentication”, IEEE Symp. on Security and Privacy 2005]



extended to use blinking patterns[N. Saxena, J.-E. Ekberg, K. Kostiainen, and N. Asokan: “Secure Device Pairing based on a Visual Channel”, Cryptology ePrint Archive 2006/050]


Personal Device for VNC Sessions

[A. Oprea, D. Balfanz, G. E. Durfee, and D.~K. Smetters: “Securing a Remote Terminal Application with a Mobile Trusted Device”, ACSAC 2004]




Gesture-based Authentication

[S. N. Patel, J. S. Pierce, and G. D. Abowd: “A Gesture-based Authentication Scheme for Untrusted Public Terminals”, UIST 2004]




Other suggested approaches

● “LoKey”: use SMS as out-of-band channel, integration with applications[A. J. Nicholson, I. E. Smith, J. Hughes, and B. D. Noble: “LoKey: Leveraging the SMS Network in Decentralized, End-to-End Trust Establishment”, Pervasive 2006]

● “Loud and Clear”: comparing non-sensical English sentences, “HAPADEP” extension[M. T. Goodrich, M. Sirivianos, J. Solis, G. Tsudik, and E. Uzun: “Loud And Clear: Human Verifiable Authentication Based on Audio”, ICDCS 2006] [C. Soriente, G. Tsudik, and E. Uzun: “HAPADEP: Human Asisted Pure Audio Device Pairing”, Cryptology ePrint Archive 2007/093]

● “Personal Pen” coupled with RFID for seamless, transparent user login[Jakob E. Bardram, Rasmus E. Kjær, and Michael Ø. Pedersen: “Context-Aware User Authentication - Supporting Proximity-Based Login in Pervasive Computing”, Ubicomp 2003]

● Location-based WLAN authentication[D. B. Faria and D. R. Cheriton: “No Long-term Secrets: Location-based Security in Overprovisioned Wireless LANs”, HotNets-III, 2004]

● “Harmony” protocol for comparing interlocked media streams[T. Kindberg, K. Zhang, and S. H. Im: “Evidently secure device associations”, HP Labs Techreport HPL-2005-40, 2005]

● “Amigo” using RF environment as common context[A. Varshavsky, A. Scannell, A. LaMarca, and E. de Lara: “Amigo: Proximity-based Authentication of Mobile Devices”, Ubicomp 2007]

● “BEDA”: synchronized button presses[Claudio Soriente, Gene Tsudik, and Ersin Uzun: “BEDA: Button-Enabled Device Pairing”, IWSSI 2007]

● “Shake them Up”: moving devices to achieve source indistinguishability[C. Castelluccia and P. Mutaf: “Shake Them Up!”, Mobisys 2005]




Currently:

● Interesting proposals to solve the authentication problem

● Using different terminology, different underlying concepts

● Implementations specific to the approach, and sometimes to a single demonstration application

● No re-usability of protocols, cryptographic primitives, sensor data handling, user interfaces, etc.

● Hard to reproduce published results

Don't re-invent the primitives

To foster research in the area:

● Have a repository of authentication techniques, methods, and protocols

● Provide tested and re-usable primitives for creating new protocols

● Make proposals and protocols comparable and interchangeable

● Provide real-world sensory data sets for reproducability and for testing new approaches

⇒ allow to focus on new and interesting applications that use these primitives




Standard desktop/laptop/server platforms:

● Java

● .NET

Embedded mobile phone/smart device platforms:

● Java (J2ME)

● C++ (Symbian)

Small device/sensor node platforms:

● TinyOS

Where do we want to use it?




OpenUAT

Documentation, demo applications, data sets: http://www.openuat.org

Source code, mailing list, bug tracker: http://sourceforge.net/projects/openuat

[R. Mayrhofer: “Towards an open source toolkit for ubiquitous device authentication”, PerSec/PerCom 2007]




● Cryptographic primitives: ciphers, hashes (JCE and Bouncycastle with wrappers), DH with default parameters and utility methods, interlock*, on-the-fly creation of X.509 CAs and certificates

● Communication channels: threaded TCP and Bluetooth RFCOMM servers using same interface (transparently interchangeable), UDP multicast, Bluetooth background discovery and peer management (opportunistic authentication)

● Key management protocols: DH-over-streams (TCP or RFCOMM), Candidate Key Protocol

● Sensors and feature extractors: ASCII line reader with various implementations for accelerometers, simple statistics, time series aggregation, activity detection/segmentation, FFT, quantizer

● Context authentication protocols: spatial references, shared motion (shaking)

● Secure channels: IPSec tunnel and transport (Linux, MacOS/X, Windows)

Utilizing Log4j, JUnit, Ant build system including J2ME builds

Components in the current release



[R. Mayrhofer: “Towards an open source toolkit for ubiquitous device authentication”, PerSec/PerCom 2007]


And what about privacy?

Reading list for privacy in this area

● “P3P” [M. Langheinrich: “A Privacy Awareness System for Ubiquitous Computing Environments”, Ubicomp 2002]

● “Hitchhiking” makes location information the primary entity [K. P. Tang, P. Keyani, J. Fogarty, and J. I. Hong: “Putting people in their place: an anonymous and privacy-sensitive approach to collecting sensed data in location-based applications”, SIGCHI 2006]

● Still problematic...[J. Krumm: “Inference Attacks on Location Tracks”, Pervasive 2007]




Security helps privacy

Encryption

● at least the content of some interaction is confidential

● but: the fact that interaction happens is relevant

Integrity

● no “bugs” injected in-transit

Authenticity

● no MITM, relaying, transparent proxies, etc.




Security hurts privacy

Non-repudiability

● often one aspect why authentication is applied in the first place

● but: bad for privacy

Plausible deniability

● “I didn't do it, my device had a virus/worm/...” is unbelievable when systems are secure

⇒ Privacy must be considered from the start when designing a system. Retrofitting does not work (even less so than with security)!(good example: [J.-E. Ekberg: “Implementing Wibree Address Privacy”, IWSSI 2007])




Non-identity based authentication

● Authentication is one big threat to privacy

● But only if authentication is based on identity (of a person or device)

● Context-/sensor-based authentication does not require identity

● Potential to provide both security and privacy




Security needs users!

● Unobtrusive, but not invisible

● Supporting spontaneous interaction

– mobile devices with direct contact

– mobile device with remote gateways

– integrating with web services, client-less authentication approaches

● Re-use of existing metaphors

– passing on keys

● New metaphors

– „Shake well before use“


63

“The problem with passwords is that they're too easy to lose control of.”

Bruce Schneier, March 2005


64

“Believe only half of what you see and nothing that you hear.”

Dinah Maria Mulock Craik (1826 – 1887)English novelist and poet


65

“We must plan for freedom, and not only for security, if for no other reason than only freedom can make security more secure.”

Karl Popper


66

Questions?

Slides: http://www.mayrhofer.eu.org/presentationsSource code: http://www.openuat.orgLater questions: [email protected]

OpenPGP key: 0xC3C24BDE7FE4 0DB5 61EC C645 B2F1 C847 ABB4 8F0D C3C2 4BDE

IWSSI 2007First International Workshop on Security for Spontaneous Interaction at Ubicomp 2007

Pervasive Computing Security - About me | Rene · PDF file · 2007-08-062007-08-03 Pervasive Computing Security 1 ... human-verifiable authentication with personal mobile device ...

Documents