Secure Interaction Design

1
Secure Interaction Design

• Ka-Ping Yee
• 21 June 2002
• HAPPY BELTANE!

2
Overview

• Definitions of security
• Computer security myths
• Previous usability work
• Conflicts and confusions
• User agent and user model
• Secure interaction design principles
• Acknowlegements and summary

3
What is security?

• Functional soundness?
• Reliability?
• (Provable) correctness?
• Secrecy, integrity, availability?

definitions
4
What is security?

• Consider the computer virus.
• E-mail is delivered to recipient correctly.
• Message is decoded correctly.
• Attachment is opened correctly.
• Program is executed correctly.
• Address book functions correctly.
• Mail API sends out mail correctly.
• Where is the security problem?

definitions
5
What is security?

• A computer is secure if you can depend on it and
  its software to behave as you expect.
• Garfinkel and Spafford, Practical Internet
  Security

definitions
6
What is security?

• A computer is secure if you can depend on it and
  its software to behave as you expect.
• Garfinkel and Spafford, Practical Internet
  Security
• Who is you?
• What do you expect?

definitions
7
Myths about computer security

• If the software is correct, then it is secure.
• Security is a black art only experts can
  understand it, and only experts need to be
  concerned with it.
• Computer security is a hard science.
• The more secure a system is, the harder it is to
  use.

definitions myths
8
Myths about computer security

• If the software is correct, then it is secure.

Viruses show that correctness is insufficient.
definitions myths
9
Myths about computer security

• If the software is correct, then it is secure.
• Security is a black art only experts can
  understand it, and only experts need to be
  concerned with it.

The expert cannot always know what the user wants.
definitions myths
10
Myths about computer security

• If the software is correct, then it is secure.
• Security is a black art only experts can
  understand it, and only experts need to be
  concerned with it.
• Computer security is a hard science.

definitions myths
Security cannot be defined without understanding
user expectations.
11
Myths about computer security

• If the software is correct, then it is secure.
• Security is a black art only experts can
  understand it, and only experts need to be
  concerned with it.
• Computer security is a hard science.
• The more secure a system is, the harder it is to
  use.

definitions myths
LETS CHECK THIS ONE OUT...
Good security makes systems easier to use.
12
Why trade off usability?

• A computer is secure from a particular users
  perspective if the user can depend on it and its
  software to behave as the user expects.
• Acceptable security is a requirement for
  usability.
• Acceptable usability is a requirement for
  security.

definitions myths
13
Why trade off usability?

• Usability is about accurately conveying intent
  and expectations between the human and computer.
• Security is about accurately conveying intent and
  expectations between the human and computer.
• Use the information already provided during
  interaction to determine security restrictions.

definitions myths
HANG ON TO THAT THOUGHT!WELL USE IT LATER...
14
Previous work

• User studies of security software
• Dhamija, Sasse passwords
• Karat iterative testing
• Karvonen SPKI
• Mosteller error messages
• Whitten PGP
• Zurko authorization

definitions myths previous work
15
Previous work

• User-centred design of security software
• Zurko role-based access control
• Design recommendations
• Holmström secure business card metaphor(but
  results not very convincing)
• Karvonen know your user, list all possible
  security issues, involve user as little as
  possible

definitions myths previous work
16
Everybody says...

• Users are ignorant.
• Karvonen, Nikander, ...
• Users dont care about security.
• Schneier, Spafford, ...
• People are the weakest link.
• Adams, Sasse, Karvonen, ...
• Are there any answers?

definitions myths previous work
17
Conflicting goals

• The user should not be allowed to continue
  ... before confirming about security. However,
  too much strain is too much ... the user should
  not be prompted about security too frequently.
• Karvonen, Creating Trust

definitions myths previous work conflicts
SO HOW MUCH IS ENOUGH?
18
Conflicting goals

• A mixture of hiding and revealing information
  about certificates, along with preventing the
  user from making any serious mistakes, is a
  likely solution.
• Karvonen, Kortesniemi, Latva-Koivisto,
  Evaluating Revocation

definitions myths previous work conflicts
HIDE WHAT? REVEAL WHAT?
19
Modes of confusion

• What does the user trust?
• What does the user expect?
• How can the system be reliable?
• How can the user stay in control?
• When should we ask the user?
• What should we show the user?

definitions myths previous work conflicts
20
What does the user trust?

• The user agent is the software system that is
  intended to serve and protect the interests of
  the user.
• Arena PC, files, apps Agent desktop shell
• Arena Internet Agent web browser
• Arena money, investors Agent banks website

definitions myths previous work
conflicts model
21
What does the user trust?

• Multiple user agents can be involved in one
  transaction.

REAL WORLD
COMPUTER
INTERNET
FINANCE
programs
money
Slashdot
doors
DESKTOPSHELL
WEB BROWSER
BANK WEBSITE
definitions myths previous work
conflicts model
stocks
files
pencils
The Onion
accounts
windows
OOOH... PRETTY COLOURS!
22
What does the user expect?
ENTER PSYCHOLOGY...

• People interpret actions in terms of physical,
  designed, or intentional behaviours Dennett.
• Physical governed by physical laws (e.g. a
  rock).
• Designed made to meet a purpose (e.g. a car).
• Intentional acts to fulfill desires (e.g. a
  dog).
• People are good at modelling a world of
  independent actors with purposes and desires
  Bruce, Newman.

definitions myths previous work
conflicts model
23
What does the user expect?

• I propose the Actor-Ability Model.
• Set of actors A A0, A1, A2, ... where A0 is
  the user.
• Each actor Ai has a set of potential abilities Pi
  anda set of real abilities Ri .
• The users state is ltA0, A1, A2, ..., P0, P1,
  P2, ...gt.

definitions myths previous work
conflicts model
24
What does the user expect?

• No-surprise condition
• P0 ? R0
• Pi ? Ri (for i gt 0)

definitions myths previous work
conflicts model
25
Design principles

• Path of Least Resistance
• Appropriate Boundaries
• Explicit Authority Trusted Path
• Expected Ability Identifiability
• Visibility Clarity
• Revocability Expressiveness

definitions myths previous work
conflicts model principles
26
Design principles Basics

• Path of Least Resistance To the greatest extent
  possible, the natural way to do a task should be
  the secure way.
• Appropriate Boundaries The interface should
  expose, and the system should enforce,
  distinctions between objects and between actions
  that matter to the user.

definitions myths previous work
conflicts model principles
27
Interlude Bad boundaries

• This is a real IE dialog.
• Im forced to make anall-or-nothing choice!

definitions myths previous work
conflicts model principles
28
Design principles Reliability

• Explicit Authority A users authorities must
  only be provided to other actors as a result of
  an explicit action that is understood to imply
  granting.
• this is Pi ? Ri (for i gt 0)
• Expected Ability The interface must not generate
  the impression that it is possible to do
  something that cannot be done.
• this is P0 ? R0

definitions myths previous work
conflicts model principles
29
Interlude When do we ask?

definitions myths previous work
conflicts model principles
30
Interlude When do we ask?

definitions myths previous work
conflicts model principles
31
Design principles Control

• Visibility The interface should allow the user
  to easily review any active authority
  relationships that would affect security-relevant
  decisions.
• Revocability The interface should allow the user
  to easily revoke authorities that the user has
  granted, wherever revocation is possible.

definitions myths previous work
conflicts model principles
32
Interlude What do we show?

709am up 117 days, 602, 1 user, load
average 0.17, 0.23, 0.23 110 processes 109
sleeping, 1 running, 0 zombie, 0 stopped CPU
states 7.6 user, 4.5 system, 0.0 nice,
87.8 idle Mem 512888K av, 496952K used,
15936K free, 60K shrd, 29728K buff Swap
1052216K av, 146360K used, 905856K free
181484K cached PID USER PRI NI
SIZE RSS SHARE STAT CPU MEM TIME
COMMAND 24733 root 18 0 2556 2556 488 S
6.0 0.4 142 chargen 25184 ping 16
0 996 996 748 R 3.9 0.1 001
top 24276 root 9 0 1888 1864 1484 S
0.7 0.3 004 sshd 23519 apache 10 0 21792
13M 8080 S 0.1 2.6 023 httpd 23520
apache 10 0 21456 12M 8076 S 0.1 2.5
020 httpd 1 root 8 0 188 148
148 S 0.0 0.0 025 init 2 root 9
0 0 0 0 SW 0.0 0.0 000
keventd 3 root 9 0 0 0 0
SW 0.0 0.0 000 kapm-idled 4 root
19 19 0 0 0 SWN 0.0 0.0 033
ksoftirqd_CPU0 5 root 9 0 0 0
0 SW 0.0 0.0 9412 kswapd 6 root
9 0 0 0 0 SW 0.0 0.0 002
kreclaimd 7 root 9 0 0 0 0
SW 0.0 0.0 008 bdflush 8 root 9
0 0 0 0 SW 0.0 0.0 015
kupdated 9 root -1 -20 0 0 0
SWlt 0.0 0.0 000 mdrecoveryd 654 root
9 0 348 288 288 S 0.0 0.0 241
syslogd 659 root 9 0 852 120 120 S
0.0 0.0 006 klogd 744 root 9 0
1988 1988 1728 S 0.0 0.3 007 ntpd 757
daemon 9 0 172 116 116 S 0.0 0.0
000 atd 786 root 9 0 360 232 200
S 0.0 0.0 003 sshd 807 root 8 0
476 336 292 S 0.0 0.0 056 xinetd
866 root 8 0 396 332 312 S 0.0
0.0 034 crond 915 root 9 0 2076
476 476 S 0.0 0.0 025 miniserv.pl 919
root 9 0 108 48 48 S 0.0 0.0
000 mingetty 920 root 9 0 108 48
48 S 0.0 0.0 000 mingetty
Not this
definitions myths previous work
conflicts model principles
33
Interlude What do we show?

definitions myths previous work
conflicts model principles
34
Design principles Integrity

• Trusted Path The interface must provide a
  faithful and unspoofable communication channel
  between the user and any entity trusted to
  manipulate authorities on the users behalf.
• Identifiability The interface should enforce
  that distinct objects and distinct actions have
  unspoofably identifiable and distinguishable
  representations.

definitions myths previous work
conflicts model principles
35
Interlude Violating identifiability

definitions myths previous work
conflicts model principles
36
Interlude Fixing identifiability

definitions myths previous work
conflicts model principles
37
Design principles I/O

• Clarity The effect of any security-relevant
  action must be apparent before the action is
  taken.
• Expressiveness The interface should provide
  enough expressive power (a) to describe a safe
  security policy without undue difficulty and (b)
  to allow users to express security policies in
  terms that fit their goals.

definitions myths previous work
conflicts model principles
38
Interlude Violating Clarity

Who is Bogus? What program? Why? Grant how
long? Cant see info... What does remember this
decision mean?
definitions myths previous work
conflicts model principles
39
Interlude Violating Clarity

What program? What source? What
privileges? What purpose? How long? How to
revoke? Remember this decision? What
decision?! Oh, might as well click Yes its
the default.
definitions myths previous work
conflicts model principles
40
Acknowledgements

• Morgan Ames, Verna Arts, Nikita Borisov, Jeff
  Dunmall, Tal Garfinkel, Marti Hearst, Norm Hardy,
  Johann Hibschman, Josh Levenberg, Lisa Megna,
  Mark S. Miller, Chip Morningstar, Kragen Sitaker,
  Marc Stiegler, Dean Tribble, Doug Tygar, David
  Wagner, Miriam Walker, David Waters

definitions myths previous work
conflicts model principles summary
41
Summary

• This talk has
• argued that usability and security must go
  together
• demonstrated how they dont have to compete
• presented the Actor-Ability Model
• directly addressed questions avoided in earlier
  work
• proposed ten design principles for secure
  interaction
• shown how they apply in practice
• ? http//zesty.ca/sid ?

definitions myths previous work
conflicts model principles summary
42

• Think different.

43

• Think different.
• Eschew adverbs.