Broadcast Encryption and Asymmetric MACs

1
Broadcast Encryption and Asymmetric MACs
2
Goal

• Broadcast to a privileged subset
• (e.g. entitlement msg)
• no group of t unprivileged colluders (hackers)
  can understand the msg
• Selection of the t hackers can be
• worst-case (for broadcaster)
• random (this appears more relevant)

3
Setting

• Center can do only global broadcasts
• No return path
• Privileged set assumed known
• Three types of assumptions
• none
• crypto 1-way f-ns (prgs) exist
• number-theoretic hardness of factoring

4
Costs

• Number of Keys
• Computation overhead
• Communication overhead

5
Naive estimates

• n number of users
• then number of possible subsets is 2n
• each must use a different key!
• (also need 2n bits to specify subset/key)
• - ignored here
• Idea generate needed key (one of many), using
  a few stored keys

6
Results

• 1-resilient
• unconditional n keys
• crypto log n keys
• number-theoretic 1 key
• 1-resilient t-resilient
• worst-case O(t lg t lg n) key overhead
• O(t2 lg2 t lg n) broadcasts
• random O(lg t lg 1/p) key overhead
• O(t lg2 t lg 1/p) broadcasts

7
1-resilient schemes

• Unconditional
• keys Ki for each user i
• user i knows all keys, but his own Ki
• To broadcast to Privileged subset S use the key

8
1-resilient schemes (cont.)

• Crypto similar to above, but
• use construction prG prF GGM-86
• g k (pseudo-)random bits 2k pseudo-random
  bits

9
1-resilient schemes (cont.)

• Number-theoretic (RSA-equivalent)
• Center selects primes p,q npq g
• each user i gets public prime pi and mod n
• The key KS for broadcast to subset S is

10
t-resilient schemes

• direct generalization of the above schemes is
  possible but expensive exponential in t
• (simply consider each group of t users as a
  unit)

11
1- to t-resilient transformation

• To broadcast a msg M break it in m pieces
  M1,...,Mm
• pieces are broadcast using independent schemes,
  each piece k times (each user has keys only for
  one of these k broadcasts)

12
1- to t-resilience (cont.)
k

memory overhead m broadcasts mk
k 2t2 , m t lg n -worst-case lg 1/p
-random
better probabilistic argument gives k t lg
t, m t lg t lg n -worst-case lg t lg
1/p - random
13
Conclusion

• t-resilient broadcast encryption
• random
• lg t lg 1/p keys
• t lg2 t lg 1/p broadcasts
• worst-case
• t lg t lg n keys
• t2 lg2 t lg n broadcasts

14
Problems

• What makes these algorithms not practical (yet)?
• a lot of computation -!!!
• also, maybe could further reduce overheads for
  t-resilient schemes (is polylog in t possible?)

15
Authentication
M
16
Signatures
(M, SigM)
SAlice
SigM Sign(M, SAlice )
17
Authentication public

• checks
• contracts
• love letters ???

18
Public Key Signatures
PAlice

• Public Key
• Secret Key

Verify(M, SigM, PAlice )
19
Public Key Signatures

• Public key ( PAlice )
• known to all
• used to verify the signature
• Secret key ( SAlice )
• known only to the signer
• used to sign messages
• without it, computing signature is infeasible

20
Authentication private
SAlice
Message Authentication Code (MAC) Sign(M, SAlice
)Hash(M, SAlice )
Verify(M, SigM, SAlice ) Check SigM
Sign(M, SAlice )
MAC Shared Secret Sig Symmetric Sig
(SignVerify)
21
Authentication
22
Secret Key Signatures

• Message Authentication Code (MAC) or
• Symmetric Signatures
• Common (Shared) Secret
• Hashing
• MD5, SHA, etc.
• Signature Hash (Msg, Key)
• Verification Signing

23
Hashing
Hash
y
x1
collision
x2

• Crypto Hash
• collisions may exist, but
• are hard to find
• Given y hard to find x, s.t. Hash(x)y

24
Performance

• Secret Key (SK) algorithms beat Public Key (PK)
  ones by orders of magnitude
• Speed
• PK 100-1000 times slower than SK
• Key size
• PK 10-50 times bigger than SK

25
Asymmetric MACs
AMAC)
MAC)

• Use MAC as tool
• Do NOT use Public Key techniques
• but
• Sender signs msgs
• Receivers authenticate the signatures
• Nobody can impersonate the Sender!!

26
AMACs

• How are AMACs different from Public Key
  Signatures?
• Signer and Receivers may share some info
• Authentic for A may not be Authentic for B
• Big coalitions may break the scheme!
• Idea
• Each Receiver has a different subset of keys used
  by Sender for signing
• Different subsets may overlap but not contain
  each other

27
AMACs
The keys of one receiver R
All keys Senders
28
AMACs
K1 K2 . . .
AMAC(M)
MACK1(M) MACK2(M) . . .
29
AMACs
Rs key not covered by the bad coalition
All keys Senders
The keys of one receiver R
Coalition of bad guys
30
Goal

• Given
• N ( of receivers)
• b ( of bad guys)
• Find smallest k ( of keys) and N subsets
  Si?1,,k, such that for
• deterministic
• any b1 subsets Si0 ? Si1?...?Sik
• probabilistic
• ProbSi0 ? Si1?...?Sik

31
Probabilistic Solution
2b
1 p
lg

• Arrange MAC keys in lg(1/p) ? 2b matrix
• Each receiver gets 1 key from each row
• lg(1/p) keys for each receiver
• What chance that a receiver has all her keys
  covered by the keys of b bad guys?
• Probkey covered in 1 row
• Probkeys covered in all rows
• Independent of N!!!

32
Performance

• Sender MAC keys/computations
• 2b lg (1/p)
• Receivers (each) MAC keys/computations
• lg (1/p)
• Alternative
• eb ln(1/p) sender ln(1/p) each receiver

33
Deterministic Solution

• Sender
• O(b2 lgN) keys
• Receiver
• O(b lgN) keys
• How to derive?
• In probabilistic solution set 1/p (N ( ) )1,
  lg(1/p)O(blg N)

ways to choose bad guys
Nb
ways to chose a receiver
34
Bandwidth improvements

• Security of individual MAC
• need not be better than p
• 1bit MACs AMAC ? 5 b lg(1/p) bits
• Sender ? 5 b lg(1/p) keys
• Receiver ?2.5lg(1/p) keys

35
Multiple Sources

• Each user can be a sender and receiver
• Total 4b2lg(1/p) keys
• each user 2blg(1/p) keys
• check MACs for common keys ( lg(1/p))

36
Multiple Sources (better way)

• Same costs as Single Source!
• Total keys Receivers
• as in single source 2blg(1/p)
• Each potential Sender S
• for each key K, gets f(K,S)
• f is a 1way function
• uses all f(K,S) to compute its AMACs
• Receivers compute and use f(K,S) for those K
  which they have
• Senders cannot impersonate!!!

37
Related work

• Broadcast Encryption
• Fiat Naor, Stinson, and others
• Some work in progress