Human Errors in Security Protocols

David Basinjoint work with Saša Radomirović and Lara Schmid

Institute of Information Security

Recap Security Protocols

We have defined• the Dolev-Yao adversary

• communicating agents that follow a role specification

• and the security properties desired2

What we have not seen

We glossed over that• a human is one of the communicating parties,

• humans have limited computational abilities, and

• they are error-prone.3

How can we achieve secure communication between a human and a remote server?

• Examples: Online Banking, Internet Voting, Electronic Tax Returns, …

• How do we model and reason about interaction between humans and computers?

4

new problem Dolev-Yao: under control

How can we achieve secure communication between a human and a remote server?

• If platform is compromised: no useful secure communication is possible.

• A trusted device is necessary.

5

additional problem: compromised platform

Platform PHuman H Server S

Device D

Possible “devices”:

For which kinds of devices is secure communication possible?

(A Complete Characterization of Secure Human-Server Communication, CSF 2015)

Focus in this talk on human errors (Modeling Human Errors in Security Protocols, CSF 2016)

Overview

1. Security protocol model

2. Modelling Human Error

3. Applications

7

Security Protocol Model — Tamarin

• Symbolic formal model specified using multiset rewriting

• Dolev-Yao adversary controlling communication network.

• Possible executions modeled by traces

• Tool support

Alice & Bobspecification

A: fresh(n) A → B: n

Protocol rules

[ Fr(n) ] ⟶ [ AgSt(n) ]

[ AgSt(n) ] ⟶ [ Out(n) ]

[ In(n) ] ⟶ [ ]

Adversary rules (simplified)

[ Out(n) ] ⟶ [ !K(n) ]

[ !K(n) ] ⟶ [ In(n) ]

[ !K(n), !K(m) ] ⟶ [ !K( pair(n,m) ) ]

[ ] ⟶ [ !K($x) ] ($x: public term) …

Protocol Specification Example

S(n)

R(n)

K(n)

Role specification of A

Fresh rule

[ ] ⟶ [ Fr(n) ]

State Term Rewriting Rule Instantiation Trace

[ ][ ] ⟶ [ Fr(n) ] [ ] ⟶ [ Fr(~1) ]

[ Fr(~1) ][ Fr(n) ] ⟶ [AgSt(n)] [Fr(~1) ] ⟶ [AgSt(~1)]

[ AgSt(~1) ][AgSt(n)] ⟶ [Out(n)] [AgSt(~1)] ⟶ [Out(~1)] S(~1)

[ Out(~1) ][ Out(n) ] ⟶ [!K(n)] [ Out(~1) ] ⟶ [!K(~1)] K(~1)

[ !K(~1) ][ !K(n) ] ⟶ [In(n)] [ !K(~1) ] ⟶ [In(~1)]

[ !K(~1), In(~1) ] [ In(n) ] ⟶ [ ] [ In(n) ] ⟶ [ ] R(~1)

S(n) S(~1)

K(n) K(~1)

Specified rules:

[ ] ⟶ [ Fr(n) ] [ Fr(n) ] ⟶ [ AgSt(n) ] [ AgSt(n) ] ⟶ [ Out(n) ] [ Out(n) ] ⟶ [ !K(n) ] [ !K(n) ] ⟶ [ In(n) ] …

Protocol Execution Example

Linear vs persistent facts 10

Specified rules:

[ ] ⟶ [ Fr(n) ] [ Fr(n) ] ⟶ [ AgSt(n) ] [ AgSt(n) ] ⟶ [ Out(n) ] [ Out(n) ] ⟶ [ !K(n) ] [ !K(n) ] ⟶ [ In(n) ] …

R(n) R(~1)

Communication ChannelsAuthentic •→○, confidential ○→•, and secure •→• channel rules are used to restrict capabilities of Dolev-Yao adversary.

Example: Confidential channel rules

[ SndC($A,$B,m) ] ⟶ [ !Conf($B,m) ]

[ !Conf($B,m), !K($A) ] ⟶ [ RcvC($A,$B,m) ]

[ !K(<$A,$B,m>) ] ⟶ [ RcvC($A,$B,m) ]

11

$ sign: public term. Agent names arepublic knowledge.

Security Properties

Set of all traces

SecurityProperty

SecurityProperty

Protocol

Protocol does not satisfysecurity property. Protocol satisfies security property.

Set of all traces

Protocol

12

If m is claimed to be secret, then the adversary does not learn m.

Set of traces: ∀ m #i #j. Secret(m)@i ⇒ not K(m)@j

Confidentiality

13

Recent Aliveness of B with respect to A

Set of all traces

— Action(A)

— Action(B)

— Action(A)

— Action(A)

No action of B, no recent aliveness

Authentication Properties: Recent Aliveness

Action of B occurs between two events of A.

— Claim(A)— Action(A)

Entity Authentication: Recent aliveness of an entity H, with respect to verifier (remote server S).

Device Authentication: Recent aliveness of a device D. We generally assume exclusive access of human H to D.

Message Authentication: If verifier claims that H has sent m, then H has indeed sent m.

Authentication Properties

15

Example: A trusted agent was not previously dishonest.

Set of traces: ∀ A #i #j. ( Trusted(A)@i ⋀ Dishonest(A)@j ) ⇒ i < j

Trace RestrictionsExclude traces that violate the specification.

Trace Restriction

Protocol

Set of all traces

Only traces in intersection are considered.

16

Excluded traces

Modelling Humans

(simplified rules)

• Humans can communicate over provided interfaces.

• Human knowledge is modelled with !HK(H,t,m) facts. E.g.: !HK(H,’pw’,p) means human H knows password p.

• Humans can concatenate and split messages: [ !HK(H,t1,m1), !HK(H,t2,m2) ] ⟶ [ !HK(H,<t1,t2>,<m1,m2>) ] [ !HK(H,<t1,t2>,<m1,m2>) ] ⟶ [ !HK(H,t1,m1), !HK(H,t2,m2) ]

agent, type, message

Overview

1. Security protocol model

2. Modelling Human Error

3. Applications

18

Modelling Human Error

19

• Users don’t know protocol specifications • Mistakes are made, even experts slip up • We are susceptible to social engineering• So how should we analyze security of systems

in view of human errors?

DefinitionA human error in a protocol execution is any deviation of a human from his or her role specification.

20

• Model rule-based behaviour: Allow for arbitrary behaviour of an untrained agent up to a few simple rules (guidelines).

• Distinguish between slips and lapses by skilled users and mistakes by inexperienced users.

• Model slips and lapses: Allow an infallible agent to make a small number of mistakes.

Two Classes of Human Error

• Infallible human follows protocol specification.

• Fallible human may deviate from protocol specification.

• Fallible humans give rise to more system behaviours than the infallible human.

Infallible vs Fallible Humans

Fallible

Infallible

Set of all traces

21

Partial order of human errors by comparing sets of induced traces.

Error 2

Error 1

Infallible

Comparing Specific Errors

Set of all traces

22

Two Classes of Human ErrorInfallible

Err 1 Err 2

Err 3

Err 1.1

Err 1.2

Err 1.3

Untrained

G 1

G 2

G 3

G 1.1

G 1.2

G 1.3

Skilled Humans Inexperienced Humans

Arrows indicate trace-set containment (node at arrowhead contains more behaviors than node at tail)

G 2.1

G 3.1

Errors →

←G

uidelines

Untrained Humans

We focus on this class• They are ignorant of and may deviate

arbitrarily from protocol specification.

• They accept any message received and send any message requested.

• But they can be trained, given guidelines!

24

Untrained

G 1

G 2

G 3

G 1.1

G 1.2

G 1.3

Inexperienced Humans

G 2.1

G 3.1

[ In(<tag,msg>) ] ⟶ [ !HK(H,tag,msg) ]

[ !HK(H,tag,msg) ] ⟶ [ Out(<tag,msg>) ] (Trace labels omitted.)

Guidelines

Guidelines are modelled by trace restrictions.

Trace Restriction

Protocol

Set of all traces

Exemplary Guidelines I

• NoTellExcept(H,tag,D): Human H does not send information of type tag to anyone except D. E.g.: Only enter your password into your own device.

• NoTell(H,tag):∀ m #i #j. NoTell(H,tag)@i ⇒ not Snd(H,<tag,m>)@jHuman H does not send information of type tag to anyone. E.g.: Never reveal your private key.

NoTell(H,t)

NoTellExcept(H,t,D)

NoGet(H,t)

ICompare(H,t)

t

t

t

t’

D

t

�

�

�

t = t’ ?

�t

Exemplary Guidelines II

• NoGet(H,tag): Human H rejects information of type tag from everyone. E.g.: Never click on links in emails.

• ICompare(H,tag): Human H always compares received information of type tag with information in his initial knowledge. E.g.: Always check the website’s URL.

NoTell(H,t)

NoTellExcept(H,t,D)

NoGet(H,t)

ICompare(H,t)

t

t

t

t’

D

t

�

�

�

t = t’ ?

�t

1. Activate the card reader by inserting the Access Card.

2. Enter your PIN and press OK .

3. Enter your contract number on the login page and click Next.

4. Enter the six-digit code displayed on the login page into the card reader and press OK .

5. Enter the eight-digit code from the card reader on the login page and click Login.

Security note: The login number displayed by UBS always has six digits. If it has fewer digits, this could be a case of attempted fraud. Contact the support team as soon as possible in this case.

Login with the Access Card and card readerAccess the desired online service via ubs.com/online and initiate the login process (self-authorization).

Concrete example — ebanking

Overview

1. Security protocol model

2. Modelling Human Error

3. Applications

29

Phone-based Authentication• Cronto: Scan a code on platform, decrypted by mobile

device, enter code + password on platform

• Google 2-step: login/password + SMS

• MP-Auth: Enter password into mobile device

• One-time passwords over SMS: single-factor authentication

• Phoolproof: choose server on device, device-server communication, then enter password on the platform

• Sound-Proof: ambient noise recorded by platform and mobile

30

D knows: H, pk(S), pw S knows: H, sk(S), pw

S: fresh(rS) S → D: S, rS D: fresh(rD) D → S: {rD}pk(S), {h(rS), H, pw}h(rS,rD) S → D: {h(rD)}h(rS,rD)

MP-Auth* without Human Role

31

Server S

Device Donly S can read this

fresh session, no replay

D must have sent thisS must have sent this

shared key: only D and S can compute this

satisfies confidentiality & authenticity of h(rS, rD). (*) Mohammad Mannan and Paul C. van Oorschot. Leveraging personal devices for stronger password

authentication from untrusted computers. Journal of Computer Security, 19(4):703–750, 2011.

MP-Auth without Human Role

D knows: H, pk(S), pw S knows: H, sk(S), pw

S: fresh(rS) S → P → D: S, rS D: fresh(rD) D → P → S: {rD}pk(S), {h(rS), H, pw}h(rS,rD) S → P → D: {h(rD)}h(rS,rD)

D: trusted device, P: untrusted platform

32

Platform PServer S

Device D

MP-AuthH knows: D, P, S, pw D knows: H, pk(S) S knows: H, sk(S), pw H → P: S P → S: ‘start’ S → P → D: fresh(rS) . S, rS D •→• H: S H •→• D: pw, H D → P → S: fresh(rD) . {rD}pk(S), {h(rS), H, pw}h(rS,rD) S → P → D: {h(rD)}h(rS,rD) D •→• H: ‘success’

33

Platform P Server S

Device D

Human H

secure channel

MP-AuthH knows: D, P, S, pw D knows: H, pk(S) S knows: H, sk(S), pw H → S: ‘start’ S → D: fresh(rS) . S, rS D •→• H: S H •→• D: pw, H D → S: fresh(rD) . {rD}pk(S), {h(rS), H, pw}h(rS,rD) S → D: {h(rD)}h(rS,rD) D •→• H: ‘success’

Modelling untrusted platform with insecure channels.34

Server S

Device D

Human H

Comparison: Phone-based Authentication Protocols

Infallible Untrained With Guidelines Infallible Untrained With

Guidelines

Cronto ✓ ✓ ✓ ✓

Google 2-Step ✓ ✓ ✓ ✓

OTP over SMS ✓ ✓ ✓ ✓

MP-Auth ✓ ✕ ✓ ✓ ✕ ✓

Phoolproof ✕ ✓ ✓

Sound-Proof ✕ ✓ ✓

Entity Authentication Device Authentication

Guideline: NoTellExcept(H,’pw’,’D’)

Adversary impersonates H and D to server, after untrained H enters password on corrupted platform.

Guideline: NoTellExcept(H,’pw’,’D’)

MP-Auth Analysis

Entity Authentication vs Message Authentication

36

• Both are important. E.g., message (origin) authentication used to authenticate transactions in online banking.

• Some entity authentication protocols can be extended for message authentication

Extensions not always possible or straightforward

MP-Auth Message Authentication

H knows: D, P, S, m D knows: H, pk(S), S, k S knows: sk(S), H, k

H → S: m S → D: fresh(rS) . {m, rS}k D •→• H: m H •→• D: ‘ok’ D → S: {h(m,rS)}k

37

derived from shared key established in login protocol

“please wire 10€ to account #123”confirm: 10€ to #123

replay protection

transfer 10€ to #123 ?

confirmed: 10€ to #123

MP-Auth Message Authentication Analysis

• MP-Auth MA with infallible human

• MP-Auth MA with untrained humanH presses OK without reading display, confirms message m sent by adversary.

• Guidelines NoTell, NoTellExcept, NoGet, and ICompare insufficient to prevent attack.

38

Improved MP-Auth Message Authentication

H knows: D, P, S, m D knows: H, pk(S), S, k S knows: sk(S), H, k

H → S: m S → D: fresh(rS) . {m, rS}k D •→• H: fresh(vc) . vc, m H •→• D: vcD → S: {h(m,rS)}k

Satisfies message authentication with human following ICompare guideline.

H must read displayin order to proceed

Google-2-stepH : knows(P,D,S,pw,m,idH)D : knows(H)S : knows(H,pw,D,idH)H → P : S, idH, pw, mP ○→• S : idH, mS ○→• D : fresh(c). c,mD •→• H : c,mH → P : S, cP → S : c, pw, m

Authenticity of m from H to S?

53

with message authentication

← enters name/password

← gets code on device (SMS)

← code entered on platform← and forwarded to server

+ message to authenticate

Authenticity inGoogle-2-step

For an infallible human: verified.

For a fallible human: falsified.Human does not know he has to comparemessage on phone with the m that he sent.

For a human with rule ICompare(H,`m’): verified.

54

Comparison: Message Authentication

Infallible Untrained With Guidelines

Cronto MA ✓ ✕ ✓

Google 2-Step* ✓ ✕ ✓

OTP over SMS* ✓ ✕ ✓

MP-Auth VC ✓ ✕ ✓

MP-Auth MA ✓ ✕ ✕

Phoolproof* ✓ ✓

Sound-Proof ✕

Guideline: ICompare(H,’m’)

* Our extension based on HISP design guidelines.

43

Conclusion• First formal model of human errors in security protocols,

providing systematic approach for reasoning about human errors

• Applications to authentication protocols:

Finding attacks arising from human errors.

Identifying protocol techniques that provide effective protection against various mistakes.

Ranking protocols WRT their robustness to human errors

Future Work• What are good guidelines?

• Verify protocols in combination of skilled and untrained human error models.

• Apply the model to improve security in the real world:

• Improve system and protocol design.

• Identify critical user actions that must be monitored.

• Identify critical concepts to teach to untrained users.44

Literature

• Modeling Human Errors in Security Protocols D.B., Sasa Radomirovic, Lara Schmid, CSF 2016.

• A Complete Characterisation of Secure Human-Server CommunicationD.B., Sasa Radomirovic, Michael Schläpfer, CSF 2015.

Details

32 / 3846

Skilled Humans

• Skilled humans follow protocol specification, may make a small number of mistakes (slips & lapses).

• Slips & lapses: Inattentiveness, routine behaviour in an unusual situation. E.g, clicking “OK” w/o reading an alert.

• Modelled by adding failure rules to protocol model.

47

Specifying Skilled Human Role

Skilled Human H follows protocol specification, keeps state information: AgSt(H,step,knownTerms)

Pattern for receiving messages: [AgSt(H,s1,k), Rcv(H,<t,m>) ] ⟶

[ !HK(H,t,m), AgSt(H,s2,<k,m>) ]

Pattern for sending messages: [ AgSt(H,s1,<k,m>), !HK(H,t,m) ] ⟶

[ Snd(H,<t,m>), AgSt(H,s2,<k,m>) ]

(Trace labels omitted.)

Example of a Failure Rule (Skilled Human Error)

Message confusion: Human H intends to send message m1, sends instead message m2.

[Snd(H,<t1,m1>), !HK(H,t2,m2), Fail(H,’msc’)] ⟶ [ Snd(H,<t2,m2>) ]

Fail fact: allows control over type and number of errors.

(Trace labels omitted.)

Related Work• Beckert and Beuster (2006), Rukšėnas et al. (2008)

formally model humans and human error in human-machine interfaces.

• Their models correspond to our skilled human approach, but capture only finite scenarios.

• We model human error in unbounded protocol executions.

• A set of failure rules for skilled human agents in security protocols are given by Schläpfer (2016).

• Our untrained human approach is new.

HISP Channel Assumptions

Authentic Channel:

[SndA(A,B ,m)]�[ SndA(A,B ,m) ]! [!Auth(A,m),Out(hA,B ,mi)][!Auth(A,m), In(B)]�[ RcvA(A,B ,m) ]! [RcvA(A,B ,m)]

Confidential Channel:

[SndC(A,B ,m)]�[ SndC(A,B ,m) ]! [!Conf(B ,m)][!Conf(B ,m), In(A)]�[ RcvC(A,B ,m) ]! [RcvC(A,B ,m)][In(hA,B ,mi)]�[ RcvC(A,B ,m) ]! [RcvC(A,B ,m)]

Secure Channel:

[SndS(A,B ,m)]�[ SndS(A,B ,m) ]! [!Sec(A,B ,m)][!Sec(A,B ,m)]�[ RcvS(A,B ,m) ]! [RcvS(A,B ,m)]

36 / 3851