nark: non-repudiation of multicast quality bob briscoe & ian fairman bt research 3 nov 1999

Nark:Non-repudiation of multicast quality

Bob Briscoe

& Ian Fairman

BT Research

3 Nov 1999

2 Nov 1999 Nark; (c) British Telecommunications plc 1999

2

context solution variants summary more info

non-repudiation: the problem were sufficient packets delivered on time?

• why should receivers admit they were? • why should sender/network concede they weren't?

multicast - heterogeneous delay & loss applications

• real-time packet audio, video - verbal contract• high value information - financial etc.

woolly solutions:• call customer service and argue• competition

– would AcmeISP lie? GlobalBigTelCo?

context


3


receiver initiated multicast

host 1

host 2 host 3

sender

receivers

router 1

router 2

host 4

join

join

join

join

join

join

context


4


other multicast security problems

components for multi-party e-commerce 1:n or n:m distribution, 1:1 commerce

– non-repudiation– key management– access revocation– audit trail– source authentication– denial of service

context

5


key mgmt: the problem

time

member

context


6


application data unit (ADU)

wrt security/charging

see taxonomy of large-scale multicast requirements [Bagnall]

context

7


key mgmt: ADUs

time

member

context

8


key mgmt

time

member

solution

seed

pseudo-randomkey sequence

key limiting policy

seed

pseudo-randomkey sequence

key limiting policysmartcard

smartcard

sender

9


1. confirm secure space ID & download proxy2. set up session3. transmit data4. generate receipt

receiver

VM + TTP key

outline solution: non-repudiation

sender

1. sender’ssecureproxy

solution

receiver

sender’ssecureproxy

shop

2.2 Seed

2.1 Buy

3.2 ACK/ADU 3.3 Key/ADU

3.1 Bulk stream

4.aggregated ACKs


10


sender's secure proxy

securely encapsulated key generator– virtual machine

• Java Card application programming interface

– private key of trusted third party• generic key generation for any sender

– very light load• only giving out next key in pseudo-random sequence

when requested

iButton, crypto co-processor = "smartcard"

solution

receiver

VM + TTP key

sender’ssecureproxy


11


host vs. network delay

stack interrupt handled non-repudiation module

• deadline learned: middleware f/b

• asks smartcard for key if deadline met

• smartcard records delivery of key

decrypt codec app? not proof that network met deadline, but...

• heavy processing after deadline test

solutionapplic’napplic’n

codeccodec

decryptdecrypt

non-repud’n

transport

network

link

physical

smartcard


13


receipt storage

simple count of delivered keys• in smartcard memory

each delivered key indexed by ADU id– smartcard overflow?

• sign and store on receiver's host(RAM or disk)

• chain digests as append more records

solution

smartcard


14


“Nark?”

solution

snitchinformer

tattle

squealerblab

grass copper's nark


22


audit trail

arbitrage• re-sale always profitable with multicast [Herzog]

buying co-op• share cost of one subscription and re-copy

fundamental problem for sender• all costs in first copy, duplication nearly free

prevention effectively impossible detection via watermarking

context


23


audit trail decrypt on smartcard

• can watermark each copy

off-card solution?– Chameleon [Anderson]

• long-term watermarked key block• watermarks secondary keys - XOR cipherstream partial flaw: no protection against leaks to recent

group members - MARKS [Briscoe]

demo implementation didn't include watermarking

variants

stostolen

len

2 Nov 1999 24


limitations only proves timely delivery to encryptor

• sender? only makes sense if bundling network QoSor if ISP trusts sender - typically not so (e.g. VoIP)

• receiver's ISP? encrypt link for delay sensitive class

must have incentive to return receipt•e.g. to claim refund after pre-payment•(pragmatic solution to 'two generals' problem)

'tamper proof' & 'watermark' fallible if don't need non-repud'n or watermarking

• limited key mgmt possible without smartcard – MARKS [Briscoe]

summary


25


loose coupling to senders

shR

sh

sh

R

R

R

R

R

S

S

S

S

sh

R

sender

shop

receiver

multicast data

unicast set-up

summary

reliable multicast keying not req'd


26


Solution statement I

openly distribute large numbers of locked identical copies of a sequence of items

•arbitrarily control which items each individual can unlock with one message per individual

•change control policy over any individual, with one further control message per individual

•control messages may be aggregated to apply to arbitrary groups of individuals

summary


27


Solution statement II

of those items each individual can unlock:– each individual can prove with one message at the end (or regular messages if necessary):•which ones they didn't unlock•the time they first unlocked those they did unlock

– optionally anyone, by examining the unlocked copy, can prove:•which individual unlocked the copy

summary


28


Wider context

dynamic stack creation• Flexinet, Mware

valid non-multicast scenarios– DVD: digital video disk – VPN: virtual private network

summary


29


further information Mware project

http://www.labs.bt.com ...… /projects/mware/

this presentation and paper… /people/briscorj/papers.html#Nark

Bob Briscoe… /people/briscorj/

Flexinethttp://www.ansa.co.uk/

more info

nark: non-repudiation of multicast quality bob briscoe & ian fairman bt research 3 nov 1999

Documents