1. CMPE 252A : Computer Networks
Chen Qian
Computer Engineering
UCSC Baskin Engineering
Lecture 9

2. Recommended Term Project
Start to plan your project as early as possible.
Introduction

3. Midterm 11/28 Everything mentioned in lectures and slides.
One page sheet allowed.

4. What is network security?
confidentiality: only sender, intended receiver should “understand” message contents
sender encrypts message
receiver decrypts message
authentication: sender, receiver want to confirm identity of each other
message integrity: sender, receiver want to ensure message not altered (in transit, or afterwards) without detection
access and availability: services must be accessible and available to users
Network Security

5. Friends and enemies: Alice, Bob, Trudy
well-known in network security world
Bob, Alice (lovers!) want to communicate “securely”
Trudy (intruder) may intercept, delete, add messages
Alice
Bob
channel
data, control messages
secure
sender s
secure
receiver
data
data
Trudy
Network Security

6. The dancing men
A story about Sherlock Holmes, by Sir Arthur Conan Doyle.
Network Security

7. The language of cryptography
plaintext
ciphertext K A
encryption
algorithm
decryption
Alice’s
key
Bob’s B
m plaintext message
KA(m) ciphertext, encrypted with key KA
m = KB(KA(m))
Network Security

8. Symmetric key cryptography
encryption
algorithm
plaintext
message, m
ciphertext
decryption
algorithm
plaintext
K (m)
m = KS(KS(m)) S
symmetric key crypto: Bob and Alice share same (symmetric) key: K
e.g., key is knowing substitution pattern in mono alphabetic substitution cipher
Q: how do Bob and Alice agree on key value? S
Network Security

9. Simple encryption scheme
substitution cipher: substituting one thing for another
monoalphabetic cipher: substitute one letter for another
plaintext: abcdefghijklmnopqrstuvwxyz
ciphertext: mnbvcxzasdfghjklpoiuytrewq
e.g.:
Plaintext: bob. i love you. alice
ciphertext: nkn. s gktc wky. mgsbc
Encryption key: mapping from set of 26 letters
to set of 26 letters
Network Security

10. A more sophisticated encryption approach
n substitution ciphers, M1,M2,…,Mn
cycling pattern:
e.g., n=4: M1,M3,M4,M3,M2; M1,M3,M4,M3,M2; ..
for each new plaintext symbol, use subsequent subsitution pattern in cyclic pattern
dog: d from M1, o from M3, g from M4
Encryption key: n substitution ciphers, and cyclic pattern
key need not be just n-bit pattern
Network Security

11. Symmetric key crypto: DES
DES: Data Encryption Standard
US encryption standard [NIST 1993]
56-bit symmetric key, 64-bit plaintext input
block cipher with cipher block chaining
how secure is DES?
DES Challenge: 56-bit-key-encrypted phrase decrypted (brute force) in less than a day
no known good analytic attack
making DES more secure:
3DES: encrypt 3 times with 3 different keys
Network Security

12. AES: Advanced Encryption Standard
symmetric-key NIST standard, replacied DES (Nov 2001)
processes data in 128 bit blocks
128, 192, or 256 bit keys
brute force decryption (try each key) taking 1 sec on DES, takes 149 trillion years for AES
Network Security

13. Public Key Cryptography
radically different approach [Diffie-Hellman76, RSA78]
sender, receiver do not share secret key
public encryption key known to all
private decryption key known only to receiver
symmetric key crypto
requires sender, receiver know shared secret key
Q: how to agree on key in first place (particularly if never “met”)?
Network Security

14. Public key cryptography+ K
Bob’s public
key B -
Bob’s private
key K B
plaintext
message, m
encryption
algorithm
ciphertext
decryption
algorithm
plaintext
message
K (m) B +
m = K (K (m)) B + -
Network Security

15. Public key encryption algorithms
requirements: . . + - 1
need K ( ) and K ( ) such that B B
K (K (m)) = m B - + + 2
given public key K , it should be impossible to compute private key K B - B
RSA: Rivest, Shamir, Adelman algorithm
Network Security

16. Prerequisite: modular arithmetic
x mod n = remainder of x when divide by n
facts:
[(a mod n) + (b mod n)] mod n = (a+b) mod n
[(a mod n) - (b mod n)] mod n = (a-b) mod n
[(a mod n) * (b mod n)] mod n = (a*b) mod n
thus
(a mod n)d mod n = ad mod n
example: x=14, n=10, d=2: (x mod n)d mod n = 42 mod 10 = 6 xd = 142 = xd mod 10 = 6
Network Security

17. RSA: getting ready example: message: just a bit pattern
bit pattern can be uniquely represented by an integer number
thus, encrypting a message is equivalent to encrypting a number.
example:
m= This message is uniquely represented by the decimal number 145.
to encrypt m, we encrypt the corresponding number, which gives a new number (the ciphertext).
Network Security

18. RSA: Creating public/private key pair
1. choose two large prime numbers p, q.
(e.g., 1024 bits each)
2. compute n = pq, z = (p-1)(q-1)
3. choose e (with e<n) that has no common factors
with z (e, z are “relatively prime”).
4. choose d such that ed-1 is exactly divisible by z.
(in other words: ed mod z = 1 ).
5. public key is (n,e). private key is (n,d). K B + K B -
Network Security

19. RSA: encryption, decryption
0. given (n,e) and (n,d) as computed above
1. to encrypt message m (<n), compute
c = m mod n e
2. to decrypt received bit pattern, c, compute
m = c mod n d
magic
happens!
m = (m mod n) e
mod n d c
Network Security

20. Bob chooses p=5, q=7. Then n=35, z=24.
RSA example:
Bob chooses p=5, q=7. Then n=35, z=24.
e=5 (so e, z relatively prime).
d=29 (so ed-1 exactly divisible by z).
encrypting 8-bit messages. e
c = m mod n e
bit pattern m m
encrypt: 12
24832 17 c
m = c mod n d 17 12
decrypt:
Network Security

21. RSA: another important property
The following property will be very useful later:
K (K (m)) = m B - +
K (K (m)) =
use public key first, followed by private key
use private key first, followed by public key
result is the same!
Network Security

22. K (K (m)) = m B - +
K (K (m)) =
Why ?
follows directly from modular arithmetic:
(me mod n)d mod n = med mod n
= mde mod n
= (md mod n)e mod n
Network Security

23. Why is RSA secure?
suppose you know Bob’s public key (n,e). How hard is it to determine d?
essentially need to find factors of n without knowing the two factors p and q
fact: factoring a big number is hard
Network Security

24. RSA in practice: session keys
exponentiation in RSA is computationally intensive
DES is at least 100 times faster than RSA
use public key cryto to establish secure connection, then establish second key – symmetric session key – for encrypting data
session key, KS
Bob and Alice use RSA to exchange a symmetric key KS
once both have KS, they use symmetric key cryptography
Network Security

25. Protocol ap1.0: Alice says “I am Alice”
Authentication
Goal: Bob wants Alice to “prove” her identity to him
Protocol ap1.0: Alice says “I am Alice”
“I am Alice”
Failure scenario??
Network Security

26. Authentication Goal: Bob wants Alice to “prove” her identity to him
Protocol ap1.0: Alice says “I am Alice”
in a network,
Bob can not “see” Alice, so Trudy simply declares
herself to be Alice
“I am Alice”
Network Security

27. Authentication: another try
Protocol ap2.0: Alice says “I am Alice” in an IP packet
containing her source IP address
“I am Alice”
Alice’s
IP address
Failure scenario??
Network Security

28. Authentication: another try
Protocol ap2.0: Alice says “I am Alice” in an IP packet
containing her source IP address
Trudy can create
a packet “spoofing”
Alice’s address
“I am Alice”
Alice’s
IP address
Network Security

29. Authentication: another try
Protocol ap3.0: Alice says “I am Alice” and sends her
secret password to “prove” it.
“I’m Alice”
Alice’s
IP addr
password
Failure scenario?? OK
Alice’s
IP addr
Network Security

30. Authentication: another try
Protocol ap3.0: Alice says “I am Alice” and sends her
secret password to “prove” it.
Alice’s
IP addr
Alice’s
password
“I’m Alice”
playback attack: Trudy records Alice’s packet
and later
plays it back to Bob OK
Alice’s
IP addr
“I’m Alice”
Alice’s
IP addr
password
Network Security

31. Authentication: yet another try
Protocol ap3.1: Alice says “I am Alice” and sends her
encrypted secret password to “prove” it.
“I’m Alice”
Alice’s
IP addr
encrypted
password
Failure scenario?? OK
Alice’s
IP addr
Network Security

32. Authentication: yet another try
Protocol ap3.1: Alice says “I am Alice” and sends her
encrypted secret password to “prove” it.
Alice’s
IP addr
encrypted
password
“I’m Alice”
record
and
playback
still works! OK
Alice’s
IP addr
“I’m Alice”
Alice’s
IP addr
encrypted
password
Network Security

33. Authentication: yet another try
Goal: avoid playback attack
nonce: number (R) used only once-in-a-lifetime
ap4.0: to prove Alice “live”, Bob sends Alice nonce, R. Alice
must return R, encrypted with shared secret key
“I am Alice” R
K (R)
A-B
Alice is live, and only Alice knows key to encrypt nonce, so it must be Alice!
Failures, drawbacks?
Network Security

34. “send me your public key”
Authentication: ap5.0
ap4.0 requires shared symmetric key
can we authenticate using public key techniques?
ap5.0: use nonce, public key cryptography
“I am Alice”
Bob computes R
(K (R)) = R A - K +
K (R) A -
and knows only Alice could have the private key, that encrypted R such that
“send me your public key” K A +
(K (R)) = R A - K +
Network Security

35. sends m to Alice encrypted with Alice’s public key
ap5.0: security hole
man (or woman) in the middle attack: Trudy poses as Alice (to Bob) and as Bob (to Alice)
I am Alice
I am Alice R T
K (R) - R A
K (R) -
Send me your public key T K +
Send me your public key A K + T
K (m) +
Trudy gets T
m = K (K (m)) + - A
K (m) +
sends m to Alice encrypted with Alice’s public key A
m = K (K (m)) + -
Network Security

36. ap5.0: security hole difficult to detect:
man (or woman) in the middle attack: Trudy poses as Alice (to Bob) and as Bob (to Alice)
difficult to detect:
Bob receives everything that Alice sends, and vice versa. (e.g., so Bob, Alice can meet one week later and recall conversation!)
problem is that Trudy receives all messages as well!
Network Security

37. Secure Group Communications Using Key Graphs
by Chung Kei Wong, Mohamed Gouda, and Simon S. Lam
in Proc. ACM SIGCOMM ’98
Secure Group Communications (Simon S. Lam)
12/2/2018

38. Secure group communications
Applications
teleconference
information services
collaborative work
virtual private networks
Group members share a symmetric key to
encrypt/decrypt communications
providing confidentiality, integrity, and authenticity of messages delivered between group members
access resources
Secure Group Communications (Simon S. Lam)
12/2/2018

39. Group key management A group session may persist for a long time
Secure rekeying
after each join
after each leave
periodically -> batch rekeying (another paper)
Scalable server and protocols
for large groups with frequent joins and leaves
Server processing time scalability in this paper. Communication reliability and scalability in next paper by Xincheng Zhang.
Periodic rekeying -> batch rekeying with a small vulnerable period
Secure Group Communications (Simon S. Lam)
12/2/2018

40. Assumptions Key server is trusted and secure (may be replicated)
An authentication service
for example, SSL
mutual authentication of server and joining user
distribution of a key shared by server and joining user (individual key)
Key server may be replicated to enhance reliability and performance. (Assumption is okay since we are not dealing with a mobile ad hoc network.) Also use a set of registrars for authentication and authorization services (see Keystone paper by Wong and Lam, 2000)
Secure Group Communications (Simon S. Lam)
12/2/2018

41. Group rekeying Non problem after a join After a leave has occurred
new group key encrypted by old group key
one encryption/rekey msg for all existing users
After a leave has occurred
new group key encrypted by individual key of each user
n-1 encryptions/rekey messages for group size n
not scalable
Secure Group Communications (Simon S. Lam)
12/2/2018

42. Key star Group of n users, one group key, n individual keys
This is the usual case
Secure Group Communications (Simon S. Lam)
12/2/2018

43. Join Protocol Protocol Encryption cost: 2 u4  s : join request
s  u4 : mutual authentication, distribute k4
s : generate k1234
s  u4 : {k1234}k4
s {u1, u2, u3} : {k1234}k123
Encryption cost: 2
S may send to {u1, u2, u3} by unicast or multicast
Secure Group Communications (Simon S. Lam)
12/2/2018

44. Leave Protocol Protocol Encryption cost: n-1 for group size n
u4  s: {leave request} k4
s  u4: {leave granted} k4
s: generate k123
s  {u1}: {k123}k1
s  {u2}: {k123}k2
s  {u3}: {k123}k3
Encryption cost: n-1 for group size n
O(n) cost is not scalable
Note: it is the encryption cost we pay attention to in this paper. The communication cost was addressed in subsequent papers
Secure Group Communications (Simon S. Lam)
12/2/2018

45. Iolus approach [Mittra 1997]
...
agent
user
A hierarchy of security agents
No globally shared group key
join/leave affects local subgroup only
Agents forward message key
decrypting and re-encrypting it with subgroup keys
Requirement: many trusted agents
Iolus is first paper on scalable group communications – key graph paper is second
Each agent and its children share a subgroup key. A leave affects only a local subgroup, with rekeying of the subgroup only <<< less work in Iolus when a user joins or leaves but more work when the first confidential message is sent
Each agent decrypts using one subgroup key to retrieve the message key and re-encrypts it with another subgroup key for forwarding. Thus most of the work (encryption+decryption) is postponed to when a data message is being sent and received (O(log(n))) <<< more work in Iolus when a user sends a confidential message. However, the overhead of a confidential message in Iolus can be amortized over many confidential messages if agents are willing to maintain state for the source destination flow
For key tree - If there are frequent joining and leaving relative to number of confidential messages sent, then key tree is not so good. Can be alleviated by batch rekeying.
Also, a large number of agents have to be trusted instead of a single trusted server.
For reliability it is easier to replicate one server than to replicate many agents. Without replication, failure of a single server is fatal.
Secure Group Communications (Simon S. Lam)
12/2/2018

46. Our approach A hierarchy of keys ... Multiple keys for each user
individual key
group key
subgroup key
user
A hierarchy of keys
Multiple keys for each user
user has every key along path to root
A single trusted key server is sufficient (may be replicated for reliability)
Secure Group Communications (Simon S. Lam)
12/2/2018

47. Key graph Data structure maintained by key server
For a single secure group
key tree sufficient for scalability
Multiple secure groups
merging multiple trees into a graph
Key graph may also be useful for access control by different groups/subgroups to resources
Secure Group Communications (Simon S. Lam)
12/2/2018

48. Rekeying strategies How to compose and deliver rekey messages
user-oriented
key-oriented
group-oriented
Secure Group Communications (Simon S. Lam)
12/2/2018

49. User-oriented rekeying
k k1-8
k k78
k456
k123 k1 k2 k3 k4 k5 k6 k7 k8 k9 u1 u2 u9 u8 u3 u4 u5 u6 u7
Select new keys needed by a user or subset of users, form a rekey message and encrypt it
(d-1)(h-1) rekey messages – sent by unicast or subgroup multicast
Most work on server, least work on user
Leaving
Note that some keys are encrypted multiples times in different messages
There are (d-1)h(h-1)/2 keys encrypted, sent in (d-1)(h-1) rekey messages by unicast or subgroup multicast
Joining is not considered for user-oriented and key-oriented approaches in these slides.
Secure Group Communications (Simon S. Lam)

50. Key-oriented rekeying
k k1-8
k k78
k456
k123 k1 k2 k3 k4 k5 k6 k7 k8 k9 u1 u2 u9 u8 u3 u4 u5 u6 u7
Encrypt each new key, then compose rekey messages - encryption cost d(h-1) -1
(d-1)(h-1) rekey messages – sent by unicast or subgroup multicast
Less work on server than user-oriented
Leaving
Each new key encrypted only once.
Encryption cost is d(h-1)-1, better than user-oriented. (“-1” missing in paper.)
Check: in the special case of a star, h=2, so encryption cost is d-1 = n-1 <<< okay
There are (d-1)(h-1) rekey messages to be sent by unicast or subgroup multicast same as user-oriented
Secure Group Communications (Simon S. Lam)

51. Group-oriented rekeying
k k1-8
k k78
k456
k123 k1 k2 k3 k4 k5 k6 k7 k8 k9 u1 u2 u9 u8 u3 u4 u5 u6 u7
One rekey message containing all encrypted new keys – sent by multicast
Message size O(log n)
Each user decrypts what it needs
Least work on server, most work on user
A user cannot decrypt any key that does not belong to the user
Leaving
Encryption cost is d(h-1)-1, same as key-oriented, but a single rekey message sent by multicast.
Note that a user cannot decrypt a key that does not belong to it.
Secure Group Communications (Simon S. Lam)

52. Join: group-oriented rekeying
k k1-9
k456
k123 k1 k2 k3 k4 k5 k6 k7 k8 k9 u1 u2 u9 u8 u3 u4 u5 u6 u7
k k789
Encryption cost: 2(h-1)
Key tree incurs a larger cost than key star
Joining of u9:
Each new key has to be encrypted for existing users. Each new key has to be encrypted for the new user. Therefore, 2 (h-1) keys encrypted since there are h-1 new keys.
In the case for key star, h=2 and there are only 2 encryptions. They are sent in two separate messages, one by multicast and the other by unicast to the new user.
Join protocols for user-oriented and key-oriented are omitted (because we will not use them). User-oriented requires (h(h+1)/2) -1 keys encrypted and h rekey messages.
Key-oriented requires 2(h-1) keys encrypted and h rekey messages.
Secure Group Communications (Simon S. Lam)

53. Ave. encryption/decryption cost of a request-1
Need to go back and think about costs from point of view of requesting/non-requesting user.
Complete case clearly should not be used. For a join, the new user gets 2^n – 1 new keys. The server has to do twice as much work, 2^n – 1 for the new user, and 2^n – 1 for the existing users.
For a tree case, a new user gets h-1 new keys. A non-requesting user decrypts and changes, on the average, d/(d-1) keys; see derivation in Appendix of journal paper <<<
Encryption cost of the server: For tree case and a leave, assumes key-oriented or group-oriented. Server cost for a leave should be d(h-1) -1 rather d(h-1); the -1 is neglected <<< fixed
Cost is in number of encryptions/decryptions performed – actually it is number of keys encrypted by server, irrespective the number of messages containing the keys. For a user it is the number of keys decrypted.
Note star is a special case of tree with h=1 and d equal to n, where n is large -2
Secure Group Communications (Simon S. Lam)

54. Average encryption/decryption cost of a request (join or leave)
For a full and balanced tree,
For a key tree (instead of key star), server does less work, but user does slightly more work
Optimal key tree degree is 4
2^n is approximate, (d+2)/(h-1)/2 - ½ instead of (d+2)/(h-1)/2
Assume the same number of joins and leaves; n is large Actually, h -1 = log_d(n) per our definition in HW and previously
For a full and balanced d-ary tree, the average server cost is (d+2)(h-1)/2 = (d+2)(log_d(n)))/2, so log(n) instead of n, but each user has to do slightly more work d/(d-1) instead of 1.
The server cost is minimized for d=4, which is the optimal key tree degree.
Secure Group Communications (Simon S. Lam)
12/2/2018

55. Experiments Two SGI machines connected by 100 Mbps Ethernet
server on one, users on the other
Rekey messages sent as UDP packets
DES, MD5, RSA from CryptoLib
n joins, then 1000 randomly generated join/leave requests
UDP does not provide reliable delivery—reliable and scalable rekey delivery is the topic of several additional papers (see references)
But we were planning to use erasure code
Secure Group Communications (Simon S. Lam)
12/2/2018

56. Server processing time per join/leave request
includes:
time to parse a request, traverses key tree to determine which keys to change, generates new keys, updates key tree
time to encrypt new keys and construct rekey messages,
time to compute message digest of rekey messages and digital signatures,
time to send out rekey messages using socket system calls
Note that RSA is slow, so signature is done on a message digest of the actual message
Secure Group Communications (Simon S. Lam)

57. Technique for signing rekey messages
Server processing time include parsing key tree, DES encryption, MD5 hash, and RSA signing, socket calls
A digital signature operation is about 2 orders of magnitude slower than a key encryption using DES. Special signing technique is needed for key-oriented and user-oriented because server sends out many messages; not needed for group-oriented because user sends out only one message.
See digital signature paper by Wong and Lam
Message sizes are larger in one signature for all rekey messages because of chaining info
Ave denotes average of join and leave proc times
key tree degree 4, initial group size 8192, encryption and signature
Secure Group Communications (Simon S. Lam)

58. Server processing time (per request) versus group size
encryption only
encryption and signature
Increases linearly with logarithm of group size
Secure Group Communications (Simon S. Lam)

59. Server processing time versus key tree degree (per join)
Initial group size 8192
Cost is 2(h-1), so as d goes up, h goes down, and cost goes down
encryption only
encryption and signature
Cost is proportional to 2(h-1)
Secure Group Communications (Simon S. Lam)

60. Server processing time versus key tree degree (per leave)
Initial group size 8192
Cost is d(h-1), so d increases, cost increases; h goes down but d increases faster than h decreases
encryption only
encryption and signature
Cost is proportional to d(h-1)
Secure Group Communications (Simon S. Lam)

61. Number of key changes by a user (per request)
Very close to analytic result, d / (d – 1)
Secure Group Communications (Simon S. Lam)

62. Rekey messages sent by server
With encryption and signature (initial group size 8192, key tree degree 4)
Total number of bytes sent is much smaller for group-oriented rekeying than the others
Total number of bytes sent by server is much higher for user-oriented and key-oriented due to the number of messages sent. For multicast, user only needs to send a message once – but if unicast is used that server has to send n messages, irrespective of user-oriented or group-oriented
Also, signing is easier to do without special technique to do chaining – therefore, group-oriented rekeying is the best
Secure Group Communications (Simon S. Lam)
12/2/2018

63. Conclusions
Scalable server performance demonstrated experimentally and analytically
Group-oriented rekeying requires smallest processing time and transmission bandwidth of server (signing is also easier), but requires each user to do more work
Hybrid approach with use of user- or key-oriented rekeying for users with limited capabilities
Solution to just the most obvious problem of scalable server processing
Many more papers to follow
Secure Group Communications (Simon S. Lam)
12/2/2018

64. End
Secure Group Communications (Simon S. Lam)
12/2/2018