Verifying the SET Protocol G Bella & L C Paulson Cambridge F - - PowerPoint PPT Presentation

▶
verifying the set protocol
SMART_READER_LITE
LIVE PREVIEW

Verifying the SET Protocol G Bella & L C Paulson Cambridge F - - PowerPoint PPT Presentation

Feb 20, 2024 225 likes •467 views

Verifying the SET Protocol G Bella & L C Paulson Cambridge F Massacci Siena P Tramontano Rome Inductive Protocol Verification Define systems operational semantics Include honest parties and an attacker Model each

slide-1
SLIDE 1

Verifying the SET Protocol

G Bella & L C Paulson Cambridge F Massacci Siena P Tramontano Rome

slide-2
SLIDE 2

2

Lawrence C Paulson

Inductive Protocol Verification

  • Define system’s operational semantics
  • Include honest parties and an attacker
  • Model each protocol step in an inductive

definition

  • Prove security properties by induction
  • Mechanize using Isabelle/HOL
slide-3
SLIDE 3

3

Lawrence C Paulson

Can Big Protocols Be Verified?

  • Can verify some real protocols:

– Kerberos IV – TLS (the new version of SSL) – APM’s recursive protocol

  • Other verification methods available:

– Model-checking (Lowe) – NRL Protocol Analyzer (Meadows)

slide-4
SLIDE 4

4

Lawrence C Paulson

Growth in Protocol Complexity

  • Needham-Schroeder (1978):
  • TLS:
  • SET: 5 main sub-protocols,

3 manuals, nearly 6 pages 80 pages 1000 pages

Why so big?

slide-5
SLIDE 5

5

Lawrence C Paulson

Internet Shopping with SSL

SSL Credit card details Curses! Can’t get that number!

slide-6
SLIDE 6

6

Lawrence C Paulson

Do We Trust the Merchant?

SSL Credit card details?? Now I can buy that software!

slide-7
SLIDE 7

7

Lawrence C Paulson

Do We Trust the Customer?

Fake card details SSL Send MS Office, charge to my card...

slide-8
SLIDE 8

8

Lawrence C Paulson

Basic Ideas of SET

  • Legitimate Cardholders and Merchants

receive electronic credentials

  • Merchants don’t see credit card numbers

(usually!)

  • Payment is made via the parties’ banks
  • Both sides are protected from fraud
slide-9
SLIDE 9

9

Lawrence C Paulson

SET Participants

  • Issuer = cardholder’s bank
  • Acquirer = merchant’s bank
  • Payment gateway pays the merchant
  • Certificate authority (CA) issues electronic

credentials

  • Trust hierarchy: top CAs certify others
slide-10
SLIDE 10

10

Lawrence C Paulson

Internet Shopping with SET

SET

purchase details Her bank His bank

slide-11
SLIDE 11

11

Lawrence C Paulson

SET Cryptographic Primitives

  • Hashing, to make message digests
  • Digital signatures
  • Public-key encryption
  • Symmetric-key encryption: session keys
  • Digital envelopes involving all of these!
  • Deep nesting of crypto functions
slide-12
SLIDE 12

12

Lawrence C Paulson

The 5 Sub-Protocols of SET

  • Cardholder registration
  • Merchant registration
  • Purchase request
  • Payment authorization
  • Payment capture
  • verified!
slide-13
SLIDE 13

13

Lawrence C Paulson

  • Let’s look at

this message

CARDHOLDER REGISTRATION

REGISTRATION FORM CARDHOLDER CERTIFICATE REQUEST CARDHOLDER CERTIFICATE REGISTRATION FORM REQUEST CARDHOLDER RECEIVES CERTIFICATE

CARDHOLDER COMPUTER CERTIFICATE AUTHORITY (CA) PROCESS

CERTIFICATE AUTHORITY PROCESSES REQUEST AND CREATES CERTIFICATE INITIATE RESPONSE INITIATE REQUEST CARDHOLDER RECEIVES REGISTRATION FORM AND REQUESTS CERTIFICATE CARDHOLDER INITIATES REGISTRATION CARDHOLDER RECEIVES RESPONSE AND REQUESTS REGISTRATION FORM CERTIFICATE AUTHORITY PROCESSES REQUEST AND SENDS REGISTRATION FORM CERTIFICATE AUTHORITY SENDS RESPONSE

slide-14
SLIDE 14

14

Lawrence C Paulson

Message 5 in Isabelle

[ [evs5 ∈ set_cr; C = Cardholder k; Nonce NC3 / ∈ used evs5; Nonce CardSecret / ∈ used evs5; NC3=CardSecret; Key KC2 / ∈ used evs5; KC2 ∈ symKeys; Key KC3 / ∈ used evs5; KC3 ∈ symKeys; KC2=KC3; Gets C ... ∈ set evs5; Says C (CA i) ... ∈ set evs5] ] = ⇒ Says C (CA i) { |Crypt KC3 { |Agent C, Nonce NC3, Key KC2, Key cardSK, Crypt (invKey cardSK) (Hash{ |Agent C, Nonce NC3, Key KC2, Key cardSK, Pan(pan C), Nonce CardSecret| })| }, Crypt EKi { |Key KC3, Pan (pan C), Nonce CardSecret| }| } # evs5 ∈ set_cr

slide-15
SLIDE 15

15

Lawrence C Paulson

What Did That Mean?

  • Cardholder had asked to register a PAN

(primary account number)

  • Cardholder has received the CA’s reply
  • Cardholder sends a digital envelope:

– A public signing key, cardSK – A message, signed using the private key – Two session keys (one for the CA’s reply) – A secret number, CardSecret

slide-16
SLIDE 16

16

Lawrence C Paulson

Secrecy of the Card Number

  • Intuitively obvious: PAN is always hashed
  • r encrypted
  • Huge case-splits caused by nested

encryptions

  • Two lemmas:

– Session keys never encrypt PANs – Session keys never encrypt private keys

slide-17
SLIDE 17

17

Lawrence C Paulson

Secrecy of Session Keys

  • Three keys, created for digital envelopes
  • Dependency: one key protects another
  • Main theorem on this dependency relation
  • Generalizes an approach used for simpler

protocols (Yahalom)

slide-18
SLIDE 18

18

Lawrence C Paulson

Secrecy of Nonces

  • Secret numbers exchanged to generate

Cardholder’s password

  • Protected using those session keys
  • Similar to the proofs for keys
  • Main theorem about the Key/Nonce

dependency relationship

slide-19
SLIDE 19

19

Lawrence C Paulson

The Purchase Phase!

slide-20
SLIDE 20

20

Lawrence C Paulson

Novel Aspects of SET Purchase

3-way agreement: with partial knowledge!

  • Cardholder shares Order Information only

with Merchant

  • Cardholder shares Payment Information
  • nly with Payment Gateway
  • Cardholder signs hashes of OI, PI
  • Non-repudiation: all parties sign messages
slide-21
SLIDE 21

21

Lawrence C Paulson

Complications in SET Purchase

  • Massive redundancy: exponential blow-ups
  • Insufficient redundancy (no explicitness),

requiring toil to prove trivial facts

  • Two message flows: signed and unsigned
  • Many digital envelopes
  • No clear goals: What should I prove??
slide-22
SLIDE 22

22

Lawrence C Paulson

Conclusions

  • Proofs are big, but not too big!
  • Can prove secrecy for several keys and

nonces, with dependency chains

  • Can handle digital envelopes
  • Merchant registration verified similarly—

Purchase & Payment phases too!