Guided Specification and Analysis of a Loyalty Card System Laurent - - PowerPoint PPT Presentation

guided specification and analysis of a loyalty card system
SMART_READER_LITE
LIVE PREVIEW

Guided Specification and Analysis of a Loyalty Card System Laurent - - PowerPoint PPT Presentation

Guided Specification and Analysis of a Loyalty Card System Laurent Cuennet 1 Marc Pouly 2 c 3 Sa sa Radomirovi 1 University of Fribourg 2 Lucerne University of Applied Sciences 3 Institute of Information Security, ETH Z urich July 13,


slide-1
SLIDE 1

Guided Specification and Analysis of a Loyalty Card System

Laurent Cuennet1 Marc Pouly2 Saˇ sa Radomirovi´ c3

1University of Fribourg 2Lucerne University of Applied Sciences 3Institute of Information Security, ETH Z¨

urich

July 13, 2015

1

slide-2
SLIDE 2

Loyalty Cards

Paper-based ink stamp cards are a convenient and inexpensive way for small shops to improve customer loyalty.

◮ Advantage: customer benefits without being tracked and

profiled.

◮ Disadvantage: too many different cards accumulate over time.

2

slide-3
SLIDE 3

Physical Loyalty Card Protocol

Customer Vendor

,

− − − − − − − − − − − − − →

,

← − − − − − − − − − − − − −

3

slide-4
SLIDE 4

Sketch of Electronic Loyalty Card Protocol

Mobile Customer Vendor Server − − − − − → ← − − − − − ← − − − − − − − − − − − − − − − − − − − − − − − −

4

slide-5
SLIDE 5

Security Requirements

Customer anonymity: Vendor cannot link points to customer’s identity. Customer privacy: Vendor can- not link customer’s transac- tions.

5

slide-6
SLIDE 6

Security Requirements

Customer anonymity: Vendor cannot link points to customer’s identity. Customer privacy: Vendor can- not link customer’s transac- tions. Theft protection: Points issued to an agent can be redeemed by the agent.

5

slide-7
SLIDE 7

Security Requirements

Customer anonymity: Vendor cannot link points to customer’s identity. Customer privacy: Vendor can- not link customer’s transac- tions. Theft protection: Points issued to an agent can be redeemed by the agent. Non-repudiation: Vendor can- not repudiate validity of unre- deemed points.

5

slide-8
SLIDE 8

Security Requirements

Customer anonymity: Vendor cannot link points to customer’s identity. Customer privacy: Vendor can- not link customer’s transac- tions. Theft protection: Points issued to an agent can be redeemed by the agent. Non-repudiation: Vendor can- not repudiate validity of unre- deemed points. Unforgeability: Loyalty points accepted by vendor have been issued by vendor. No double-spending: Redeemed loyalty points will not be ac- cepted.

5

slide-9
SLIDE 9

Security Requirements

Customer anonymity: Vendor cannot link points to customer’s identity. Customer privacy: Vendor can- not link customer’s transac- tions. Theft protection: Points issued to an agent can be redeemed by the agent. Non-repudiation: Vendor can- not repudiate validity of unre- deemed points. Unforgeability: Loyalty points accepted by vendor have been issued by vendor. No double-spending: Redeemed loyalty points will not be ac- cepted.

5

slide-10
SLIDE 10

Theft protection

Points issued to an agent can be redeemed by the agent:

◮ “Agent” = Mobile Device.

We are not protecting against theft of Mobile Device.

6

slide-11
SLIDE 11

Theft protection

Points issued to an agent can be redeemed by the agent:

◮ “Agent” = Mobile Device.

We are not protecting against theft of Mobile Device. 2 Threats:

  • 1. Points issued to a mobile device are redeemed by an attacker’s

device. ⇒ Requirement: Confidentiality of loyalty points.

  • 2. Points issued to a mobile device are corrupted or lost and thus

not redeemable by the device. ⇒ Requirement: Authenticity of loyalty points.

6

slide-12
SLIDE 12

Theft protection

Points issued to an agent can be redeemed by the agent:

◮ “Agent” = Mobile Device.

We are not protecting against theft of Mobile Device. 2 Threats:

  • 1. Points issued to a mobile device are redeemed by an attacker’s

device. ⇒ Requirement: Confidentiality of loyalty points.

  • 2. Points issued to a mobile device are corrupted or lost and thus

not redeemable by the device. ⇒ Requirement: Authenticity of loyalty points. Remaining Problem: Transmit Loyalty Points from Server to Mobile Device authentically and confidentially.

6

slide-13
SLIDE 13

Communication Topology [BRS15]

What assumptions can we make about

◮ the communication channels between the four parties? ◮ the capabilities of the four parties? ◮ the honesty of the four parties?

7

slide-14
SLIDE 14

Communication Channels

→◦

→◦ Authentic Channel between Customer and Vendor, due to context and location.

8

slide-15
SLIDE 15

Communication Channels

→◦

→◦

→◦

→◦ Authentic Channel from Device to Customer: Customer knows his device. Insecure Channel from Customer to Device: Anybody could input information into Device.

9

slide-16
SLIDE 16

Communication Channels

→◦

→◦

→◦

→◦

→◦

→◦ Insecure Channel from Device to Server: Any Device can send information to Server. Authentic Channel from Server to Device: Server’s public key can be distributed authentically in the shop.

10

slide-17
SLIDE 17

Communication Channels

→◦

→◦

→◦

→•

→◦

→◦

→◦

→• Secure Channel between Vendor and Server due to physical access control.

11

slide-18
SLIDE 18

Honesty and Capabilities

→◦

→◦

→◦

→•

→◦

→◦

→◦

→•

◮ We assume all four agents are honest. ◮ Customer and Vendor are computationally restricted.

12

slide-19
SLIDE 19

Coffee Shop Topology

D S C V

→◦

→◦

→◦

→•

→◦

→◦

→◦

→•

C

Customer

D

Customer’s Mobile Device

V

Vendor

S

Vendor’s Server

→◦ Insecure Channel

→◦ Authentic Channel

→• Secure Channel

13

slide-20
SLIDE 20

Coffee Shop Topology

D S C V

→◦

→◦

→◦

→•

→◦

→◦

→◦

→•

C

Customer

D

Customer’s Mobile Device

V

Vendor

S

Vendor’s Server

→◦ Insecure Channel

→◦ Authentic Channel

→• Secure Channel

How to transmit Loyalty Points from Server S to Mobile Device D authentically and confidentially?

13

slide-21
SLIDE 21

First Protocol

D S C V

→◦

→◦

→◦

→•

→◦

→◦

→◦

→• 1. C → V : money 2. V → S : money 3. S → V : points / QR 4. V → C : QR 5. C → D : QR / points Are the points transmitted from S to D confidential?

14

slide-22
SLIDE 22

First Protocol

D S C V

→◦

→◦

→◦

→•

→◦

→◦

→◦

→• 1. C → V : money 2. V → S : money 3. S → V : points / QR 4. V → C : QR 5. C → D : QR / points

→◦

→◦ Are the points transmitted from S to D confidential? - No!

14

slide-23
SLIDE 23

First Protocol

D S C V

→◦

→◦

→◦

→•

→◦

→◦

→◦

→• 1. C → V : money 2. V → S : money 3. S → V : points / QR 4. V → C : QR 5. C → D : QR / points

→◦

→◦ Are the points transmitted from S to D confidential? - No! Options: (1) Change assumptions, (2) Improve protocol.

14

slide-24
SLIDE 24

Second Protocol

D S C V

→◦

→◦

→◦

→•

→◦

→◦

→◦

→• ?. D → S : key 1. C → V : money 2. V → S : money 3. S → V : {points}key / QR 4. V → C : QR 5. C → D : QR / {points}key

◮ Idea: S encrypts points for D. Server needs a key for D.

15

slide-25
SLIDE 25

Second Protocol

D S C V

→◦

→◦

→◦

→•

→◦

→◦

→◦

→• ?. D → S : key 1. C → V : money 2. V → S : money 3. S → V : {points}key / QR 4. V → C : QR 5. C → D : QR / {points}key

→◦ Not authentic

◮ Idea: S encrypts points for D. Server needs a key for D. ◮ Problem: How to send information authentically from D to S?

15

slide-26
SLIDE 26

Second Protocol

D S C V

→◦

→◦

→◦

→•

→◦

→◦

→◦

→• ?. D → S : key 1. C → V : money 2. V → S : money 3. S → V : {points}key / QR 4. V → C : QR 5. C → D : QR / {points}key

→◦ Not authentic

→◦

→◦

→•

◮ Idea: S encrypts points for D. Server needs a key for D. ◮ Problem: How to send information authentically from D to S?

Information can be sent authentically along path [D, C, V , S].

15

slide-27
SLIDE 27

Second Protocol

D S C V

→◦

→◦

→◦

→•

→◦

→◦

→◦

→• 1. C → D : GetPoints 2. D → C : key 3. C → V : money, key 4. V → S : money, key 5. S → V : {points}key / QR 6. V → C : QR 7. C → D : QR / {points}key Are the points transmitted from S to D authentic?

16

slide-28
SLIDE 28

Second Protocol

D S C V

→◦

→◦

→◦

→•

→◦

→◦

→◦

→• 1. C → D : GetPoints 2. D → C : key 3. C → V : money, key 4. V → S : money, key 5. S → V : {points}key / QR 6. V → C : QR 7. C → D : QR / {points}key

→◦ Are the points transmitted from S to D authentic? - No!

16

slide-29
SLIDE 29

Second Protocol

D S C V

→◦

→◦

→◦

→•

→◦

→◦

→◦

→• 1. C → D : GetPoints 2. D → C : key 3. C → V : money, key 4. V → S : money, key 5. S → V : {points}key / QR 6. V → C : QR 7. C → D : QR / {points}key

→◦ Are the points transmitted from S to D authentic? - No!

→◦ Idea: Use authentic channel S •− →◦ D to transmit {points}key.

16

slide-30
SLIDE 30

Third Protocol

D S C V

→◦

→◦

→◦

→•

→◦

→◦

→◦

→• 1. C → D : GetPoints 2. D → C : key 3. C → V : money, key 4. V → S : money, key 5. S → D : {points}key

17

slide-31
SLIDE 31

Third Protocol

D S C V

→◦

→◦

→◦

→•

→◦

→◦

→◦

→• 1. C → D : GetPoints 2. D → C : key 3. C → V : money, key 4. V → S : money, key 5. S → D : {points}key

◮ We have modeled the protocol with the Tamarin prover. ◮ Tamarin verifies authenticity and confidentiality for points

transmitted from S to D.

17

slide-32
SLIDE 32

Third Protocol

D S C V

→◦

→◦

→◦

→•

→◦

→◦

→◦

→• 1. C → D : GetPoints 2. D → C : key 3. C → V : money, key 4. V → S : money, key 5. S → D : {points}key

◮ We have modeled the protocol with the Tamarin prover. ◮ Tamarin verifies authenticity and confidentiality for points

transmitted from S to D.

◮ It does not satisfy the privacy requirement: Vendor can link

points redeemed to purchases. See paper for a solution based on an e-cash scheme.

17

slide-33
SLIDE 33

Conclusion

◮ We have introduced the coffee shop topology and used it to

design a novel security protocol.

◮ The security protocol exemplarily designed is a light-weight

electronic customer loyalty program that improves upon commercially deployed systems.

◮ Our example illustrates the use of communication topologies

to guide the design of security protocols.

◮ This approach helps to quickly rule out insecure protocol

designs and thus to reduce the protocol designer’s search space.

18

slide-34
SLIDE 34

Future Work

◮ Interactive and automated protocol design:

What is the “most secure” communication channel achievable for a given arbitrary communication topology? How to automatically construct the corresponding protocol?

19

slide-35
SLIDE 35

Future Work

◮ Interactive and automated protocol design:

What is the “most secure” communication channel achievable for a given arbitrary communication topology? How to automatically construct the corresponding protocol?

◮ Refined set of channels: •−

→•, • →

  • , →, →

E.g.: Human-computer interface is different from network links.

◮ More general attacker model.

19

slide-36
SLIDE 36

Future Work

◮ Interactive and automated protocol design:

What is the “most secure” communication channel achievable for a given arbitrary communication topology? How to automatically construct the corresponding protocol?

◮ Refined set of channels: •−

→•, • →

  • , →, →

E.g.: Human-computer interface is different from network links.

◮ More general attacker model. ◮ Light-weight loyalty point system that supports collaborating

shops or franchises.

19

slide-37
SLIDE 37

Questions?

References: [BRS15] David Basin, Saˇ sa Radomirovi´ c, and Michael Schl¨ apfer. A Complete Characterization of Secure Human-Server

  • Communication. (CSF 2015).

[R15] Tamarin specification files: www.infsec.ethz.ch/research/projects/hisp.html

20